4 Tips for Refactoring Your Code for Readability

Поділитися
Вставка
  • Опубліковано 12 чер 2024
  • Sign up for the Level 2 Game Dev Newsletter: eepurl.com/gGb8eP
    Refactoring your code on a regular basis is a good way to reduce technical debt. But refactoring is a skill that can take years to perfect. That's why I focus each refactoring session on a single goal. That goal could be for scalability, testability, modularity, or a number of other things. In this video I'll share 4 tips for refactoring your code for readability.
    Download the project files (Tier 2 Patrons): / 61457305
    00:00 Introduction
    02:30 Sign up for the Level_2 Game Dev Newsletter
    02:59 Example project
    04:00 Tip 1: Be consistent
    06:19 Tip 2: Follow conventions
    08:43 Tip 3: Bake your intent
    12:00 Tip 4: Cut out the fat
    14:10 Conclusion
    💬 Join Our Community
    Discord: / discord
    Patreon: / infalliblecode
    Newsletter: eepurl.com/gGb8eP
    ❤️ My Favorite Unity Assets *
    Odin Inspector and Serializer: assetstore.unity.com/packages...
    Editor Console Pro: assetstore.unity.com/packages...
    Rainbow Folders 2: assetstore.unity.com/packages...
    Peek: assetstore.unity.com/packages...
    Project Search & Replace: assetstore.unity.com/packages...
    ⚡ Unity 3D Plus: prf.hn/click/camref:1100l3e8M/...
    ⚡ Unity 3D Pro: prf.hn/click/camref:1100l3e8M/...
    👋 Contact me directly at charles@infalliblecode.com
    * Disclosure: These are affiliate links, which means I'll receive a commission if you use them to make a purchase.
    👋 Contact me directly at charles@infalliblecode.com
    * Disclosure: These are affiliate links, which means I'll receive a commission if you use them to make a purchase.

КОМЕНТАРІ • 90

  • @mhrohan917
    @mhrohan917 2 роки тому +67

    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

    • @Dfjs427
      @Dfjs427 2 роки тому +3

      One centralized manager that injects dependencies to the rest of the game. Interface segregation and dependency inversion

    • @micaiahstevens8840
      @micaiahstevens8840 2 роки тому

      That 'mod' injection sounds near the ballpark of this, but just sounded cool to learn more about.

    • @themattstrauss
      @themattstrauss 2 роки тому

      @@Dfjs427 yea but how

  • @majlada
    @majlada 2 роки тому +7

    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

  • @houbeenie
    @houbeenie 2 роки тому +3

    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

  • @ElBARTO298
    @ElBARTO298 2 роки тому

    Wow thank you very much. I found this channel and can't stop watching and learning. Super helpful. Will sign up to the newsletter

  • @InfallibleCode
    @InfallibleCode  2 роки тому +3

    🚀 Sign up for the Level 2 Game Dev Newsletter: eepurl.com/gGb8eP
    📦 Download the project files (Tier 2 Patrons): www.patreon.com/posts/61457305

  • @rickyfreddy6963
    @rickyfreddy6963 2 роки тому +3

    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.

  • @jean-michel.houbre
    @jean-michel.houbre 2 роки тому

    Always great advice! I love these videos that help me progress.

  • @phirewind
    @phirewind 2 роки тому +3

    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.

    • @jspesh
      @jspesh 2 роки тому

      Well said, I agree 100%

    • @MrTomateSalat
      @MrTomateSalat 2 роки тому

      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.

  • @mhrohan917
    @mhrohan917 2 роки тому +1

    Right when I needed!

  • @archerist_
    @archerist_ 2 роки тому

    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.

  • @doge9203
    @doge9203 2 роки тому

    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.

  • @asadickens9353
    @asadickens9353 2 роки тому +2

    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!

    • @DJnoratos
      @DJnoratos 2 роки тому

      it is bad example tho.

    • @asadickens9353
      @asadickens9353 2 роки тому

      @@DJnoratos I'm not sure I follow; A specific tip was a bad example? Which tip did you think was a bad example?

  • @Cameo221
    @Cameo221 2 роки тому +1

    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 🙂

  • @joao13soares
    @joao13soares 2 роки тому

    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.

  • @rafa_guitar
    @rafa_guitar 2 роки тому +1

    Very useful video. Thanks so much!

  • @oldman4101
    @oldman4101 2 роки тому

    This channel is gold

  • @Rizzan8
    @Rizzan8 2 роки тому +1

    Ah, a readability topic. Gonna return in a few hours with a popcorn and read the comment section.

  • @sebastianbryant4216
    @sebastianbryant4216 2 роки тому

    Thanks for the amazing content!

  • @rainessandrai8240
    @rainessandrai8240 2 роки тому +2

    Very good summary of stream! But i still suggest the watch stream for more detailed information.

  • @yugoanzai8197
    @yugoanzai8197 2 роки тому

    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

  • @drmucahiderdogan
    @drmucahiderdogan 2 роки тому

    Great content!

  • @simoroshka
    @simoroshka 10 місяців тому +1

    With experience these things become automatic and you start refactoring while you are writing that code :D

  • @oscarreyes1056
    @oscarreyes1056 2 роки тому

    Great video!

  • @ZeroSleap
    @ZeroSleap 2 роки тому

    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.

  • @longuemire748
    @longuemire748 2 роки тому

    Thank you

  • @turkeyjerkey
    @turkeyjerkey 2 роки тому +1

    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!).

  • @BBdaCosta
    @BBdaCosta 2 роки тому +1

    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.

    • @jangohemmes352
      @jangohemmes352 2 роки тому

      I like Uncle Bob's vision on that, I second your reference to it

  • @asembahra6187
    @asembahra6187 2 роки тому

    Thanks for the nice video

  • @NewUnityProject
    @NewUnityProject 2 роки тому

    More videos about refactoring would be perfect!

  • @TChapman500Gaming
    @TChapman500Gaming Рік тому

    What about modifying the player loop to get rid of the need for a GameManager singleton?

  • @barisaxo
    @barisaxo 2 роки тому

    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.

  • @user-rm2gh2gc5f
    @user-rm2gh2gc5f 2 роки тому

    And use guard clause (inver if) where appropriate)

  • @lucasdvs10
    @lucasdvs10 2 роки тому

    is there a video about tips for Refactoring Your Code for extension?

  • @CreativeSteve69
    @CreativeSteve69 2 роки тому +2

    Lateley past couple weeks. I started on learning Game Maker Studio 2 while Learning C along with more python. Been having a blast. :)

  • @nathnolt
    @nathnolt Рік тому +1

    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.

    • @LordOfLemon
      @LordOfLemon Рік тому +2

      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.

  • @club311gaming
    @club311gaming 2 роки тому

    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

  • @m_maksym
    @m_maksym 2 роки тому

    Charles(and Barles) how about a video with tips and usitn new input system?

  • @Bedheadbanana
    @Bedheadbanana Рік тому

    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?

    • @Chubzdoomer
      @Chubzdoomer 10 місяців тому

      The only Vector3 I see (originalPosition) is camel case.

  • @mehmedcavas3069
    @mehmedcavas3069 2 роки тому +1

    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

    • @Dfjs427
      @Dfjs427 2 роки тому

      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

    • @Rizzan8
      @Rizzan8 2 роки тому +1

      So you are a Dictionary personDictionary = new Dictionary(); connoisseur?

  • @jaykinbacon2379
    @jaykinbacon2379 2 роки тому

    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!

  • @ridlr9299
    @ridlr9299 2 роки тому +1

    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?

    • @marlonruvalcaba386
      @marlonruvalcaba386 2 роки тому +2

      when you use serialized they are shown at the editor, they aren't accessed by other script so keeping the underscore is fine.

    • @user-rm2gh2gc5f
      @user-rm2gh2gc5f 2 роки тому

      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.

  • @ZebNoid
    @ZebNoid 2 роки тому

    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.

  • @loganlane7833
    @loganlane7833 2 роки тому

    I love you videos

  • @jeffmccloud905
    @jeffmccloud905 2 роки тому +3

    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.

    • @Dfjs427
      @Dfjs427 2 роки тому

      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

    • @Rizzan8
      @Rizzan8 2 роки тому +2

      Agree. Unity uses C++/Java styles that are abysmal.

  • @purpl3grape
    @purpl3grape 2 роки тому

    I like to refactor scripts into 1 line of code. 😌

  • @darkbatu
    @darkbatu 2 роки тому

    why is better use var?

  • @a_guy_in_orange7230
    @a_guy_in_orange7230 2 роки тому

    Don't suppose you have a video on all the fancy shortcuts you used in this video?

    • @majlada
      @majlada 2 роки тому

      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

  • @dragoNogarbLog
    @dragoNogarbLog 2 роки тому

    11:38 Does the local parameter in the method make Unity GC a lot more. Am I right?

  • @ksviety
    @ksviety Рік тому

    I think, any meta information of a parameter shoud be placed into method doc, rather than into its name, which makes it look ugly.

  • @weckar
    @weckar 2 роки тому

    Is it me, or were the Ss particularly harsh in this video?

  • @marlonruvalcaba386
    @marlonruvalcaba386 2 роки тому +1

    The most painful part of the tutorial is checking the position and orientation at the update.

  • @a_guy_in_orange7230
    @a_guy_in_orange7230 2 роки тому +2

    Refactoring to put the { on its own line. . Yessssssss

  • @MohammadFaizanKhanJ
    @MohammadFaizanKhanJ 2 роки тому

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

    • @Rizzan8
      @Rizzan8 2 роки тому +1

      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.

    • @MohammadFaizanKhanJ
      @MohammadFaizanKhanJ 2 роки тому

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

  • @DJnoratos
    @DJnoratos 2 роки тому +1

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

  • @micaiahstevens8840
    @micaiahstevens8840 2 роки тому

    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]

    • @micaiahstevens8840
      @micaiahstevens8840 2 роки тому

      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.

    • @micaiahstevens8840
      @micaiahstevens8840 2 роки тому

      11:00 you can ALSO, as an option use the comment in between >In seconds

    • @micaiahstevens8840
      @micaiahstevens8840 2 роки тому

      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.

  • @thebag1981
    @thebag1981 2 роки тому

    So get rid of this for the sake of brevity & it’s implicit, but use private despite it being implicit…

  • @ShatabdaRoy115
    @ShatabdaRoy115 2 роки тому

    Where is de time stamps?

  • @KrucLeo
    @KrucLeo 2 роки тому

    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.

  • @CyberAngel67
    @CyberAngel67 2 роки тому +3

    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
      @Dfjs427 2 роки тому

      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

    • @CyberAngel67
      @CyberAngel67 2 роки тому +2

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

    • @Rizzan8
      @Rizzan8 2 роки тому

      @@CyberAngel67 Ah, so you are a Dictionary personDictionary = new Dictionary(); connoisseur?

    • @CyberAngel67
      @CyberAngel67 2 роки тому

      @@Rizzan8 what!