Question Vote for coding standards

Probably all votes from m_ would go to _ instead of no prefix. So it's 130:100 for prefixes.

 

How they became variables? Not using CAPS doesn't make them static or something.

Code (CSharp):

1. public class Character
2. {
3.     private struct Consts
4.     {
5.         public const float GravityAmount = -9.81f;
6.     }
7. }

Now you know that they're constant and inside this class only. It looks very clean, without distracting attention of caps.

I don't want to type / look at Dictionary<GameObject, Component> two times in a row.

Seriously?
So many people using them just cause some YouTuber told them to <insert C++ reasons>.
I've tried it myself and it was super ugly.
We have

this.

for rare cases where local is named the same as member.

I feel like these are bad practices from 90's era.
But we're teaching good ones there, right?
So we need to avoid questionable principles as much as possible, and stick to the most human-friendly standards of C#.

~In my honest opinion

 

Not gonna lie, you are pretty good at making stuff up. Other thread:

 

Personally I prefer sing a _ prefix so that if I'm deep in the code I don't have to look at the signature of a field in order to know whether it's public or private, I can just see the _ in front of it and know that this is a private field.

Also, why exactly would these be bad practices?

 

Maybe try to convince Unity to add "Find References In Project" option (similar to current "Find References In Scene") to the engine. Something like https://github.com/ogxd/project-curator. Would help a lot with any SO workflow.

 

If that were to be added it would only come in 2020.2 at the earliest so that wouldn't work for our project in 2019.4

I do agree that that could help out, I'll forward it to the QoL team

 

Sorry if my harsh expression leads to misinterpretation.
These are coming from my personal experience and reading of the thread.
I'm trying to discuss actual problems here

We've already said how in the posts above.
It goes against some C# standards, as a result makes code much harder to read, and newcomers may think of these as something special in terms of compilation. (ex. Python coders with their __class__)

 

Still making stuff up?
Microsoft:

Google:

.NET Runtime:

 

So it means "use what's best to solve your problem", right?

As I see '_' can be helpful in monster classes, where it is actually hard to find members you need.
But in that case, maybe you're doing something wrong and you better split your logic into multiple encapsulated classes

That's why I feel prefixes would not fit in this project

 

Yeah, I know. But they are not like 'really private'
I mean serialized fields are injected through Unity's serialization, so maybe this particular subject worst discussing.

Personally, I use '_' for serialized fields too. But I don't have sureness about this.
I think it should be explicitly declared in conventions.

And I would vote for a separate folder for scenes. Because scenes will generate scene-specific folders for Lightmaps and NavMeshes. It's not cool to have such folders in the root of the project. Maybe you can move them to a different place after creation, but I've never tried this. And this is not convenient at all.

 

And about monsters.

Spoiler: Singletons

Try to avoid the usage of Singletons. Explore usage of ScriptableObjects (1, 2) for a similar, centralised class that can be accessible from multiple objects.

Something like that would be nice:
Avoid structure of "Monster" classes. Learn about Single Responsibility in S.O.L.I.D. principles and more:

Note: we use Inspector and ScriptableObjects for Dependency Injection principle.

 

Seems like it's possible in Quick Search. Version 2.0 is a bit wonky compared to 3.0 (available in 2020.1) but better than nothing:


Ver 3.0:

Consider adding that package.

 

Good find! It looks a little nicer in 2.0 for me

 

I'm sad about the prefix on privates, the var ban and the caps on constants, however there's been plenty of discussion around those topics already.

Now, I'd like to raise a couple of other things:

• First, my personal preference on properties:
  • Usually I only use public fields in structs, never in classes. I'd say, when exposing a field, use properties instead of the field itself, particularly when you only need to read the value from outside. eg:
    
    Code (CSharp):

    1.     public string Name => _name;
    2.     [SerializeField] private string _name;
  • PascalCase properties, even private ones. I used Rider a while ago and if I recall it suggests doing that by default, and it stuck with me when I switched back to VS. But anyway, My reason behind it is, I like using private properties mainly to improve readability on repeatedly accessed data from different members, or to easily get common values that don't really require dedicating a field to. Basically I use them as simpler versions of Get methods to reduce boilerplate, that's why I believe they should be differentiated from fields and PascalCase suits them better. eg:
    
    Code (CSharp):

    1. private Vector3 Velocity => _characterController.velocity;
    2. private bool IsGrounded => _characterController.isGrounded;
    3. private bool IsFalling => !IsGrounded && Velocity.y < 0f;

• Second, any words about capitalization of protected fields? Some people (like myself) treat them as private, some as public, and some use a different prefix—so this should be in the document as well.

• And finally, this is all syntactic sugar and I'm in favor of all of it, but I know some people aren't. It doesn't say anything in the document about them so I'm just wondering if we should get a consensus or leave it at the discretion of the programmer.
  • Ternary operator ? "yes" : "no";
  • Both Null?.Propagation() and Null ?? Coallescing (except with UnityEngine.Object (and no ??= cuz c# 8 when? ))
  • Expression-bodied member => expression;
  • No brackets on single line statements.
    
    Code (CSharp):

    1. for (int i = 0; i < length; i++)
    2.     for (int j = 0; j < length; j++)
    3.         if (isTrue)
    4.             WhoNeedsBrackets();

Any thoughts?

 

Yes. This please.

I'm trying to avoid private properties, as it's not always clear what they represent.
For ex. if I make IsGrounded inside PlayerUI class, would it make any sense?

If it's used by user then it's public

I think we won't use them on UnityObjects. Any other sugar is cool for me

 

That seems more like a naming problem. You could call it IsPlayerGrounded and I guess it'd make sense.

What do you mean? If it's serialized it's PascalCase, if not it's _camelCase? That would be extremely odd imo. What does it have to do with the fact that it's protected?

That's what I said

 

I'd only do it if it was basically a calculated private field or something. I support just avoiding them altogether to prevent confusion.

EDIT: Also I'll go ahead and throw it here since this seems to be one of the few places where there is actual discussion, but I'm rather annoyed that there has not been any official comments in the Inventory System thread. I'm rather disinclined to participate in the project at this stage, which is a shame because I was very interested in it at the start.

 

If protected field is exposed to user from abstract class then it's camelCase. For properties - PascalCase

 

Ciro made a revised story post in the narrative thread and asked that we finalize it by today so that the other systems can be worked on, which includes the inventory system. I assume that locking down the story means that either he or one of the other Unity people will make a post later today/over the weekend/early next week about the other systems, so only a little more time to wait.

 

Just for your information, for all of you, who use the "_" as a visual indicator for private field, did you know that VS already show a different icon in the intellisense base on the access modifier ? Plus, you can Alt-F to show only fields.

 

Oh okk, agreed then!

This.

 

I'd also like to call out the fact that VSCODE is free and available on all platforms mac/linux/windows. Rider and visual studio both have a cost associated with them.

If there is an interest in being an inclusive community project, then VSCODE is definitely going to in the toolset of *at least some* of the developers.

 

Visual Studio Community is free.

 

I suppose so! If you look at the VS community license it includes unlimited use "for contributing to open source projects."

Since unity open project 1 is an open source project, then I guess VS community would be good to go without limitation if used in this context. I'm so used to telling new/junior developers to uninstall community and get a licensed version that I forgot.

Thanks!

 

does anyone have a rider settings file for this?