Would be great to see a video on code structure and Connections between Differnt types of Manager Scripts. Mainly How things are connected cleanly in a game
These new type of video's from you are exceptional. They are not only professional and helpful because of the obvious good preparation, but mostly because of the way you speak. You are a really good speaker with a great charisma and combined with how clean everything else is it makes it easy to follow and understand. I don't have to pause the video and think about what you are saying or rewind it because I couldn't hear you properly. Well done and thank you. If school teachers were like this I would go to school the rest of my life.
I like all these tips! Definitely some good places to start on your refactor journey. Everyone should remember that these are TIPs on how to refactor! So always review your coding situation!
Some of my code comments in my current business software work are to highlight things that are non-obvious solutions to a given problem for those who come after me, but those are the least important comments in that codebase. The most important comments aren't the WHAT, because just like you said, if the code is written well then the WHAT should be fairly straightforward. Instead, it's the WHY, especially in business logic software. I've said this elsewhere, but I've spent days trying to figure out why something was even being done, only to discover it was some business procedure decision made years ago that created the problem that needed to be solved in the first place. Without knowing what the non-software-related reason for doing something was, it seemed like a really dumb solution to a problem that didn't exist. It was still a dumb solution, but knowing why it existed gave us insight on how to structure the new version of the software properly.
The WHY can become answered by checking the git-history for that code-block. If the commit-message isn't enough then one should follow the ticket-id which should be part of the commit-message. The Ticket/Story/Task should describe the why. Not the code. In worst case I would ask the ProjectManager about given Behavior and if he sees a reason for it. The why can change and if you bake it into your code it means, that it can lie. The only thing in code which is telling the truth is the code itself. I would never trust any comment in code either (as mentioned) because requirements can change and/or because comments are rarely become updated. Over 90% of code comments which I've seen are code smell.
Thanks, luckily I already learned these from your past videos. I also learned how to use unit test to make sure my code is working even after refactoring.
Glad to get validation that I'm doing things right already! Also following whatever rider already recommends anyways, haha. But I really strive for organisation, it always feels good to know that something is always in order 🙂
That refactoring stream was how i found this channel today, and watching the Common Mistakes video was eye opening. You guys legit have the best tutorials with design patterns and stuff. I wanted to ask if you guys could make a video about the UI toolkit and UI documents, im trying to learn them and im kinda overwhelmed.
I really appreciate everything in this video and will save it as a "good coding practices go-to reminder", although I already follow most of the practices. One thing I won't probably abdicate is adding "this." whenever possible. I find it helpful to instantly see that I was referring to a component from the game object where the script is running from.
One tip that Uncle Bob says in his classes about naming conventions is that "the name of a variable is proportional to the scope that the variable is in". That way if your scope is one line maybe the variable can have one character, so in my point of view try to explain everything is not better to readability.
Excellent video! So how hard was it to create the original code, which didn't conform to your coding standards, so you could refactor it? lol Personally, I can't write code that doesn't conform to my long-developed coding standards (and I'm with you on explicitly adding 'private' to variable declarations, since I work with multiple languages, and the default for them all isn't private!).
Nice video :) for the, after the code style and conventions, what makes readability easier is breaking a big class into smaller classe. Basically the single responsbility principle. The problem in this case is when you break down too much and the classes comunication between each other starts to get too complex
Pro tip: for naming/coding conventions for C# and .NET, follow Microsoft's Guidelines on the subject which were established back in 2001. Unity inadvertently encourages violating many of them. Fight back.
I've heard you mention in passing that you don't like summaries, I think it was in one of your live vids, but you moved on before having a chance to explain why. I'm curious to hear your thoughts on summary documentation.
I would've not made an extra function (MoveToStartingPosition), but rather put a comment above, and maybe put it inside of a block. Functions can be good, when they are called multiple times, but often times, having functions, splits up where the code is and you need to scroll forwards and back in order to follow it, which is harder than if the code is just right there. Of course, functions which do what their name is and don't produce any side effect don't have this problem. Also simplifying the code, to just do the thing, in the least complicated way is the most important thing, and much more important than code style, unless the code style has shit indentation.
I mean, you can always control+click to go into the function. It's not as complex as you make it out to be, and having everything segmented into tiny functions means that the code is easier to debug.
And here i am, being very pround of all my summarys in my codebase so i know what the methods do after some time. Welp i guess if the code would be more readable i didn't need those
Charles: Imagine reading a book where each page used multiple font families, paragraph sizes, and margins. Me: Why just imaging it? Read "House of Leaves" by Danielewski Mark.
You mentioned that private serialized variables shouldn’t use an underscore. Is that the same for straight up public variables? What about properties with getters and setters?
Public, protected and private fields with attribute are all serialized fields and must obey one naming convention. Rider also forces this rule. Properties is Pascal case.
Little known secret. Unity not only hides the underscore, but you can classify a variable as a meta-data only datatype by using "m_" prefix in your variable name. The letter "M" will be invisible in the inspector view!
I think this is a Vim extension in jet rider? Not sure, but learning Vim is one of those things that if you do actually spend time getting to grips with it, you can never come back
If you are writing comments then maybe your code is required refactoring. Remember with Robert C. Martin said, "A long descriptive name is better than a long descriptive comment."
Summaries (comments) are good for public stuff when creating a documentation for a library. Also Robert C. Martin says many things and then violates it in his code examples - he uses abbreviations like there is no tomorrow, while he is against them in his Clean Code book.
@@Rizzan8 Develope do compromises despite knowing good practices. Its common. Most of the time we know that we are doing bad code. This happens often due to short deadline and different other factors. I never saw that someone said clean code is not right book.
Hi. I can already say that this code is not well written and should NOT be an example. Why? 1) You should not directly write code in if conditions, but rather put it to boolean function example: If (!isPositionCorrect){} 2) Using Else is also bad code structure structure. Use Return rather 3) You do not even have filled description for your params, yet you use the summary anyway...
5:05 manually editing code like that, does a HUGE disservice to your users. That just teaches BAD habits from the start. VS Community is free, and am SURE other editors can do similar, but I put my cursor on the end of a class of namespace and redo the } and it will reformat the ENTIRE file to use my preferred standard of { } on a new line, OR on the previous line if that is your standard. AND fixes all spacing and tabbing. (prob multiple ways to accomplish this.) 5 seconds, vs 50 seconds. Do I wish, probably does, have an ENTIRE project/solution reformatter, sure. BUT its faster than manually editing code. TALKING about those differences, might be better than doing them. [Gets to this in the 3rd chapter, but feels better to address this first, than say LETS manually edit first]
7:40 should mention Unity Editor has its OWN code style, regardless of what you THINK it should be, NOT sure if you can change this. Personally I like this, as I don't have to worry about _ and uppercase/lowercase because it simplifies that. I don't remember the exact style. BUT its def there.
11;54 (BAD day to watch this HAHA) If your going to refactor that RandomForceVector, HELPFULL Micaiah (I wouldn't) but some random programmer is going to add a RandomVector to your library, instead of not realizing its already there, just poorly named.
Get component in property... Coruotines... I see the author makes a genuine effort to do a good job. However, I don't see this passing a code review in a production environment. Do take it with a grain of salt.
I have to say that a couple of things I have to disagree with, the first being inspector private variables. I used what you said you are trying and opted back to the convention because deep in the code, it gets hard to decipher if it's a local scope variable or global private. With even small code, it takes a few seconds to work out that variable and its intent, and thats the key. So Inspector Private or standard private, should be treated the same. Jason Storey, he has a habit of pushing is agenda, and I have to disagree with all his ways here. Especially Naming the methods, like you xxxxxCoroutine shows more intent than just CO does. Also at the 11:47 minute mark... Really, we are going to use lazy programming here, and use var? I know your IDE has the ability to show it as being a float, but come on, use var as they are intended to be used!
@@Dfjs427 var was only created for use for anonymous types, any other usage is just pure lazy programming. Because it is easier to just type var and be done with it, in a lot of situations, there is more intent to read the evaluated right side to understand what is being returned. The video is about refactoring for readability and how it shows intent, and yet he uses the var in a lazy situation. C# would have been better without the var contextual keyword, but without it we couldn't have anonymous types.
Would be great to see a video on code structure and Connections between Differnt types of Manager Scripts. Mainly How things are connected cleanly in a game
That 'mod' injection sounds near the ballpark of this, but just sounded cool to learn more about.
@@Dfjs427 yea but how
loving this channel, this is so sleek and clean. the amount of effort on display is very unique among other unity related guides. great video
Sweet, you followed up on the idea. Helped me a lot to tweak and adjust my way of refactoring. Thanks as always! Never too late to learn :D
Wow thank you very much. I found this channel and can't stop watching and learning. Super helpful. Will sign up to the newsletter
These new type of video's from you are exceptional. They are not only professional and helpful because of the obvious good preparation, but mostly because of the way you speak. You are a really good speaker with a great charisma and combined with how clean everything else is it makes it easy to follow and understand. I don't have to pause the video and think about what you are saying or rewind it because I couldn't hear you properly. Well done and thank you. If school teachers were like this I would go to school the rest of my life.
I like all these tips! Definitely some good places to start on your refactor journey.
Everyone should remember that these are TIPs on how to refactor! So always review your coding situation!
it is bad example tho.
@@DJnoratos I'm not sure I follow; A specific tip was a bad example? Which tip did you think was a bad example?
Some of my code comments in my current business software work are to highlight things that are non-obvious solutions to a given problem for those who come after me, but those are the least important comments in that codebase. The most important comments aren't the WHAT, because just like you said, if the code is written well then the WHAT should be fairly straightforward. Instead, it's the WHY, especially in business logic software. I've said this elsewhere, but I've spent days trying to figure out why something was even being done, only to discover it was some business procedure decision made years ago that created the problem that needed to be solved in the first place. Without knowing what the non-software-related reason for doing something was, it seemed like a really dumb solution to a problem that didn't exist. It was still a dumb solution, but knowing why it existed gave us insight on how to structure the new version of the software properly.
Well said, I agree 100%
The WHY can become answered by checking the git-history for that code-block. If the commit-message isn't enough then one should follow the ticket-id which should be part of the commit-message. The Ticket/Story/Task should describe the why. Not the code. In worst case I would ask the ProjectManager about given Behavior and if he sees a reason for it. The why can change and if you bake it into your code it means, that it can lie. The only thing in code which is telling the truth is the code itself. I would never trust any comment in code either (as mentioned) because requirements can change and/or because comments are rarely become updated.
Over 90% of code comments which I've seen are code smell.
🚀 Sign up for the Level 2 Game Dev Newsletter: eepurl.com/gGb8eP
📦 Download the project files (Tier 2 Patrons): www.patreon.com/posts/61457305
Thanks, luckily I already learned these from your past videos. I also learned how to use unit test to make sure my code is working even after refactoring.
Very good summary of stream! But i still suggest the watch stream for more detailed information.
Glad to get validation that I'm doing things right already! Also following whatever rider already recommends anyways, haha.
But I really strive for organisation, it always feels good to know that something is always in order 🙂
Right when I needed!
That refactoring stream was how i found this channel today, and watching the Common Mistakes video was eye opening. You guys legit have the best tutorials with design patterns and stuff.
I wanted to ask if you guys could make a video about the UI toolkit and UI documents, im trying to learn them and im kinda overwhelmed.
I really appreciate everything in this video and will save it as a "good coding practices go-to reminder", although I already follow most of the practices.
One thing I won't probably abdicate is adding "this." whenever possible. I find it helpful to instantly see that I was referring to a component from the game object where the script is running from.
Very useful video. Thanks so much!
10:35This coroutine example uses both naming convention and intent.Nice!Things like this should be in the naming conventions of a Unity dev team.
One tip that Uncle Bob says in his classes about naming conventions is that "the name of a variable is proportional to the scope that the variable is in". That way if your scope is one line maybe the variable can have one character, so in my point of view try to explain everything is not better to readability.
I like Uncle Bob's vision on that, I second your reference to it
Always great advice! I love these videos that help me progress.
This channel is gold
Ah, a readability topic. Gonna return in a few hours with a popcorn and read the comment section.
Excellent video! So how hard was it to create the original code, which didn't conform to your coding standards, so you could refactor it? lol Personally, I can't write code that doesn't conform to my long-developed coding standards (and I'm with you on explicitly adding 'private' to variable declarations, since I work with multiple languages, and the default for them all isn't private!).
Nice video :) for the, after the code style and conventions, what makes readability easier is breaking a big class into smaller classe. Basically the single responsbility principle. The problem in this case is when you break down too much and the classes comunication between each other starts to get too complex
Pro tip: for naming/coding conventions for C# and .NET, follow Microsoft's Guidelines on the subject which were established back in 2001. Unity inadvertently encourages violating many of them. Fight back.
Agree. Unity uses C++/Java styles that are abysmal.
yes! Was writing my code like this except for using vars. I don't like them because I think they are hard to read and understand :D
So you are a Dictionary personDictionary = new Dictionary(); connoisseur?
With experience these things become automatic and you start refactoring while you are writing that code :D
Lateley past couple weeks. I started on learning Game Maker Studio 2 while Learning C along with more python. Been having a blast. :)
More videos about refactoring would be perfect!
I've heard you mention in passing that you don't like summaries, I think it was in one of your live vids, but you moved on before having a chance to explain why. I'm curious to hear your thoughts on summary documentation.
Thanks for the amazing content!
Thanks a lot.
I would've not made an extra function (MoveToStartingPosition), but rather put a comment above, and maybe put it inside of a block. Functions can be good, when they are called multiple times, but often times, having functions, splits up where the code is and you need to scroll forwards and back in order to follow it, which is harder than if the code is just right there. Of course, functions which do what their name is and don't produce any side effect don't have this problem. Also simplifying the code, to just do the thing, in the least complicated way is the most important thing, and much more important than code style, unless the code style has shit indentation.
I mean, you can always control+click to go into the function. It's not as complex as you make it out to be, and having everything segmented into tiny functions means that the code is easier to debug.
What about modifying the player loop to get rid of the need for a GameManager singleton?
And here i am, being very pround of all my summarys in my codebase so i know what the methods do after some time. Welp i guess if the code would be more readable i didn't need those
Charles: Imagine reading a book where each page used multiple font families, paragraph sizes, and margins.
Me: Why just imaging it? Read "House of Leaves" by Danielewski Mark.
Thank you
You mentioned that private serialized variables shouldn’t use an underscore. Is that the same for straight up public variables? What about properties with getters and setters?
when you use serialized they are shown at the editor, they aren't accessed by other script so keeping the underscore is fine.
Public, protected and private fields with attribute are all serialized fields and must obey one naming convention. Rider also forces this rule. Properties is Pascal case.
is there a video about tips for Refactoring Your Code for extension?
Great video!
Charles(and Barles) how about a video with tips and usitn new input system?
Little known secret. Unity not only hides the underscore, but you can classify a variable as a meta-data only datatype by using "m_" prefix in your variable name. The letter "M" will be invisible in the inspector view!
And use guard clause (inver if) where appropriate)
Great content!
Thanks for the nice video
It’s mentioned we use Pascal case for public member variables but 7:39 we make the private Vector 3 pascal case rather than camel case. Why is that?
The only Vector3 I see (originalPosition) is camel case.
Don't suppose you have a video on all the fancy shortcuts you used in this video?
I think this is a Vim extension in jet rider? Not sure, but learning Vim is one of those things that if you do actually spend time getting to grips with it, you can never come back
If you are writing comments then maybe your code is required refactoring. Remember with Robert C. Martin said, "A long descriptive name is better than a long descriptive comment."
Summaries (comments) are good for public stuff when creating a documentation for a library. Also Robert C. Martin says many things and then violates it in his code examples - he uses abbreviations like there is no tomorrow, while he is against them in his Clean Code book.
@@Rizzan8 Develope do compromises despite knowing good practices. Its common. Most of the time we know that we are doing bad code. This happens often due to short deadline and different other factors. I never saw that someone said clean code is not right book.
I think, any meta information of a parameter shoud be placed into method doc, rather than into its name, which makes it look ugly.
Refactoring to put the { on its own line. . Yessssssss
Is it me, or were the Ss particularly harsh in this video?
11:38 Does the local parameter in the method make Unity GC a lot more. Am I right?
No.
The most painful part of the tutorial is checking the position and orientation at the update.
I love you videos
why is better use var?
Hi. I can already say that this code is not well written and should NOT be an example. Why?
1) You should not directly write code in if conditions, but rather put it to boolean function
example: If (!isPositionCorrect){}
2) Using Else is also bad code structure structure. Use Return rather
3) You do not even have filled description for your params, yet you use the summary anyway...
5:05 manually editing code like that, does a HUGE disservice to your users. That just teaches BAD habits from the start.
VS Community is free, and am SURE other editors can do similar, but I put my cursor on the end of a class of namespace and redo the } and it will reformat the ENTIRE file to use my preferred standard of { } on a new line, OR on the previous line if that is your standard. AND fixes all spacing and tabbing. (prob multiple ways to accomplish this.)
5 seconds, vs 50 seconds. Do I wish, probably does, have an ENTIRE project/solution reformatter, sure. BUT its faster than manually editing code. TALKING about those differences, might be better than doing them.
[Gets to this in the 3rd chapter, but feels better to address this first, than say LETS manually edit first]
7:40 should mention Unity Editor has its OWN code style, regardless of what you THINK it should be, NOT sure if you can change this.
Personally I like this, as I don't have to worry about _ and uppercase/lowercase because it simplifies that. I don't remember the exact style. BUT its def there.
11:00 you can ALSO, as an option use the comment in between >In seconds
11;54 (BAD day to watch this HAHA) If your going to refactor that RandomForceVector, HELPFULL Micaiah (I wouldn't) but some random programmer is going to add a RandomVector to your library, instead of not realizing its already there, just poorly named.
I like to refactor scripts into 1 line of code. 😌
So get rid of this for the sake of brevity & it’s implicit, but use private despite it being implicit…
Get component in property...
Coruotines...
I see the author makes a genuine effort to do a good job. However, I don't see this passing a code review in a production environment.
Do take it with a grain of salt.
Where is de time stamps?
I have to say that a couple of things I have to disagree with, the first being inspector private variables. I used what you said you are trying and opted back to the convention because deep in the code, it gets hard to decipher if it's a local scope variable or global private. With even small code, it takes a few seconds to work out that variable and its intent, and thats the key. So Inspector Private or standard private, should be treated the same.
Jason Storey, he has a habit of pushing is agenda, and I have to disagree with all his ways here. Especially Naming the methods, like you xxxxxCoroutine shows more intent than just CO does.
Also at the 11:47 minute mark... Really, we are going to use lazy programming here, and use var? I know your IDE has the ability to show it as being a float, but come on, use var as they are intended to be used!
@@Dfjs427 var was only created for use for anonymous types, any other usage is just pure lazy programming. Because it is easier to just type var and be done with it, in a lot of situations, there is more intent to read the evaluated right side to understand what is being returned. The video is about refactoring for readability and how it shows intent, and yet he uses the var in a lazy situation. C# would have been better without the var contextual keyword, but without it we couldn't have anonymous types.
@@CyberAngel67 Ah, so you are a Dictionary personDictionary = new Dictionary(); connoisseur?
@@Rizzan8 what!