preferred prefix for private fields/member variables
Good to see this project happening, almost exactly what I proposed twice:[quote=“Kamyker, post:236, topic: 781986”]
I really wish that we would have “Live Projects” (similar to Live Game) created by both Unity and community. Instead we have Abandoned Projects that were made just to showcase some kind of preview feature.
[/quote]
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.
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
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
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.
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.
// UnityTechnologies 9/30/2020
// 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.
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”
hmm I’ll try my luck: what about making Unity source-available like Unreal? (just kidding… or?)
Encapsulation!
Oops, I went off topic