10 Things You NEED to Be Doing in Unity

A collection of vital tips and techniques I use in Unity every day. Some are Unity specific, while some are just good programming practices. Let me know if I taught you anything!
❤️ Become a Tarobro on Patreon: / tarodev
=========
🔔 SUBSCRIBE: bit.ly/3eqG1Z6
🗨️ DISCORD: / discord
✅ MORE TUTORIALS: / tarodev
0:00 Intro
0:08 Serializing components
1:18 Drawing scene gizmos
1:35 Initialization order
2:31 Stop using public fields
4:30 Mod to loop collections
5:04 PlayClipAtPoint
5:55 Limit extern calls with SetPositionAndRotation
6:53 Operator overloading
8:17 Composition
8:56 Don't use lazy naming conventions

[@finn9233]

Every programmer should keep this in mind while coding: "Code is read much more often than it is written"

[@TheClanFollows]

And it is written much more often than it is understood 😂

[@dominikzawlocki3117]

@@TheClanFollows I like this

[@zardify_]

Pls someone tell this to my boss...

[@prppnd3811]

Clean Code by Robert C. Martin?

[@rickloyd8208]

Once I followed the tips from the book you quote, the speed of writing increased significantly! It's kind of less stress on your brain =)

[@bike_n_fish]

I've also a tip for beginner : don't over focus on optimisations, instead make your game. If your game is not optimised, you can do it later. But if your game is not working because you spent too much time implementing good practices and well designed patterns - over commenting your code, you gonna loose precious time and energy. When you are experienced and you know what are the pros and the cons of using a specific method you will automaticly try to use the best of it. Bu when you're a beginner, just make the game.

[@hiakofficial8180]

Man you've saved me, I realized i was doing the same thing, i wanna go with the best practice so my didn't have to write the code again

[@benjamindameworth5351]

The only optimization you should do along the way is optimizing the way your code is organized. If you don't organize your code it becomes unreadable for future you

[@heyreefes]

My ass looking thru five hundred methods to make the character move so I can have the most optimised and best one

[@thracco]

As a hobbyist dev im actually glad you made a video for the naming conventions. It wasn't until way later that i would read the subject from a book and wouldn't pay much attention to it. Also a not so beginner Tarodev tutorial that I understand! Kinda proud of myself!

[@Tarodev]

You're turning pro ;)

[@Shorkiedokey]

I'm a bit confused, because I name functions with PascalCase, should I name functions and public variables the same way? What would you say it's a good way to name them? Thanks.

[@Tarodev]

@@Shorkiedokey function should always be PascalCase 😊

[@Tarodev]

​@@nikolicd91 I use standard C# conventions. The way unity does it is inferior and has a bunch of convention collisions. Unity should have enforced proper C# conventions from the beginning, but didn't. In addition, Unity uses a wide range of conventions, even in their samples and live events, so you really shouldn't use them as a benchmark for coding conventions.

[@RealisiticEdgeMod]

I use syntax highlighting instead of these ugly underscores. Just make local vars a different color.

[@stephenkirby6788]

My man rolled out of bed, threw on a shirt with a hole in it and started spitting C#/Unity knowledge. Love it. Great video!

[@shenlong3879]

One minor issue with the modulo approach to index cycling is the index variable isn't really an index anymore, more like a counter, and related to that you could potentially run into overflow issues with really big numbers (not that it's really all that likely).

[@YassineZaroui]

Isn't the Modulo also a bit slower?

[@gregoryfenn1462]

Absolutely, to give a simplified example of the problem: suppose we have x a uint8_t (unsigned 8 bit int). Then define "i = (x++ % 5)". Starting from x=0 we have i = 0,1,2,3,4,0,1,2, ... but when x is 255 we have i = 0. Then when x increments it goes from 255 to 0. But that means i is 0 again, so the pattern breaks whenever x overflows. Of course in most games we use uint32_t or sint32_t, so this won't happen for a long time. But if the counter goes up several times a frame, it will still overflow after a few minutes or hours which can create a hard to detect bug later down the line. So for me I would always explicitly wrap an integer back to 0 manually rather than rely on modulo operators.

[@houtamelocoding]

@@YassineZaroui Maybe? Branches are also slow so the proper way of knowing this would be benchmarking.

[@saniel2748]

@@houtamelocoding Modulus can't be predicted, it's just a very slow operations. Possibly one of the slowest math operations you can have And Mono is also not smart enough to replace '% 2' with '& 1' That said, hundred of modules per frame, most certainly, won't change your FPS in any meaningful way

[@sewminadilshan7223]

Your videos have the highest knowledge density. Never fails to amaze me in these short videos.

[@PitiITNet]

So nice to see you getting back to releasing videos And on the last point - I think there is a special place in hell for people that say "I code for 35 years and do not use naming conventions" 🤣

[@Tarodev]

No farm sim, just felt compelled to draw a cute cow for the video, which ended up taking longer than the video itself... I always seem to do that :D Thanks mate!

[@anlozge1788]

@@Tarodev cute indeed.

[@Tarodev]

@@anlozge1788 Me or the cow? ;)

[@PitiITNet]

@@Tarodev BOTH!, So you have drawn it all yourself?! :o That's impressive!

[@Tarodev]

@@PitiITNet Nope, background was from Adobe Stock + Gaussian. I did draw the cow, with heavy reference art though.

[@jamjardavies]

A quick note with the mod to loop collections section. Using mod like that does have 1 bug with it, and that's the clipIndex could wrap once it hits Int.MaxValue, causing it to not loop correctly, and also since the int is signed, it'll eventually crash once it hits the negative values. Instead I would write it as _clipIndex = (_clipIndex + 1) % _clips.Length, then index directly using _clipIndex.

[@TheKr0ckeR]

That was question in my head actually. Since the game is very long for example, IDX value will get so much higher values. So in first example, we reset the value to 0 which even if its a long way, still proper way. I was trying to find a better way to reset idx.. But your example seems legit.

[@generichuman_]

@@TheKr0ckeR If it's a 32 bit unsigned int, and it's incremented 60 times a second, it'll take about 2.26 years to overflow. That's a long time to run a game.

[@Dorbellprod]

Dude I had no idea that Unity serializes properties, thanks

[@funlightfactory6031]

OMG! Using the modulus for iteration to avoid overflow is mindblowing. It was so obvious I don't know why I didn't think of it.

[@Tarodev]

But now we have the problem of overflowing the int :P Only use it if you know it won't (99% of cases it won't).

[@Nullzero98]

As for naming conventions, I agree that they are quite important! Good on you for pushing them! But I don't find it all that useful, in Unity, to know whether something is public, private, or local via a naming convention. Partly because Visual Studio automatically color codes the different scopes. But mostly because the scope for most component based scripts is so small anyway. Occasionally you get a big 5k line PlayerScript or something... but most other scripts are what... 30-100 lines? So why bother with scope naming. What DO I find useful for naming conventions then? GameObjects, Prefabs, Component refs, types and spaces. GameObjects => "go" prefix. goBullet. goPlayer. goEnemy. No more confusion about what an object is or isn't. Prefabs(onDisk) => "prefab" or "pf" prefix. No more guessing if a GameObject reference is actually a GameObject or a disk reference. Components => "cp" prefix. cpBullet. cpPlayer. cpEnemy. cpAnimator. etc. Just by the variable name, I know which component it is, and which functions I can call on it. Transforms => "xf" prefix. xfBullet. xfPlayer, etc. Types, ie Vector3 vs Vector2 => I put a v3 or v2 in front, respectively. v2PlayerPos for 2D game. v3Direction, etc. And yes, for floats, ints, strings, as well. Spaces, ie WorldSpace vs ViewPort vs ScreenSpace etc. v3PlayerPosWS is a world space position. v2BulletDirXZ is a direction but in XZ axis only (ie, top-down shooter). v2MousePosSS for mouse cursor position in screen space. This will save your sanity. Keep the tips coming! Love it!

[@Tarodev]

Good write up. I like the idea of prefixing their types. I do it for some things, but not necessarily a prefix, for example: _scriptableUnit _projectilePrefab

[@Nullzero98]

@@Tarodev this is the way, my friend!

[@Etherealscorpions]

I definitely see where you're coming from with naming by type, but if you're asking for help on forums, or helping people on forums or similar, then the scope naming conventions - or at least, being able to quickly explain your variables' scope to a third party - makes it much easier on everyone involved.

[@badscotsman]

What you're referring to is called Hungarian notation.

[@johnhershberg5915]

A lot of people disagree, but I stopped using naming conventions altogether. I use PascalCase for everything. What I noticed was that it was wasting brain resources thinking stuff like "This serialized field has the health set from the editor, and it's at 100 by default, but on this enemy it's 120, and I'm taking damage which comes from the function parameter which right now is 70, and multiplying it by this locally scoped variable..." etc etc. Instead when I'm parsing logic, all I should care about is the logic. Pretty much never do I care about where it comes from. So what I want to instead be thinking is "Health is 120, and I'm taking 70 damage, and multiplying that by 2". Historically the reason for underscores is so if you need your IDE to show you the top-level stuff (serialized fields in our case) you could just type _ and it'll bring up IntelliSense for those. But in my personal opinion that's a distraction these days. If you're back to reading code after a long time it's probably because something is wrong. You should be focusing on the logic of what's happening in the function rather than where things are coming from. Just my humble 2 cents. It sounds weird, but try it and see for yourself.

[@badscotsman]

Great video! Love love love that you covered the naming conventions again and didn't back down! Soooo important for the exact reasons you mentioned. ❤️

[@pianoatthirty]

Dude you are SO INSPIRING! Happy to see you back! You should totally do a 'let's build a small game from start to finish' type course where you implement these good practices! Would instantly buy it.

[@Tarodev]

Funny you say that... 😉

[@ishan9050]

The mod to loop collection was sick Awesome 👍

[@1Tasteless]

Agreed. Going to save me so much time in the future.

[@pythonxz]

That one made me realize that I need to use modulo more. It's an elegant syntax.

[@Meow_YT]

Not really. That variable is now unbounded and will wrap around eventually, with possible issues if the compiler has checks on integer overflows not known about?

[@ishan9050]

@@Meow_YT interesting point. Definately will have a look. Thanks for the mention

[@goehlergamedev]

Coding conventions are so important. Even as a solo dev. This last one is a great tip! Always remember: readability is king. It's SO important for the person who will read your code next. And you SHOULD care about that person - cause 9 out of 10 times, that person is you! 😁

[@tobihendrix1324]

Quick note: The "public Type Variable => ReturnValue;" Syntax creates a readonly property, so its not the same as having "public Type Variable {get;private set;}". The difference is, that the readonly property cannot be changed even by the instance itself, it has no setter.

[@Tarodev]

You're completely right, thanks for the correction!

[@bread8176]

The value can still be changed by directly modifying the field it accesses, so in *practice* it is the same. (unless you mark the backing field as readonly as well)

[@Erkle64]

@@bread8176 Same in what you can do. Different in how you can do it.

[@trollgasm]

Thank you for this one. I'm trying my best to get industry standard coding, and stuff this goes above and beyond. You are so far out of the hundreds of youtubers in this category that is unequivocally straight to the point and the most professional. Looking forward to diving into more of your videos.

[@BenVanTreese]

Along the lines of naming conventions, one thing I think can be really useful is writing out booleans as lines above the check, for example: var jumpWasPressed = Input.KeyDown("Space") if(jumpWasPressed) { //do jump stuff} The code itself is a comment, and it prevents comments/code from getting out of sync. This is of course a broader topic about variable names in general, but that's one I do that I think would benefit a lot of code since it explains the "why" of the boolean/etc in many cases. Also, if the variable is within a function scope and you're not returning it or etc, it's not allocating (on heap) or etc, so there is no real performance difference.

[@WatchingTokyo]

This is great advice. This kind of technique allows to clarify what it is we meant to be testing.

[@pasta8026]

You are my favorite gamedev tutorial KZbinr! All your videos are very helpful for me!

[@Tarodev]

And you're my fave commenter of today!

[@Unity3dCollege]

Great video! all perfect advice, and reminded me about the serialized properties :)

[@thomaskluck4164]

Thanks a lot for those hints. I am a fan of not making it harder than it is. Plus: Programming is the art of making yourself not lose track of the things you are doing. The very first thing I came up with was to separate variable scopes through naming conventions. This makes life a lot easier.

[@b4ux1t3-tech]

I kept typing out comments to add to what you were saying, only for you to go on and say exactly what I was going to say! I'm a software developer by trade, and work in C# on a daily basis, building an enterprise product. Whenever I sit down to learn something about Unity, I end up spending a bunch of time griping about how I don't get the latest c# features, and critiquing (in my head) the actual C# code that's used in many of the tutorials out there (including first party ones!). It's really refreshing to see someone using C# to its fullest, great video!

[@marcusaasjensen]

Overriding the + operator is pure genius!

[@eusouoervilha]

Loved the part on naming conventions. In addition is good to remember always to give useful names for the variables, that also makes all the difference.

[@DePistolero]

Thank you, every second from your every video is pure gold diggin... thank you!!! And thank you for the naming convention, I've had my fair share of confusion, bugs, and misreads due to wrong use of naming convention... Thanks for serializing a property, the mod wraparound thing and operator overloading... so useful, and more importantly so nicely explained... thanks.

[@JoshOClock]

I like having the convention that every 'prefab' I reference for instantiation is ALWAYS a gameObject then I never worry about having to change it's type and losing all my references. But that's just a personal choice. Great video!

[@user-rl2ox1bu4c]

Agree with this one. Good video though.

[@KonaiNobi]

100% agree on the Naming Convention point. I personally use the following; public Type variableName (Camel Case) private Type _variableName (Underscore Camel Case) public/private void MethodName(Type value) { var variableName (Camel Case) } This allows instant identification of public variables, private variables, and methods, not just for scope but functionality as well. All function-scoped variables are camelCase as they are easily identifiable as local within the scope of their parent method. While the author, whom I have deep respect for, recommends using PascalCase for public variables & properties, I however, find using PascalCase only for MethodNames makes it impossible to confuse methods with similarly named properties. Just my 2¢. 😁

[@omle8492]

There was so many “ohhhh this is so cool” moments

[@Tarodev]

Mission accomplished

[@sn0man]

Great video, all helpful tips for beginners and old timers alike. Thanks again and keep doing your thing Tarodev!

[@Tarodev]

You know what? I will

[@greyfireocelot6140]

Naming Conventions have always helped me quickly solve coding issues that crop up during projects, I didn't realize so many people didn't use them until I started entering GameJams.

[@iwoMalki]

Great stuff! Thta tip with position and rotation really f'ed me up! Been using unity for years and never knew that function existed!

[@er.unsaid7766]

I'm with you regarding naming conventions.

[@Tarodev]

And I'm with you

[@soverain]

Finally, a new video! And a good one for sure. As a senior dev, you reminded me of the operator overloading and the neat tricks you can do with them. You could do a video on extension methods (like advanced level). I saw some seriously good sh*t with them. Duck typing in C# is a very cool feature.

[@Tarodev]

I actually have a video on extension methods... Ancient though. Don't remember how advanced I made it

[@soverain]

@@Tarodev Yeah, I remember, but that was not so advanced, still very useful.

[@NihongoWakannai]

10:20 When it comes to naming conventions, people don't really mention a convention for naming function parameters. In my experience, I have personally found it more convenient to tell the difference between an injected value vs a value held or created by this object than anything else. People just lump local variables and function parameters together, but to me I just feel like a variable potentially injected from another class should be distinguished from a local variable, especially when using ref/out. I feel like C# standard naming conventions aren't really made for game development, because it puts more emphasis on identifying public vs private variables when I just don't use public variables for game development. The 3 categories for me are class values, function values and injected values.

[@phee3D]

great tips, I didn't know many of these even though I've been working with unity for 2-3 years. For naming conventions, I use "m_varName" for private variables, uppercase initials for public variables, underscore for parameters and lowercase for locally scoped vars. It greatly improved the readability of my code for my own sake.

[@TaAnderson-Google]

The. Return. of. the. King! Good to see you, Sir. Thank you for the tips, the helpful details, and the easy to understand ways to impliment them. As always, I'm happy to see your video, and I'm looking forward to both your upcoming ones, and your larger projects. Good luck and good health.

[@Tarodev]

Long time no see!

[@AetherXIV]

you always teach me a lot and make me a better programmer. thank you Taro

[@bluestek]

Man you are my favorate youtube unity knowledge master! I had no idea they added serialization of get set properties! Keep up the good work!

[@Tarodev]

Only on properties with a backing field, just be aware 😄

[@Fresch1990]

Wow... 3:44 Serialized 'Properties' is huge... I didn't notice that change and I really appreciate you mentioning it. It always bothered me to write a full propery to conform to Unity and C# coding conventions..! Thank You!

[@Neonalig]

I probably knew the majority of these already, but using the [field:SerializeField] attribute to specify that the backing field should be serialised on a property is actually ingenious shorthand. Thank you so much!

[@jmarsh411]

Same!

[@ravd123]

Another great no nonsense vid :) Took away so many tips from this. Thx

[@trashcaster]

It's funny because the naming conventions, I've always flipped local and private from what you do, but there is another benefit to doing it your way. If you are in your IDE and you type "_" then your private variables will populate the IntelliSense popup, and not your public, which can be handy for setting variables that no other scripts will have access to, since it will still look pretty on the outside, but remain easy to read and write on the inside. I also did not know about overloading the operators, that is indeed a VERY cool trick. It's a tier above extension methods, which are already S tier. Thank you for making this video, I always look forward to them!

[@firstvf]

Thank you so much! your videos are always a treasure trove of incredibly useful information🙂 And serialized get-set property - its awesome!😎

[@Tarodev]

That one's my bread and butter

[@kevinscaglioni8020]

As always, awesome video man. Cheers

[@calccalccalc]

Your hot tips are always welcome mister tarodev

[@papafhill9126]

The naming convention thing is pretty smart. I do underscore for local and lowercase for all others, but I'll start testing uppercase for public going forward. Thanks for the tips!

[@ShinichiKudoQatnip]

I feel so good now that I know I have been doing these for quite some time now, and better to know the things I totally missed, thanks for the heads up 😘😘

[@iHeartGameDev]

so much KNOWLEDGE! Awesome video, Taro -- I specifically liked the phrasing at the end with coding conventions: "would have gotten along a little bit better" 😆

[@Tarodev]

Makes it a bit tricker for them to bite back at me 😁 Glad you enjoyed it, Nicky!

[@ErtBaran]

08:57 I was confused about this. Now i'm done! Thanks so much for this and the others.

[@freelancepakistangames7245]

I've been using unity for quite a long time and did not know most of the tips in this video. Thank you sir🥰

[@Tarodev]

Welcome :)

[@magnusm4]

Composition sounds a lot like the structure in ECS. Where an entity is given components. Rather than inheriting from another entity. I built a similar composition system for my hierarchical state machine. Where I have one state that only holds states. So that I can add a state for camera actions, a state that handles controls etc. Separating actions and features which also hold their own stats to do their own thing. While the core values "transform, camera, rigidbody" called context. Are all on the player for all states to access.

[@mailmaxxxx]

Love your work. One thing I find hard teaching students is the naming conventions - partly because Unity seems to just randomly capitalise stuff, so my rule is to stick to my naming convention (essentially the C# Microsoft recommendations) and just accept that Unity is different!

[@Tarodev]

This is my way too Maxy boy...

[@Fyres11]

Naming convention is indeed a good idea. I do try to go a step further by adding some details in the var name itself. so_something for scriptable, go_something for gameobject, etc.

[@Tarodev]

This is very interesting. I can certainly see this being beneficial

[@pythonxz]

I add prefixes for my filenames, but that's a good idea too.

[@PPSzB]

It's called a hungarian notation and many people advise against using it, especially when using modern IDE. One of the downsides is you have to remember to change variable name when you change its type (like in the GameObject and Carrot example)

[@cfinger1093]

These are always super useful, thank you! keep making them plz. Cheers.

[@MarceloSantos-rk5ee]

Great tips, thank you!

[@seaweeddol8171]

I really appreciated the section about naming conventions! I've been following a lot of tutorials that use the same conventions you mentioned, but I didn't understand why people always used _ in some variables, or capitalized others. I'm definitely going to follow this more now.

[@Tarodev]

You'll be happy you did :)

[@BLANKdev]

I was wondering where that naming convention video went, glad to have it back because I coudn't agree more and have been using it myself ever since!

[@Tarodev]

Fills me with joy to know I converted you

[@BLANKdev]

@@Tarodev it really is that much better sorry everyone 😬

[@TheShelfman]

That last tip felt like a direct roast to me😂 and it hurts even more to acknowledge that you're completely right. There's a some great tips in here! Thanks😁

[@sadbuttrue666]

Love it. Thank you very much man. (twenty years of dev and 3 years in Unity here)

[@Tarodev]

You're very welcome Servaus 🙏

[@shuffle8]

Thank you so much for sharing. It's really informative and helpful 🙂

[@ZacMarvinGameDev]

This channel is always pure GOLD!

[@pythonxz]

I'm glad you said that people really need to use inheritance when it fits the situation. Always use the tool that seems the most appropriate. As for naming variables (or really anything in code), do not abbreviate unless it is very obvious what it stands for. I've also seen far too many people leaning on comments to explain a function, when naming the function something more descriptive would do just as well.

[@Tarodev]

People can get carried away, you know?

[@migcreatesgames2622]

Excellent Tips! I didn't think about DrawGizmos for spawn points. I been doing the inspector gizmos and complain about the size, but now for sure I will start with drawgizmos instead

[@dizmo..]

I rarely write any comments, but you are just too good. I wanted to thank you for all of your videos, which helped me a lot in game-development. Keep quality of your work on high level, man, thats why we enjoy it! I recommend this channel for every developer i know. Cheers from UA game-dev Community!

[@Tarodev]

Damn. Thanks dizmo 🙏

[@ziccodx]

Yes, please follow naming conventions ^^, it's immensely helpful and expediates the process of reading code.

[@harshitjoshi3082]

Great video man 👍

[@omaralashtar7587]

Good work man . We waiting alot of time ,just dont forget us and upload this great video 😄😄

[@b5fan504]

+1 for the naming conventions. Thank you.

[@marcmustermann1676]

Great content as usual. Extra points for the sporty look today.

[@Tarodev]

Ready for action at all times

[@syedmeesumalizaidi2152]

Nice to see you back buddy... Great...Mind-blowing

[@Tarodev]

Thank you Syed 🙏

[@castlecodersltd]

Great video with some useful tips. Thanks ☺

[@quentinyahia352]

Thanks for the video, always a good thing to see we can still learn something. For the code convention, I just notice I don't use the underscore private field just because jet brain color the local as white and the private / public as green (dependends on theme ofc)

[@halivudestevez2]

nice tips and trixx, again!

[@ezrahuffman]

I've been using unity for a while and still learned something, so thanks!

[@zeiksz]

Lot of good stuff here. Thank you!

[@zeiksz]

I tried this property -> field thing, because that was new to me, but worked only if it was basic like public int Teszt { get; set; }, but once I did something like [field:SerializeField] public int Teszt { get => teszt; set => teszt = value; } int teszt; it no longer showed in the inspector. The goal was to call event in the setter, etc. Any idea, what I did wrong? Or is this a bug/feature?

[@mehmedcavas3069]

yesss knew all of them :D great video again :)

[@w0mblemania]

Very good point about privacy levels. If you want solid, clean, maintainable code that will serve you and your customers in the years ahead, then design your code with an API mindset. i.e. start with PRIVATE on most everything. Encapsulate EVERYTHING. Then, you provide a public interface to those workings, which the rest of your app uses, ONLY for those things that are needed. I suggest reading 'Writing Solid Code' by Steve Maguire. It's old, but timeless. It's the bible for making quality, maintenance-friendly software.

[@tomasmartins5009]

The naming conventions tip is actually the best here. I am a hobbyist unity developer but a professional C# user for a decade and it always hurts seeing tutorials here on KZbin with people just mixing everything together.

[@msj6894]

Your video is always great! Thank you so much :)

[@avg_ape]

Thanks for the tips - esp for the naming convention tip.

[@muammar88]

Dude, I can't believe I didn't know most of these! Thanks for sharing!

[@quintongordon6024]

That serialize property tip. Been waiting for that for a while.

[@chris.davidoff]

I clicked because the thumbnail is so good. I stayed because this is very useful lol

[@Bolt3006768]

The naming conventions I use were taught to me in my CS courses. Cap class publics, mCap for private class variables, then lower for local variables. I sometimes use a fourth convention specifically for counters which use usually an _ or C_

[@Tarodev]

As long as there is something in place to save you that extra parsing step, you're doing it right.

[@MuhammadHosny0]

use C99 naming conventions.

[@samserious5483]

Thanx, very useful!!!

[@davegillie6074]

I think you approached the subject of naming conventions with humility and grace while still holding a strong opinion. I respect that, and I used to agree with you! However, time and exposure to different code bases and people who write code have changed me, and now I think that talking about naming conventions is a distraction from the real problem. When people argue in favor of naming conventions it always goes the same way. "When I'm looking at a big function with lots of variables dancing around with the same naming convention, I have to look harder to tell what's going on." If a function is so big and messy that it's hard to tell what's going on unless differently scoped variables have different naming conventions, then the function should probably be cleaned up. The way I see it, . Why not focus on the real problem of the big messy function/class? There were 2 times in my life when I felt strongly about naming conventions. 1) When I was fresh out of college feeling like I knew how everything "should" be. 2) When I get handed scripts written by scientists/researchers/non-coders and enforcing naming conventions is easier than teaching them how to write clean code. This video is great, and I watched till the end because I learned from it. My hope for this comment is to convince you coders that your battle is with big/messy code, not naming conventions. Choose the right battle.

[@disrate]

Thank you for this useful video :)

[@davidpoussif6944]

Great videos! Would be great to see some videos from you explaining UniRX, Zenject or MVC

[@exceptionaldifference392]

Good stuff, thanks.

[@viniciusrusso3552]

As a new dev I constantly need to go back to my codes to change something cause I learned a better way to do it, and I found myself lost in my own code several times. naming conventions not only saves time but also its way less stressing if, as I, you're coding for 3-4 hours after your 8hr job. definetelly will implement these

[@ucagdascoskun]

Good content, thanks!

[@mmokzlrsn]

This video is pretty good. I learn a lot thanks to you

[@fleity]

At first I wanted to complain about the title being too clickbaity, I didn't expect to learn much new stuff but wtf get set fields can be serialized?! Your videos never disappoint. This is amazing.

[@Xankill3r]

The single method call for setting both Position and Rotation is actually very recent (in at least 2021 LTS). They added it just a couple of patches back - 2021.3.11f1 I think.

[@Tarodev]

Makes sense why I've only just discovered it, I guess 😁

[@Deadener]

For real? I could have sworn I've seen it since like 2018. edit: Yep, I've found threads on it dating back to 2017. It was added in Unity 5.6.

[@Xankill3r]

@@Deadener you're right. I mixed it with the get method for position and rotation which was added in 2021 LTS. Plus the set for both added to TransformAccess.

[@Nullzero98]

Great tips. Especially the field: serializedField tip, and the lambda short-hand. Will be using both of those for sure! As for Prefabs, they are awful to deal with when it comes to the Inspector. Easily one of the hardest parts of Unity for beginners to understand. The fact that Prefabs are called Prefabs, but can be serialized as Components and GameObject fields in the Inspector is so confusing. I really think they should just have a PrefabFile type or something, and any serialized field declared as PrefabFile should only allow references to prefabs saved on disk. Yes, you lose flexibility, but that's the point... no level or game designers shooting themselves in the foot by dragging the wrong thing into a generic GameObject field.

[@MrZtapp]

Great tips

[@L0upyb0y]

Something which I don't see listed in the summary is enabling advanced play options in the editor settings. This allows one to choose whether to reload stuff or not on play, which most of the time isn't needed if you're just working on level-design for instance. It'll most likely save most devs precious seconds when entering playmode. Remember to disable it when working on advanced features though!

[@Tarodev]

I actually have an entire video dedicated to this 😘

[@Gabahulk]

GREAT video!

[@doommustard8818]

My general recommendation is to have a naming convention and stick with it. It doesn't matter which convention you use, but if you're in a group use whatever the group's convention is.

[@Tarodev]

I totally agree. In the real world you shouldn't barge into an established group and try change their conventions. Certainly fight for a good rule set if you're there at conception though.

[@doommustard8818]

I like to name functions/methods with Capitals private begin with _ Events begin with On *Listeners begin with When scoped variables can get away with not being descriptive because I don't have to look at code I'm not currently working on to know what they're doing so I don't have a convention for them other than comments on their definition *If the listener is solely used as a listener and too complex for lambda notation

[@NoTimeLeft_]

How about this Tarodev: ONE thing you SHOULD be doing for KZbin. Do you see what I did there? Do you remember quaternion? Pepridge farms remembers

[@Tarodev]

You better watch your mouth, Gonzo

[@NoTimeLeft_]

You're a good sport T. But I'll just call myself gonzo the quaternions and then you'll never get to me Mwwahahhahahahah