C# Coding Conventions in Unity
Вставка
- Опубліковано 6 лип 2022
- Follow these C# Coding Conventions when learning to program in Unity so that your code is easier to read and understand!
This is the first "byte-sized" clips extracted and edited from one of my full tutorials. If you enjoyed it and want more like it, be sure to let me know by liking the video or commenting below.
ACCESS PROJECT FILES & SUPPORT THE CHANNEL:
💛 / iheartgamedev
iHeartGameDev Merch:
💛 www.iheartgamedev.com
WANT MORE?
Check out the original tutorial this clip is from here:
✅ • How to Program in Unit...
✦ Like the vid? Please consider Subscribing!
bit.ly/2YdIb6j
SOCIAL:
✦ Discord
/ discord
✦ Twitter
/ iheartgamedev
Would you watch a longer video explaining even more coding conventions for programming in unity?
Definitely
Yes to all. I dont think there is any downside to having more content of any kind. The bite-sized videos are good for quick reference, and the longer videos are great for in depth explanation. And if anyone is like me, which I am sure I am not alone, I dont always need the deep explination for the basic stuff and want to get to the more complex stuff sooner, so I can refresh with the short videos and get up to speed faster.
yes/
yup
Absolutely! I need this!!!
Doesn't matter how advanced you are, you'll always learn something on this channel.
Thanks for the videos!!
Thanks for the video. I loved the command pattern video, I hope there are more design patterns explained in the future.
I like short and informative videos like this one, would be great if you could make more of those!
Thanks just what I was curious about for Csharp! Really great channel
Exactly, what I needed, I've been writing a lot of coupling codes, and this was the best help !!!!!💥
Thanks for recommending this video, Dark!
Great job, Nicky!!
Thanks Daniel! Miss you bro!
In my own personal projects, I like using the Hungarian notation. I find it helps me differentiate between the different variables on screen.
Fields and properties should be named in lowerCase, AFAIK.
Build in Unity classes made the same way, for example Time.deltaTime etc.
short but useful video!!
Glad you think so!
I always thought that
private var: _camelCase
public var: camelCase | Without underscore.
I think it should be like that. Lets say you're declaring a variable of type PlayerMovement, if you named the variable the same as the class name, it's not that obvious whether you're accessing the actual class or the reference you have to it.
// This is more obvious
public PlayerMovement playerMovement;
playerMovement.DoSomething();
This is also what I use and what Rider recommends for fields that are visible on the Unity inspector.
And PascalCase for public properties.
Bro u saved me thank u so so so much
Thanks for watching!
So cool!
Thanks!
Thanks
Nice vid mate!
BTW, did you code your outro background video?
Thanks very much! I made the background in Blender!
I remember when I first saw this clip when I first found your channel. This clip forever changed how I coded in Unity and my scripts have never been cleaner. Thank you for making this.
Thanks so much Jasper! 😊
Great 👍🏿
Nice video, that's something that should be used more often by programmers, it's always a hell getting a Unity freelance due to people ALWAYS missing naming conventions and writing poorly named variables, due to that i could never know if its a public, private or local variable
Thanks Gabriel! Hopefully by sharing this info, devs are more likely to abide by the standard conventions!
Sorry, but that's on you. You should provide the conventions(since they are subjective) and enforce them. There are a bazillion tools that do it automatically. So make passing the tools part of the requirements for the work and don't pick low quality programmers.
sometimes i think its Enums that people uses all uppercase like: PLAYER_WALK, IDLE and honestly it looks more unique to enums and little funny
Use this comment to represent that you are interested in "URP/HDRP Explained" video. Big thanks to author for all videos from this channel ;)
No come one, there are so many videos about this topic already...
Are methods and functions two differrent concepts in c#? I thought they're the same thing.
Great little video Nicky, I agree with everything you said.
Thanks buddy! Your short and sweet videos lately had me all inspired!
I've watched your state machine tutorial so much that it's already burned into my memory that this video clip is from there😅
It’s true!
Can you please make a video explaining Unity Timeline
♥♥
In an article on this topic on Unity's github it did not memtion _underscore. I also don't use it because it aggravates readability and makes code ugly.
Within the Unity StarterAssets Third/First-Person Controller the Unity team uses exactly the style as he mentioned here with the underscores. There is also an official article from Unity from 2022 september where they mention the undescores the same way as he does in the video. I guess the underscore is used commonly in C# because there is no "this". So e.g. instead of other languages where you write "this.isRunning = true" it is "isRunning = true" and then underscore makes it more readable "_isRunning = true" so it is clear that its a class variable.
It does help to know that the variable will not be accessed by external code.
It also helps finding the variable faster in intellisense
And with [SerializeField] private... ???
Make a video on how to make ragdoll characters like human fall flat or gangbeast and self balancing them
Was expecting to see a bad coding convention, as in older tutorials you didn't follow them yourself. Yet, a good standard (mostly) one is shown.
Thanks for the great tutorials and best of luck!
If only it didn't matter! Truth be told C# is much easier than other languages so two rules like this isn't crazy bad.
Not bad at all! Hopefully more people abide by the standards!
I agree with majority of stuff mentioned here, except for this one: "always declare static fields on top". This may be the way "you" write your code, but it is definitely not a standard. A standard is to always put instance fields before static ones. Besides this little false convention, all in all, very decent video.
i
I
PLEASE , MAKE A 100 HOURS UDEMY COURSE :/
meanwhile i be writing variables like examplevariable
I use camel case as well in public and protected methods, and pascal case in properties, to denote that properties may execute some code in the getter or setter, and I only use _ for local variables in a function, when I need to differentiate from a global one
If it works for you and anyone who reads the code 🤗
@@iHeartGameDev i find it does fit quite nicely, the only thing is private variables are indistinguishable from public ones inside their own class, but I'm to lazy to type underscores lmao
That is just a sloppy naming convention.
@@alphaanar2651 care to elaborate?
@@ZiplawDev not to throw shade on you, but, using camelCase for *any* public member and underscore for local variables only shows lack of your experience. Reconsider your conventions. Really if you gave your code for a review, the first thing mentioned would be such bad conventions you are following.
I know Unity encourages it unfortunately, but public fields in a class in C# are not recommended. You should use property getters/and setters. Reference: all from the Microsoft docs since 2000... "Fields (C# Programming Guide)" and "C# Coding Conventions" and "Field Design". Public fields are "generally not recommended" and should "used sparingly" and even this: "❌ DO NOT provide instance fields that are public or protected."
Hungarian notation. Anything else is inferior.
Instantly know the scope and type of the variable just by looking at its name.
ALSO CONSTANTS IN ALL CAPS
No, maybe in C and C++, but never in C#. ALL_CAPS is not a convention for anything and it is never mentioned in official pages. Class-level constants are still PascalCase, and local constants declared within a method scope is camelCase.
@@alphaanar2651 It should be though. I would fail all code reviews for my Jrs if they don't haha rip
@@broganking9830 I mean, you may still use ALL_CAPS (or other peculiar formats), it is not a big must to follow standard conventions in the end. But really this naming style does not fit C#, at all. (I subjectively think that it looks too ugly). Maybe it is time for code refactoring ;)
time to do none of these XD
As long as no-one has to read your code lol
@@twillij29 it's not gonna make much of a difference but people are gonna judge me probably
@@BGDMusic No, if people have to read your code then it's good to have some set rules and clarity. I don't know if you have experience going into a project mid-development but it's a nightmare to read code that doesn't have any conventions in place. If it's just you reading it, then it's probably fine.
@@twillij29 it's just upper vs lower and some letters but idc it's whatever
yeah ok you have a point
distinguishing between different types of stuff is good but conversions only do so much
I prefer writing public variables using camelCase, I find it easier to read.
Ew
1:25 trouble in that, what a this is not variables, its fileds
Talking about code convention and you didn't put the bracket of the example method on a new line. Awful video. This guy has no idea what he's talking about.
I have no idea what I'm talking about. Thanks for pointing out the mistake. :)
Worth pointing out that majority, if not all, articles that I've read regarding bracket spacing state that it's a preference as long as it's consistent throughout the project: softwareengineering.stackexchange.com/a/2786
@@iHeartGameDev 😂I love that you dove into more research because of a joke
@@Masticater :) I try really hard not to spread misinformation. Had to be sure I wasn’t 😵💫
@@iHeartGameDev Nevertheless, the official one by Microsoft states that brackets ought to be placed on a separate line. C# is nothing like other languages where the placement of a bracket does not mater. But to be fair, it surely is not a reason to trash this video.
Fields are camelCase properties PascalCase. No _
Is Currently c# meta and in my opinion best to read
The underscore means "this." because in C# there is no "this"