@louis-philip
And remember: "Potential readers of your code" is more than likely going to be YOU in the future.
@MechMK1
I've once seen a variable called qr_t_us_135_uss_t. The variabke name meant "Query result, Table, Users, Using Columns 1, 3 and 5, which are of type unsigned int, string, and string, and the whole variable is temporary". The codebase was a mess
@Cadet1249
In my opinion avoiding duplicate code is often taken too far. You avoid duplicate code if the code has the same reason to change, not just to make it look prettier. If you try to extract every inch of shared logic you’ll end up with high coupling and your code will be even harder to maintain
@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!
@VeitLehmann
I agree 100% with rule 1 and 3. For rule 2, you have to be careful to not split things too early. This could lead to premature abstractions that don't work well in the future. Instead, don't be afraid to rewrite/refactor code early and often. So first keep it as simple as possible, and if some logic is user 3 times or more often, extract it. By then it should be clear what a good abstraction should look like. And because you're in the habit of refactoring early and often, you'd be confident to adjust the logic if the abstraction doesn't work nicely anymore later. So my top priorities for good code are: 1. Write code that's easy to understand 2. Write code that's easy to change
@rhn8696
1. don't deeply nested code and not using inversion; avoid deep nesting by inverting conditionals, merging related if statements, and extracting complex logic into separate methods or functions 2. organize code; prevent code duplication by extracting shared logic into its own functions. 3. don't use naming that only you understand; use clear and descriptive naming conventions to make the code self-explanatory and easier for others to understand.
@jorge_cazares
In my Software class, we learned the following principles: Don’t repeat yourself (DRY) Comment where needed Fail fast (code should reveal its bugs as early as possible) Avoid magic numbers One purpose for each variable Use good names Use whitespace and punctuation to help the reader Don’t use global variables Functions should return results, not print them Avoid special-case code I think this video summarizes many of them!
@formulanova12
1) Avoid nesting by inverting and use functions to simplify 2) Avoid duplicate codes 3) Use understandable names for functions, variables, etc.
@harjeet-music
Watching this video I remembered collaborating with some friends on a school coding project years ago. One of my friends had a proclivity for writing very messy code, using variable names like "habbababa". I asked her on that occasion why on earth she would name a variable like that - and reportedly, "habbababa" sounded "kind of cute". I still find it hilarious up to this day.
@overloader7900
The reason math is poorly understandable is not its inherent complexity, but the fact that mathematicians for some reason are all using single letter meaningless variable names
@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.
@galacticminx
Overuse of these principles (except the naming one) can also be a sign of an inexperienced developer, because they treat them like rules instead of guidelines and only applying when it really does make sense to do so. Overuse of extracting methods would be the most common one - creating a function for the sake of it when it's just a few lines of code that's only used in one place. If the name of the function helps to make the code more readable, this is where a comment would be more helpful than a function call. Bear in mind that calls have performance implications too.
@padcom
There is a lot more to it than just 3 simple laws but I can definitely agree that this is a very good start. Well done!
@sayori3939
the logic inversion is so valuable specially for beginners, usually you create a lot of weird situations and temporal dependencies by not structuring conditons properly
@perfectionbox
Imagine someone writing a program that converted well-written code to badly-written, by nesting, duplicating, and renaming.
@atlas_19
4:33 Bro gave us time to discuss the topic in pairs.💀
@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.
@demonicious_
Separation of Concerns is good but I feel like people sometimes take it too far. So you'll find a function which calls 3 other functions and each of those functions perform only 1 line operations. A rule of thumb I like is that I only extract functionality to another function if it's used in multiple places.
@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