C# Coding Conventions in Unity

[@iHeartGameDev]

Would you watch a longer video explaining even more coding conventions for programming in unity?

[@trzrekzii9361]

Definitely

[@HalcyonVoid]

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.

[@mracipayam]

yes/

[@gamegrade8279]

yup

[@mihaianca8602]

Absolutely! I need this!!!

[@keryan1374]

Doesn't matter how advanced you are, you'll always learn something on this channel. Thanks for the videos!!

[@howdy_official]

Fields and properties should be named in lowerCase, AFAIK. Build in Unity classes made the same way, for example Time.deltaTime etc.

[@hakanviajando]

Thanks for the video. I loved the command pattern video, I hope there are more design patterns explained in the future.

[@uwinhong]

short but useful video!!

[@iHeartGameDev]

Glad you think so!

[@Choco-sk2gj]

Thanks just what I was curious about for Csharp! Really great channel

[@theGreaterAwareness]

In my own personal projects, I like using the Hungarian notation. I find it helps me differentiate between the different variables on screen.

[@gg_ru]

I like short and informative videos like this one, would be great if you could make more of those!

[@jasperjavillo686]

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.

[@iHeartGameDev]

Thanks so much Jasper! 😊

[@tPlayerioT]

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

[@epiksol_]

Great job, Nicky!!

[@iHeartGameDev]

Thanks Daniel! Miss you bro!

[@umapessoa6051]

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

[@iHeartGameDev]

Thanks Gabriel! Hopefully by sharing this info, devs are more likely to abide by the standard conventions!

[@Giga4ever]

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.

[@laniakeadev.2271]

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.

[@Andrew-tl9gk]

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.

[@euden_yt]

It does help to know that the variable will not be accessed by external code. It also helps finding the variable faster in intellisense

[@sir.niklas2090]

I always thought that private var: _camelCase public var: camelCase | Without underscore.

[@aleksapetrovic7088]

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();

[@euden_yt]

This is also what I use and what Rider recommends for fields that are visible on the Unity inspector. And PascalCase for public properties.

[@kruth6663]

Are methods and functions two differrent concepts in c#? I thought they're the same thing.

[@through-it]

Every method is a function, but not every function is a method. Method exists only in a class context.

[@darkdoom907]

Exactly, what I needed, I've been writing a lot of coupling codes, and this was the best help !!!!!💥

[@iHeartGameDev]

Thanks for recommending this video, Dark!

[@RazerFlexing]

Bro u saved me thank u so so so much

[@iHeartGameDev]

Thanks for watching!

[@Tarodev]

Great little video Nicky, I agree with everything you said.

[@iHeartGameDev]

Thanks buddy! Your short and sweet videos lately had me all inspired!

[@sergiosoba]

And with [SerializeField] private... ???

[@artimelessGames]

A bit late but i guess you name it with an underscore because the variable is private to others classes (you can just change its value in the editor)

[@ElboxD]

Nice vid mate! BTW, did you code your outro background video?

[@iHeartGameDev]

Thanks very much! I made the background in Blender!

[@ZiplawDev]

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

[@iHeartGameDev]

If it works for you and anyone who reads the code 🤗

[@ZiplawDev]

@@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

[@alphaanar2651]

That is just a sloppy naming convention.

[@ZiplawDev]

@@alphaanar2651 care to elaborate?

[@alphaanar2651]

@@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.

[@litemystic]

Can you please make a video explaining Unity Timeline

[@beninjensin]

Make a video on how to make ragdoll characters like human fall flat or gangbeast and self balancing them

[@ВалерийГеннадьевич-в6ц]

Use this comment to represent that you are interested in "URP/HDRP Explained" video. Big thanks to author for all videos from this channel ;)

[@Andrew-tl9gk]

No come one, there are so many videos about this topic already...

[@VEETEEGameStudio]

I've watched your state machine tutorial so much that it's already burned into my memory that this video clip is from there😅

[@iHeartGameDev]

It’s true!

[@alphaanar2651]

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.

[@charlesonis3484]

So cool!

[@iHeartGameDev]

[@bunzy5279]

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.

[@iHeartGameDev]

Not bad at all! Hopefully more people abide by the standards!

[@scoontaquex3388]

Thanks!

[@jeffmccloud905]

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."

[@Angel-eg8xm]

PLEASE , MAKE A 100 HOURS UDEMY COURSE :/

[@Balakademi]

Thanks

[@rusluck6620]

meanwhile i be writing variables like examplevariable

[@weckar]

i

[@iHeartGameDev]

I

[@quaintgamestudio6149]

Great 👍🏿

[@kensteelyhuntergames484]

1:25 trouble in that, what a this is not variables, its fileds

[@mohsenmousavi2313]

♥♥

[@MichaelGGarry]

Hungarian notation. Anything else is inferior. Instantly know the scope and type of the variable just by looking at its name.

[@hellfim]

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!

[@BGDMusic]

time to do none of these XD

[@twillij29]

As long as no-one has to read your code lol

[@BGDMusic]

@@twillij29 it's not gonna make much of a difference but people are gonna judge me probably

[@twillij29]

@@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.

[@BGDMusic]

@@twillij29 it's just upper vs lower and some letters but idc it's whatever yeah ok you have a point

[@BGDMusic]

distinguishing between different types of stuff is good but conversions only do so much

[@Chronomatrix]

I prefer writing public variables using camelCase, I find it easier to read.

[@alphaanar2651]

Ew

[@broganking9830]

ALSO CONSTANTS IN ALL CAPS

[@alphaanar2651]

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.

[@broganking9830]

@@alphaanar2651 It should be though. I would fail all code reviews for my Jrs if they don't haha rip

[@alphaanar2651]

@@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 ;)

[@mw3653]

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.

[@iHeartGameDev]

I have no idea what I'm talking about. Thanks for pointing out the mistake. :)

[@iHeartGameDev]

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

[@Masticater]

@@iHeartGameDev 😂I love that you dove into more research because of a joke

[@iHeartGameDev]

@@Masticater :) I try really hard not to spread misinformation. Had to be sure I wasn’t 😵‍💫

[@alphaanar2651]

@@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.

[@flaschenzuglp9994]

Fields are camelCase properties PascalCase. No _ Is Currently c# meta and in my opinion best to read

[@Andrew-tl9gk]

The underscore means "this." because in C# there is no "this"