Question Vote for coding standards

You can select 2 options:
- C# or C++
- preferred prefix for private fields/member variables

Good to see this project happening, almost exactly what I proposed twice:

Tbh I'd rather see few smaller projects instead of one massive one as it will be tough to keep it updated with the engine.

 

I prefer to stick with Rider's standards, but not everyone uses Rider I guess

 

I also prefer Rider's standards. They're very sane and it helps keep the code consistent with general C# style guidelines

 

you guys use uppercase public fields.
i was taught in programming, idk what language maybe c# dont use other languages. I was told that variables, all variables would have a lowercase and methods and other important stuff would have an uppercase. Have i been mistaught

 

Each language has it's own convention. Not to mention that most of the time frameworks also has their own naming conventions too.

 

In fact I quoted one of your posts in my proposal, back in April

What do you mean? Are you referring to this project when you say "massive"?

 

I must guess it' s because C# has properties, which are basically shortcuts for Get Set methods, and public variable are very similar to properties when viewed from outside

 

Could you send a link or explain exactly how Rider's differs from C#?

 

Rider's standard is the same C# standard. The IDE just actively enforces it

What he meant, is mainly always using var except for when you can't. Writing public variable and function names in PascalCase, declaring private variable prefixed with an underscore (private float _movementSpeed), and private serialized fields with camelcase without using the underscore

 

If we were to go with private fields not using m_ but instead just pascalCase, how do we deal with properties? Are properties gonna be UpperCase (CamelCase)?

I'd like to adopt any convention that will be chosen but for me the idea of using m_ for private is:

private int m_hitPoints = 100;
public int hitPoints => m_hitPoints;

But yeah I'm pretty excited for the project regardless.

 

I don’t care, as long as it’s consistent, doesn’t get in the way of autocomplete, doesn’t create resistance to refactoring and change and is human readable.

 

hmm I'll try my luck: what about making Unity source-available like Unreal? (just kidding... or?)

Yes, well looked through the cards and maybe it's not massive but compared to all other Unity samples/projects it's going to be the biggest one in terms of connected gameplay systems. It may be a real challenge to maintain if it gets too popular. If that happens then creating multiple projects with community github moderators/reviewers (like bitcoin) could be good.

Tbh I dislike a bit that Unity LTS version was picked but I guess this particular project is meant to be stable for learning experience not exactly improving Unity. For future projects (or some of them) consider using the newest non-beta version .

 

No public fields, no prefixes - public PascalCaseProperties => private [SerializeField] inCamelCase as per original C# naming conventions.
Prefixes are redundant if you are using an IDE and reduce readability, it makes it look like you are doing something special or have got the discard character wrong. It's not C / C++ in the 90s.

 

I would go with Rider's standard as well. Makes thinks more organised and clear for anyone joining the project Thou, just having any standard would be awesome as the project's idea is pretty cool. Look forward to contributing to it.

 

Enforcing these specific cases won't be easy.

I'm not a fan of var everywhere, ptsd from js.

 

I prefer no prefix. Same reasons Braneloc mentioned:

That being said, as long it's consistent, I'm cool with it. Is there an official deadline on the voting?

----------------------------------------------​

Commenting Standards - Where are they?
Obviously, explain with good naming and readable code, but we're probably gonna want comments, too.
I suggest:
- Write comment above every class that says the class' purpose. Optionally, include details about how the class works, especially if it's not particularly intuitive or readable.
- Precede each comment with a "signature" that includes git username and date comment was written.

Code (CSharp):

1. // UnityTechnologies 9/30/2020
2. // comments here

Sidenote: It brings me joy no one voted for "Whatever (complete mess)"

 

I second this. The Microsoft spec is probably more thorough and thought-out than any standard we can come up with in any reasonable period of time.

Some may be concerned that these guidelines are now 12 years old, but this section of the C# programming guide in the official .NET docs references them, and that was just two years ago.

 

There's some advantages to using public properties only instead of public fields but they make project a bit more complicated for new users.

Up to @cirocontinisio if another voting will be needed or rather keep it simple for the 1st project.

 

Things should only be public if they are to be used in other classes. If not, it adds to complexity :/ Encapsulation!
Code should always be descriptive - public properties make it clear what is read/write and what should be used.

Also - lets please get rid of magic numbers in code - I'm looking at you Character.cs (and that Update method is huuuge)

If you are looking at complexity, git can be completely overwhelming to new git users. Wait, official Unity Asset Store GitHub but it's a plugin not a package and not included, Visual Studio integrated but where's the tab, GitHub desktop - there's 4 versions of my copy now, sourcetree won't run and that guy on the internet says command line except he's on a mac and... now the fork is behind.. and none of these git words make sense.. Oops, I went off topic

 

I find it easier to differentiate between private fields and local variables when prefixed, but it's ultimately down to personal preference - as per the C# guidelines:

"The field-naming guidelines apply to static public and protected fields. Internal and private fields are not covered by guidelines"

 

Change color of fields in IDE.

The only advantage of underscores is being able to quickly pull up intellisense with fields list, useful in big classes, waste of time in smaller ones.

 

I vote for Rider standards, too: prefixes for private fields. That said, I think public fields should be camelCase and properties should be PascalCase.

 

I absolutely agree with you!

• camelCase for public
• camelCase with "_" prefix for private
• PascalCase for methods and public variables with access modifiers

We can have an editorconfig file that enforces these styles. I can create it.

I'd also add having attributes (such as [Tooltip] or [SerializeField]) in different lines.

 

I agree with this. I would add that my preference would be to keep public fields to a minimum. I'd prefer private fields with the [SerializeField] attribute.

 

Absolutely, that's a must.

 

In an IDE, sure, but Open Projects are hosted on Github where such distinction is advantageous to readability.

 

Will you implement public variables with access modifiers or getters/setters?

 

I *hate* var everywhere.

Code (CSharp):

1.   var result = SomeFunction(var1, var2);
2.   gameObject.method(result);

What is result???
This is so useless for code reviews and makes for hideous ramping up and debugging.

And C# styles get confusing when mixed in with the Unity JavaScript-styled libraries:

Code (CSharp):

1.   myGameObject.transform.localPosition = myVector;

(Although I do love the C# standard styles and am happy if we stick with them for the project.)

 

That's the C++ convention in the poll. It's not the case everywhere, newer packages use uppercase public properties/fields like Addressables, Jobs, Entities.

 

Are you writing in notepad?

 

Github viewer is kinda a notepad and also hovering over a variable/method to see its type is a waste of time.

Use var if it makes sense and type is visible within few lines.

This project and its code will be reused by many users, readability is the top priority.

 

I agree with @Dustin_00 , using var everywhere is a nightmare from a code review point of view. Per Dustin's example, what is result? Is it a standard type like int or string? Is it a List or Dictionary? Is it a class? Without looking at either the SomeFunction function, or the gameObject.method function you have no idea what that may be returning. And what if someone later changes what SomeFunction returns, but not the input for gameObject.method? Congratulations, you've now got an error in the Unity console that may not be clear.

When the goal of this project is partially teaching, using var will make it much less accessible for newer programmers. I'd recommend we avoid them as much as possible.

Exactly this. In the time it takes you to hover over a var type and for the popup to appear after Intellisense guesses what the variable type is, I could have pressed my F12 key and already be at the definition for the custom class. Being explicit in what type a variable is aids that goal by aiding readability.

 

Oh, okay, in that case I agree on that.
But "_" prefix kills readability

 

I used to be against the underscore private field prefix until I was convinced by a rather compelling argument that it helps differentiate members from locally scoped variables. In my day job, I rarely use fields so it hardly matters. I don't have a strong opinion on the matter.

However, I definitely prefer using var when possible. Variable names should be meaningful and having the type explicitly presented next to the variable is no excuse for poor naming. That being said, I'll agree to community preference on it. I will say that assignments where the type is obvious should be exempt and the programmer should prefer implicit typing:

Code (CSharp):

1. var item = new Item();
2.  
3. var inventory = GetComponent<Inventory>();

 

It doesn't.
I've made theme for Rider that makes locals gray, reassigned italic, members cyan, properties purple, and statics bold.
That's what actually makes code readable and keeps your eyes pleased

 

Let me know if you find something that works for VS Code, I don't see anywhere I can customize the color of field variables specifically. In the meantime, I'd also recommend taking a gander at changing your font to Fira Code, it has ligatures that are amazing for code readability.

 

VS Code is not an IDE for me

Any font rather than JetBrains Mono looks awful in Rider, especially with bold italic usage

 

Well I could be wrong but I suspect more people are using VS Code and Visual Studio 2019 Community to contribute than Rider. So to that end I'd probably still prefer the prefix for readability (and of course that's not even including the code reviews in github.)

 

For VS Community 2019 get https://marketplace.visualstudio.com/items?itemName=ms-madsk.ColorThemeDesigner
and
https://marketplace.visualstudio.co...vKuzmichArtStea1th.EnhancedSyntaxHighlighting

 

Private fields without "m_" or "_" shouldn't even be an option IMO.
Without prefixes it will become a pain in the neck to distinguish between local variables and fields.

Code should be always readable, regardless of the IDE.
Plus rider is behind a paywall, correct me if I'm wrong.

 

I agree with @kcastagnini and @tmcdonald, I think it's a good idea to adopt a solution that works well for any IDE or code editor of choice.

So either "_" or "m_" is good for private and protected fields.
I have a preference for Pascal case for public properties to differentiate them from local variables.

As for the the use of var. I find it extremely useful for refactoring. I'd also argue the the function names should be sensible and the type returned should be implicitly evident.

Also I believe abbreviations should be avoided as much as possible. I prefer a lon variable name that makes sense than a small one that leaves me with doubts

 

Yes I'd love PascalCase for public fields me too, camelCase for local vars and _camelCase (or m_camelCase) for private fields.
If we use camelCase for everything it will become a huge mess.

 

I'll never understand that.. I haven't encountered such problems when used VS, even in the messiest code.
Members are always at the top, you read them first and you know them.
Locals are, well, locally, so it's easy to see them without much scrolling.
If you have "somethingList" as member it would be just "list" locally, and you know what it is, cause it's made in CreateSomethingList().

And when i'm looking at the Unity's source code, i'm just getting distracted to all "s_" and "m_"' 's, it just makes code ugly and doesn't help.
Good names and methods split - that's what helps

 

I find really readable private properties with _ or m_ on the other hand, because I can immediately understand if a variable is a private field or local variable without scrolling or remembering all the fields.
Plus by typing _ I get all the suggestions by IntelliSense.
It's just my preference anyways, I'm just used to it.

 

I'm all for this, with the exception of step 5 (although it makes perfect sense).

His descripting of camelCase seems wrong to me but it's still okay.

 

My short and simple summary of the whole thread and polls (tabs vs spaces):

- PascalCase: classes, methods, enums, namespaces, public fields/properties
- camelCase: local variables, methods parameters
- _camelCase: private fields/properties
- use [SerializeField] private instead of public when possible to expose fields in the editor
- (optional) try to use public properties instead of public fields
- tabs, not spaces

Obviously don't use it, wait for guidelines from Unity.

 

I'm with @Neonage and "Uncle Bob" on this. Prefixes and suffixes are not necessary with the IDEs we have nowadays. You should just keep your classes small, following SOLID principles. Actually, it is better to hide a field that would be public in a Property.

 

Often times on github you read and discuss code snippets not whole files.

 

Ahh but a C# field is really just a neat way of encoding a getter and/or setter method. In fact the motivation for using uppercase fields and properties and methods is that the client to the API shouldn't need to know what it is! A field like .Speed could be a getter property or a public field for all the client cares.