I have wrote small cheat sheet about Unity Coding Guidelines. You can send it to anyone who asks or worried about his/her code formatting rules.
Link: https://gist.github.com/dasannikov/9fbffd8e6965e005f34390a3572abe20
Any comments / suggestions ?
1 Like
Some explanations as to why one should/shouldn’t do the suggestions mentioned would be nice.
The majority of the sheet is basically just saying “don’t do this” without explaining why.
1 Like
Indeed. I don’t even agree with some of the recommendations, such as “Avoid public fields. Use public properties instead” — I see this in some plugin code, and it’s nothing but a PITA (quite apart from being slightly wasteful of CPU cycles). My guideline would be: avoid public properties unless you need them; use public fields instead. (You can always convert to a property later if the need arises, without affecting the calling code.)
1 Like
At the risk of sounding like I’m piling on here, I agree with Joe and Vryken. Code standards are a great thing to have, but I think their importance is reduced when you’re working on a solo project. I finished my first game with terrible code (public everything, tightly coupled classes) but I finished the game! Compare that to now when I write much better code, but get so caught up in doing things “correctly” and in a way that will scale well that I get caught in the slog of it and get bored, never finishing the project. Kinda tough to argue that working fast and dirty on your own project is the worse option, in my opinion.
That said, standards are good, but it’s just as important to know why you’re doing something as it is to know what to do in the first place. I think if you added a lot more comments to that file and explained the reasoning behind the advice, it would be a lot more helpful to the people you’re targeting.
2 Likes