@louis-philip
And remember: "Potential readers of your code" is more than likely going to be YOU in the future.
@nicky5185
I'm leading a project which consist of migrating old PHP code. I found up to six levels of nesting, functions with bodies of more than 3000 lines (yes, three thousand), copy-paste engineering galore and many, many other issues. They blame PHP, but I blame the programmers, who even today still write very sub-standard code
@TheDriftingStig
I remember watching this video while I was an intern at my current company. 3 years later, I can say that this video has helped me so much. I'm writing very clean code thanks to you!
@AdidasDoge
2:46 I feel like the if statement that checks if it is a valid user does not need to be in its own method, as it is literally two lines of code. I get that making it into its own method would allow whoever is reading the code to instantly understand what the if statements are for, but another part of clean readable code is conciseness and being succint. If we are adding another two lines of code that doesn't actually much affect the readability of the code, then it isn't very necessary.
@atlas_19
4:33 Bro gave us time to discuss the topic in pairs.💀
@mongky9903
From my experience, there is some addition rules: - Abstract logic of large part of code into a function is good but when that part is only used 1, 2 times then it is better to not abstract it - Adding assertion is good when developing a new function - Always calling function with explicit parameters name. For example fn(a = 1, b =2) is better than fn(1, 2)
@AD-wg8ik
I’m not inexperienced but I stayed for your animations
@madezra64
The first law is such a massive game changer. I have a PowerShell script that was orchestrated by our RMM to manage Bitlocker standards for our customer endpoints. The first version, while stable and worked, was just so messy... I had no idea how bad nesting can get, ESPECIALLY when you walk away from your code and come back a year later with your brain filled with entirely different implementations. I looked back on my v1 code after getting far better and did exactly what this video showed, especially the first law! I then applied this to my monitors for our AV and it's been a night and day difference in terms of maintaining and troubleshooting my own work. If you could only watch one part of this video, the first law should be your choice (except this is hypothetical so listen to it all :) )
@etni_dev
Very good tips, but I like to keep the conditionals more granular. It's easier to write better log messages or throw more specific error codes
@fuzzychest
DRY gave me so many problems early on. I abstracted everything, always. The idea is not to do that, and really, never to do it first. You want to abstract business logic where it makes sense, and, I would do so as an iteration/refinement. Not on a first pass. Good design decisions early can alleviate having to do this too much. But don't be afraid to repeat yourself if it makes sense or if there are too many clauses to your business logic. And, for God's sake, ALWAYS repeat yourself in tests. Verbosity in tests is much appreciated.
@whatever7338
Extracing is a double edged sword. You now need to find the function, understand it, remember it and keep it in your head while youre trying to understand what follows after it. Also if its something simple then the function is pointless. The only reason to extract something is if youre using it multiple times. Also that first example for extraction it would be much better just having bool isValidUser = ...; if(!isValidUser){} right next to each other.
@xwrn
Here's terms for what the video is talking about, so folks can look up more about them. 0:50 "Early Exit" or "Early Return". 2:00 The "Extract Method" Refactoring. 4:00 "DRY" "Don't Repeat Yourself". And the Extract Method refactoring is a great way to implement it.
@Zaro2008
1:46 All fine and good until you run into an auth error and can't figure out if it's an authentication or authorization problem. Don't do this!
N/A
@CodeAesthetic a little bit of history: the designer of C# is the one who designed Delphi, and he used I for naming interfaces in Object Pascal. It is from a time when we didn't have a Intelisense nor mouse over highlight of the object properties in the editor.
@RegrinderAlert
It’s worth noting that the first example refactor changes the program behavior- they are not equivalent. It needs additional return statements in the guards .
@yutubl
@1:20 pre-if-checkings is a readable practice, but your example refactoring changed its behaviour! If error case when one of the if error conditions is true and a message is logged the original code didn't execute the for loop with its inner logic, your code logs and runs the for loop.
@HerbertLandei
I see some people complaining about the code extraction. In the example, I would do a similar extraction, but for another reason. Avoiding code duplication is a nice side effect, but the core idea should be: Keep the abstraction level of a function or class or whatever constant. An example: You don't want a function dealing with structuring a report page doing regex stuff, this is clearly too low-level. Think about how you would explain your function with a few words to your colleage: "I look if there is a report header, else I use the default, then I add the body, and if there is a footer, I include it as well". And that's what the function should do. If it does some finicky stuff with the body, extract it. If it does some regex, definitely extract it, maybe even a level deeper, below the functions dealing with the header, body or footer. Having one abstraction level is much more important for readability than to avoid code duplication.
@TheNotedHero
Even easier: submit for review and listen for the WTFs/min statistic. If it's under 2, your code is fine.
@ajcgpol
The "merge related if statements" example you gave is in fact a bad advice. Authentication and authorization are different things. You are not just "losing granularity", you are shooting your foot with a wrong log message. You'll waste time trying to solve an authentication issue thinking it's an authorization issue.
@kantancoding
For those of you that are confused about me not using a return statement in the first example, it's because `log.Fatalf()` actually exits the program e.g.: ``` // Fatalf is equivalent to [Printf] followed by a call to [os.Exit](1). func Fatalf(format string, v ...any) { std.Output(2, fmt.Sprintf(format, v...)) os.Exit(1) } ``` Sorry if it made the example a bit confusing! ref: https://cs.opensource.google/go/go/+/refs/tags/go1.22.4:src/log/log.go;l=417