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
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.
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!
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.
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 🙂
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.
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.
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.
No. You should follow the standard of the platform or your team. If you're working on a Unity project, you should follow Unity standards and then C# standards. Some of the recommended standards are absolutely terrible anyhow
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
I thought so too for a long time. I started using them a few weeks ago and I can't go back now. It doesn't seem to bother me, most of the time I couldn't care less if something is an int or a string if the var name is descriptive enough. You'll always know that a variable called 'name' will be a string, or that a var called 'amount' will be a number of some sorts, usually an int but it rarely matters when you're just reading through the code
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!).
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.
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!
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.
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!
What's wrong with var there? Do you really care that it's a float? It's common sense that Random.Range returns float and that Vector3 takes it as a parameter
@@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.
