This video is an excellent example of what uncle Bob mentioned in his book about being pragmatic with your own clean practices. All your tips are in the book, and the tips you don’t judge it to be good you just don’t have to use. People flame uncle Bob with the “functions shall be short” tip, but they forget the pragmatism mentioned by Bob in the introduction of the book.
You made me realise that my JavaScript code was complete doodoo and made me redo it all again. This time I actually understood what I was trying to do. Thank you.
Thank you Connor!!! I am forever dealing with "code smells" because people are not taking the time to do clean code. And I always end up cleaning up THEIR mess when I have to do the daily merge of everyone's code. 😭
Try and make it their problem, that is, try to get the teammates to use the same principles as you want to. That way you are less burdened when doing merges and they get their stuff merged with more ease and probably learn from it. Where possible / feasible, use linting and code guidelines to automate the guidance.
I'm not sure if it would be another principle worth considering, but over the last year I've stopped dealing with the traditional try/catch error handling construct and instead return results and if my code throws an exception it is an "unhandled" exception to terminate the app (I'll have a hook into unhandled exceptions so I can log it before crash). You can think of it like Zig's "panic" feature. I just find the traditional try/catch something that makes code execution more difficult to reason about. I also use error codes so if the caller of a function received an error it's easier to check the error code for certain kinds of errors that can be handled or possibly panic. If I'm using a library that subscribes to the try/catch paradigm then I'll wrap it around my own thing that hides that construct (and only expose the things I use from the library). Probably not perfect and, I'm sure, the methodology would conjure up some discussion and debate but it has made my experience more fun and the code I write a bit more iron clad.
Great clear video 👍. But to be honest, the majority of the examples are covered by using a good ESLint configuration. Add some Prettier on top for the spacing / formatting.
Thanks for video! Principle #6: I think you have forgotten to mention about direct returning the value instead of placing it to const and then returning it Principle #7 I think better naming for the second variable would be TAXABLE_TRANSACTION_MULTIPLIER
this video slaps. I'm a huge believer that optimization should come only went a bottleneck presents itself, and in all other instances making code that is human readable is paramount. To assume how the code will be ran on the hardware, especially in javascript of all things, and attempt to pre-optimize is a fools errand. What is vastly better is easy to digest at a glance human readable code, where you can intuit how it should be used and how it can use extended and maintained. Great stuff!
Nice list. For #1, I actually prefer writing the last conditional with an else statement and no return statement. If I have fresh eyes on the code, my first question would be "why does the child version have a return"
Regarding Optimization. In more than 20 years writing Production Java code for one of the largest international banks, I have had to optimize my code twice. The first time a change to the XSLT library implementation made processing take 50x longer. Simply adding a line of code to set an undocumented but supported flag returned to normal. The second time, Dodd Frank caused volume to increase 10x overnight. Because I had written the worker code to be reentrant all I had to do was change config parameter # of workers from 1 to 16 to increase throughput 10-fold (and add an extra CPU core and run code analysis and deadlock detection overnight). Bottom line: Just write Clean Code and - as Conner says in the video - let the compiler worry about the insignificant local optimizations that are such tempting distractions; that's its job, not yours.
Nice video, thanks! Straight to the point! In principle 9, I think that the example was not very good regarding the 2 loops VS 1. Reduce can be a little hard to get used to, but once you do, it's really easy to read and understand what it does. I used to chain array functions as you did here, but mainly because I never took the time to work with reduce. Now it's just easy, and if you have big arrays, loop twice VS once is really not a good idea.. I agree thaw trying to be clever while programming does not make sense, but reduce is just a basic array operator 🤷🏻♂️
Not sure I agree with 9, i'll take that reduce instead because if we apply this rule, you'll see people chaining filter map sort and such which is rather messy imho
1b) using exptions for flow control is not a good idea. Additionally showFullVersion and showChildrenVersion are alternatives. With new style it looks like showChildrenVersion is a kind of error handling. 5) you introduce a new method and increase complexity. Methods will be used. So someone will use it to log something else or even abuses it. And then other logic is coupled. You couple business logic of three methods. It they are independent than its a bad idea. It you want to make sure that they behave equally -only then - its a good idea. 8) such things can sometime be a good soliution. Especially if setting the var area later is costly. for instance if your are in a database transaction than this can be good. Or is you process an image and updating it later would mean to run through millions of pixels again. All other points are ok.
@@maelstrom57 using Exceptions for flow control is an anti pattern. (btw. cuddled else is never a clean code, especially with intendation of 2. And for the latter: showChildrenVersion is on the same abstraction level like showFullVersion. As I said: if there are barely any children than you construction is kind of ok. That is what i mean as kind of error handling. That a child wants to see this site is an error so to day. But if there are equally amount of children and adults than both methods are on the same level. They are alternatives. And a ternary operator (or a switch if more than two) would be a better solution than.
some ai will be doing all of this in a year or two, max. The only people that will have jobs are lead developers in management positions (to dictate what AI needs to do). Junior or mid level will be completely obsolete. If you're about to start programming in 2024..... you're most likely not going to land a job in a few years, be aware.
Good examples. But using exceptions in validation code will throw a lot of exceptions in a large system. They will clutter the application monitoring and hide the actual problems. In addition, exceptions are expensive. Invalid user input is expected.
@@memeproductions4182 Validation should be handled by usually telling the user what went wrong, which means not throwing an error, but rendering some kind of message to the user (sending JSON response, printing to screen, etc...); it doesn't make sense to crash your application because of invalid user input lol. But to be fair, all of his examples are oversimplifications for the sake of teaching a specific concept, so we can cut him some slack.
== for null checks === for everything else This just ensures you check for undefined as well, and is generally the preferred practice of most style guides / tech companies.
@@ConnerArdman it's better to have clearer code than rely on the odd behaviour of !=. So if (user.age !== null && user.age !== undefined) { } or if (user.age) { } are better options.
It's really a matter of opinion, but I would disagree. Some prefer explicit checks for undefined, but personally I find it to just be a little clunky. It's also just easy to forget to also check for undefined, whereas eslint can remind you to always do == null to solve for that problem. The industry is somewhat divided on this, but every team I have ever worked on at tech companies big and small preferred == null. As an example, here' is Google's JavaScript style guide stating the same opinion: google.github.io/styleguide/jsguide.html#features-equality-checks As for the second option, I actually think this is an objectively bad practice and one I have seen cause real bugs in production. For example, your check of if (user.age) is presumably meant to be the same as above, to check that the value exists. However, what if the age is 0? 0 is falsy, so we wouldn't get into the if check. In some instances this may be what you want, but in others it isn't. I would generally avoid relying on truthy/falsy for this reason, as even if it is what you want, it is isn't particularly obvious and readable code.
Prefer wrapping loose equality operator in a function: `isNullish` - quite popular in TS. Then it's clear to team you intend ==, rather than being questioned at code review time or eslint squawking at you (eqeqeq rule)
@@ConnerArdman if you're reading from the DOM this isn't an issue as you'll always get a string, otherwise in my opinion it's better to be explicit and check for null and undefined.
0:00 1. Eliminate if/else branching; early termination 2:16 2. Ambiguous definitions: ‘is’ function prefix to denote boolean return 4:05 3. Self documenting code: avoid belaboured comments 5:37 4. Consistent formatting. Use Eslint + Prettier to automate code style 7:14 5. DRY business logic. Look for opportunities to refactor. Make sure to test! 8:37 6. Fail or exit functions fast. Related to 1. 9:28 7. Avoid magic values - declare and use CONSTANTS instead. 10:41 8. Avoid violating single responsibility. Prefer to use pure functions (no side effects) 11:57 9. Overly clever code (code golf). Leads to impenetrable single liners (have to rewrite in order to debug) 14:00 10. Premature optimisations.
The isPrime example, you use Math.sqrt in the condition, this will in many languages, including js, cause the sqrt to be calculated on each pass of the loop so you should break that out to a variable and the comment can then be added to the creation of the variable, this will make it even more clear that the comment is for why we use Math.Sqrt and improve performance and reduce line complexity since the loop conditional will be a simple i
Over commenting. I’m in university and I have to comment everything line for line and have a massive comment block on the top explaining how it works overall. Why is this taught if that many comments is actually a bad thing?
Actually learning how to comment is a skill that is difficult to teach. Your prof’s approach is likely because he is just a tad lazy, but is also not totally terrible. As long as your comments aren’t just rewording the code, you’re doing ok. Explain the thinking behind it, why a more obvious approach isn’t valid, etc. Have fun!!
When you are writing a comment, think about the why not that what. The code already does and should be written in a manner that what is doing is clear. There are occasions that a “what” type of comment is needed. For example, the algorithm is complicated and long, or obscure, or using some hidden feature that it’s not so easy to understand by just looking at the code. Normally, a comment like is more useful when the piece of code is doing something that it’s not common for the environment/industry.
#1 Mostly agreed, but I think the last part when there are two ways of ending function, one with return and the other one with no return is more confusing than just one else statement #4 There was a semicolon missing in one line ;)
13:14 the reason why the bitwise expression is confusing in that example is because it evaluates to a number, 1 or 0, instead of true or false. Js deals with truthy/falsy for conditional expressions so it still works, but it should really evaluate to a boolean if being used in a conditional, e.g. n & 1 !== 0 Great tips otherwise 🔥
"easy to understand" vs. "more performant" while I agree, creating code that is complex for the sake of convolution is bad. I am not in agreement with easy to understand code should be used over performant code. Just comment your complex functions or lines stating what it does. In applications that are running 100s or 1000s of actions these things don't really matter. When you're running millions of actions asynchronously sometimes milliseconds matter.
Bad Performance is often a result of poor data structure usage, or api calls, etc. VS something like “how should I sort this array”. In these cases I easy to understand is preferred imo.
The code at 5 got made worse IMO. Before three functions encapsalated 3 actions you can do. Now logAction takes in some ambigous param action and I got to read the function to have any clue what it's doing
Just a small addition on the example of DRY; what's covered here is to replace three functions that do the same thing with one function that can do anything. If you want to enforce the passed-in value is always one of a specific set of strings, it should still be fine to use these other three functions. They can cover an abstraction, enforcing the passed "action" to be a specific value. Such as "return logAction("logged in")" in the first example function.
Yep. DRY is dangerous advice because many times you don't repeat yourself but rhyme. Code should be allowed to rhyme, if it isn't then you've created an abstraction layer that will need logic. In worst case in the abstraction layer. And the more rhyming code you try to fit in the more logic you need, thus the abstraction starts growing and growing and growing. Don't repeat yourself. But don't be afraid to rhyme.
I have been coding since 1969 and constantly learning. With ober 13 Lang under my best (1st love is assembly on a mainframe) I always agonize over "is it readable?" If not them clean it up! I write with the intention that someone else may have to maintain this. I also never take code personally, as I have seen many coders do. Instead I will show my code to others and ask them "is this easy to understand?" If the answer is no, I need to fix it. On each function, I place "function notes block" which are a block of comments, right before the function definition. It describes why the function is used, all the variables used, along with global variables, and in the case of assembly, what registers are touched or referenced. I used to run the code through a custom print program to output all these "function note blocks" to be used along any documentation I have. It shows the functions sorted alphabetically, the module they are in along with the line number where they are defined. Comes in very handy when something goes wrong
Nice video, I agree with most of your principles. But I disagree with #8. I think modifying global variables is totally fine most of the time. And I think functions can and should do lots of things if it makes sense. I find the "single responsibility principle" to be silly. Long functions are much better than a bunch of small ones. #9 example is tough to see. I think both examples look equally "readable". #10 is solid advice
Well in code interview it's lame but they dont care about clean code, they just throw you with random interview question which does not represent the job of a developer. Wish you good luck on your next interviews, you got this !
Your first advice was fine until you reach the test on the age, where it doesn’t hold anymore and really makes no sense. Inverting doesn’t provide anything useful and actually removing the else here makes the code look a bit weirder. The rule is that nesting should be done when it makes sense, and early-return on errors is fine, but the rest feels like you’re trying to apply a General Fundamental Ultimate Rule™ and really you should not take things to heart like that.
2:25 If it is just the comparison of two numeric values, then why we are sending the object to this utility function? Namely, that function does not need to know how the "length" of a "password" object is retrieved. Rather the place that is taking care of the business logic already know what password object is and how its length can be retrieved, so we can directly send the value instead of the object. With doing so we can convert this utility functions into a library which would not be depend on any object (e.g. StringUtils in Java Apache Commons). Plus, minimum password constant value can be retrieved from another constant util class's function instead of directly referencing to the variable from a function, so that the checkPasswordLength does not need to know also where actually that constant is located. My point is that, there should be minimum change in the rest when we change something in somewhere.
Suggestion: It's a very good useful video, but instead of “Principle #n” for the names of the timestamps, it would be more useful if they were meaningful names. I like to read the description and jump to specific topics. @sidouglas did something similar. It can be more succinct. For instance, instead of “Eliminate if/else branching; early termination”, it can be “Guard clauses” or “Return early”.
🎯 Key points for quick navigation: 00:00 *🌐 Avoid unnecessary nesting and branching to improve code readability and maintainability.* 02:16 *📝 Clarify ambiguous code by using descriptive names and function names that reflect their behavior.* 04:09 *🔍 Use comments sparingly and effectively to explain complex logic rather than reiterating what the code does.* 05:32 *🛠️ Maintain consistent code formatting for readability and reduce potential errors.* 07:25 *🔄 Apply the DRY principle to eliminate code duplication and enhance maintainability.* 08:50 *⚡ Fail fast and early in functions to minimize unnecessary processing and enhance code efficiency.* 09:47 *🎩 Replace magic numbers or values with named constants to improve code readability and maintainability.* 11:27 *🔧 Ensure functions adhere to the Single Responsibility Principle to enhance clarity and maintainability.* 12:08 *🔄 Prefer clear and readable code over overly clever solutions for better maintainability and understanding.* 14:08 *⏳ Avoid premature optimization; optimize code when necessary based on actual performance bottlenecks.* Made with HARPA AI
Does practicing all these things before seeing this video already makes me a senior dev? I don't even know what stage i am.. Maybe junior, intermediate or senior.. but whose checking
I just watched first part of the video, u removed if else and added more ifs, the pronlem with your code style is that when it will come to priority of your ifs, because just swap two of them and your code does not work as expected, it mean if i have 10 ifs i should keep in mind not to change the order od ifs in future when i add or remove a condition, good video and thanks for sharing but who made if else knew better than us if not they just made if without else.
when it comes to quotes (in languages that accept both), I use single quotes generally, unless the string contains a single quote, in which case I use double quotes (I prefer that to escaping).
A bit misleading to have curly braces around single statements in your first code layout, then remove them for the improved version. You artificially make the bad layout look more cluttered.
I get what you're saying, but I actually think the bad version needs them. Without curly braces, nested ifs get pretty confusing imo, whereas when they are just vertically stacked and single lines I don't think they are necessary. Regardless though, if you include the curly braces in the improved version, it will still look vastly better.
Nice content, good job. The first tip is a double edged sword. Too many control statements can also be confusing. You have to check the entire method to understand what all it can return. Sometimes the if-else blocks which populated a variable and return at the end is easier to understand.
Don't return the value of a function you did not intend to return. This WILL cause subtle bugs later than you will spend hours trying to figure out. Return values you intend to return as per the contract of the function you are writing. Don't use return as a shortcut to end the function while forwarding another function's return value. Right now it returns nothing, but later on it might, and that value will propagate to places you did not intend it to.
The proper way is it to write "{ my function(); return; }" but that doesn't change anything in JS if the function is void: you just get undefined. Now if someone doesn't understand the concept of a void function and tries to read its return value, then it's their fault and their code deserves to break.
There's a principle I've been talking about that might fall under "single use" but I call it "avoiding code omniscience". When we develop things in a shared project, we don't want our code to impact current code or potential future code in a way that we didn't anticipate. But we also don't want our code to increase the complexity of the project such that people working on it require knowledge of your code - i.e. requiring code omniscience. Like if we have a validation process that prevents certain items being added to a cart in an ecommerce system, unless it's hooked in directly to the add to cart system, every controller that implements add to cart will need to be updated to add this - you've increased the complexity. Or similarly, if the code we write adds a flag to the item being added, and if it's there, the validation occurs. Someone rocking up years later would have to be aware of the flag if they want to make a new system that creates gift boxes (bundles of items) or something. Documentation and tests can solve this problem but....
It can depend, but generally speaking no. It's a pretty common practice to add constants to the top of the file that sort of act as a configuration setup. That said, I don't think it would be the worst thing for this to be inside the function either.
The side-effect with "never nesting" is you have a default behavior if a combination of checks unexpectedly work (either though a bug or unanticipated inputs). Could be good, could be bad, depending.
Couldn't agree more with all of these, though Python has instilled a habit of using 'SINGLE_QUOTES' for constants and identifiers, and "double quotes" for misc./ "natural" text in me
example 1 in Principle 9 is actually rather subtle O(n^2) because the reduce is O(n) and the spreading again is O(n), so its two nested loops. Another reason why the second approach is plain better ;) The second is only O(n), becasue its two consecutive loops.
Hey Conner) thanks for the useful tips. But something is not clear for me in example with reduce and filter. If I'm not mistaken distructuring in reduce will cause the time complexity Am I right?
I like the first sentence I hear after clicking your video is "The first principle of clean code ..." just jump to the point. Love it!!!
Turns out people can read the title and don’t need videos to introduce it for 2 minutes! What a novel concept 😂
it means he's an honest man, not a jackal who wants to steal your time for their "watch time".
This video is an excellent example of what uncle Bob mentioned in his book about being pragmatic with your own clean practices. All your tips are in the book, and the tips you don’t judge it to be good you just don’t have to use. People flame uncle Bob with the “functions shall be short” tip, but they forget the pragmatism mentioned by Bob in the introduction of the book.
You made me realise that my JavaScript code was complete doodoo and made me redo it all again.
This time I actually understood what I was trying to do. Thank you.
That’s awesome 🙌
Thank you Connor!!! I am forever dealing with "code smells" because people are not taking the time to do clean code. And I always end up cleaning up THEIR mess when I have to do the daily merge of everyone's code. 😭
Try and make it their problem, that is, try to get the teammates to use the same principles as you want to. That way you are less burdened when doing merges and they get their stuff merged with more ease and probably learn from it. Where possible / feasible, use linting and code guidelines to automate the guidance.
In Principle 3 you should also extract Math.sqrt so it wont call it again and again at each iteration
I'm not sure if it would be another principle worth considering, but over the last year I've stopped dealing with the traditional try/catch error handling construct and instead return results and if my code throws an exception it is an "unhandled" exception to terminate the app (I'll have a hook into unhandled exceptions so I can log it before crash). You can think of it like Zig's "panic" feature. I just find the traditional try/catch something that makes code execution more difficult to reason about. I also use error codes so if the caller of a function received an error it's easier to check the error code for certain kinds of errors that can be handled or possibly panic. If I'm using a library that subscribes to the try/catch paradigm then I'll wrap it around my own thing that hides that construct (and only expose the things I use from the library).
Probably not perfect and, I'm sure, the methodology would conjure up some discussion and debate but it has made my experience more fun and the code I write a bit more iron clad.
Great clear video 👍.
But to be honest, the majority of the examples are covered by using a good ESLint configuration. Add some Prettier on top for the spacing / formatting.
Thanks for video!
Principle #6: I think you have forgotten to mention about direct returning the value instead of placing it to const and then returning it
Principle #7
I think better naming for the second variable would be TAXABLE_TRANSACTION_MULTIPLIER
I love the blue background on you profile pic and also that soft blue lightning in your room. I love blue too
what a gem bro, glad I stumbled upon this video.
Really love your content, straight to the point with examples 👍🏻
at 2:00 you are missing return statement.
This was excellent in that it's a practical and straightforward explanation, thank you!
this video slaps.
I'm a huge believer that optimization should come only went a bottleneck presents itself, and in all other instances making code that is human readable is paramount. To assume how the code will be ran on the hardware, especially in javascript of all things, and attempt to pre-optimize is a fools errand. What is vastly better is easy to digest at a glance human readable code, where you can intuit how it should be used and how it can use extended and maintained.
Great stuff!
Nice list. For #1, I actually prefer writing the last conditional with an else statement and no return statement. If I have fresh eyes on the code, my first question would be "why does the child version have a return"
Regarding Optimization. In more than 20 years writing Production Java code for one of the largest international banks, I have had to optimize my code twice. The first time a change to the XSLT library implementation made processing take 50x longer. Simply adding a line of code to set an undocumented but supported flag returned to normal. The second time, Dodd Frank caused volume to increase 10x overnight. Because I had written the worker code to be reentrant all I had to do was change config parameter # of workers from 1 to 16 to increase throughput 10-fold (and add an extra CPU core and run code analysis and deadlock detection overnight).
Bottom line: Just write Clean Code and - as Conner says in the video - let the compiler worry about the insignificant local optimizations that are such tempting distractions; that's its job, not yours.
Nice video, thanks! Straight to the point! In principle 9, I think that the example was not very good regarding the 2 loops VS 1. Reduce can be a little hard to get used to, but once you do, it's really easy to read and understand what it does. I used to chain array functions as you did here, but mainly because I never took the time to work with reduce. Now it's just easy, and if you have big arrays, loop twice VS once is really not a good idea.. I agree thaw trying to be clever while programming does not make sense, but reduce is just a basic array operator 🤷🏻♂️
I know all your principles, because I have read Clean Code book. But I appreciate this video, and I love this video and your content. +1 subscribe.
THANK YOU❤
I liked the way of code... nice
Not sure I agree with 9, i'll take that reduce instead because if we apply this rule, you'll see people chaining filter map sort and such which is rather messy imho
For 9:33 i would say that it would be clearer if we did:
"let price = 10.0"
so we know it is double
excellent content thanks Conner.
Should variables be in capital and functions in camel?
1b) using exptions for flow control is not a good idea. Additionally showFullVersion and showChildrenVersion are alternatives. With new style it looks like showChildrenVersion is a kind of error handling.
5) you introduce a new method and increase complexity. Methods will be used. So someone will use it to log something else or even abuses it. And then other logic is coupled.
You couple business logic of three methods. It they are independent than its a bad idea. It you want to make sure that they behave equally -only then - its a good idea.
8) such things can sometime be a good soliution. Especially if setting the var area later is costly. for instance if your are in a database transaction than this can be good.
Or is you process an image and updating it later would mean to run through millions of pixels again.
All other points are ok.
Your take on 1b is weird. It's a random example with no context so how can you tell if the exception is needed or not?
@@maelstrom57 using Exceptions for flow control is an anti pattern.
(btw. cuddled else is never a clean code, especially with intendation of 2.
And for the latter:
showChildrenVersion is on the same abstraction level like showFullVersion.
As I said:
if there are barely any children than you construction is kind of ok. That is what i mean as kind of error handling. That a child wants to see this site is an error so to day.
But if there are equally amount of children and adults than both methods are on the same level. They are alternatives.
And a ternary operator (or a switch if more than two) would be a better solution than.
some ai will be doing all of this in a year or two, max. The only people that will have jobs are lead developers in management positions (to dictate what AI needs to do). Junior or mid level will be completely obsolete. If you're about to start programming in 2024..... you're most likely not going to land a job in a few years, be aware.
Good examples. But using exceptions in validation code will throw a lot of exceptions in a large system. They will clutter the application monitoring and hide the actual problems. In addition, exceptions are expensive.
Invalid user input is expected.
so what should you instead of throwing?
@@memeproductions4182 Validation should be handled by usually telling the user what went wrong, which means not throwing an error, but rendering some kind of message to the user (sending JSON response, printing to screen, etc...); it doesn't make sense to crash your application because of invalid user input lol. But to be fair, all of his examples are oversimplifications for the sake of teaching a specific concept, so we can cut him some slack.
Don't use double equals comparison.
I'd still go with the reduce one and made it more readable 😂
not gonna lie, that first principle i just learned that from chatGPT, now tell me if GPT is that really irrelevant for these haters.
Turned the video off as soon as I saw he was using == and not ===.
== for null checks
=== for everything else
This just ensures you check for undefined as well, and is generally the preferred practice of most style guides / tech companies.
@@ConnerArdman it's better to have clearer code than rely on the odd behaviour of !=. So
if (user.age !== null && user.age !== undefined) {
}
or
if (user.age) {
}
are better options.
It's really a matter of opinion, but I would disagree. Some prefer explicit checks for undefined, but personally I find it to just be a little clunky. It's also just easy to forget to also check for undefined, whereas eslint can remind you to always do == null to solve for that problem.
The industry is somewhat divided on this, but every team I have ever worked on at tech companies big and small preferred == null. As an example, here' is Google's JavaScript style guide stating the same opinion:
google.github.io/styleguide/jsguide.html#features-equality-checks
As for the second option, I actually think this is an objectively bad practice and one I have seen cause real bugs in production. For example, your check of if (user.age) is presumably meant to be the same as above, to check that the value exists. However, what if the age is 0? 0 is falsy, so we wouldn't get into the if check. In some instances this may be what you want, but in others it isn't. I would generally avoid relying on truthy/falsy for this reason, as even if it is what you want, it is isn't particularly obvious and readable code.
Prefer wrapping loose equality operator in a function: `isNullish` - quite popular in TS. Then it's clear to team you intend ==, rather than being questioned at code review time or eslint squawking at you (eqeqeq rule)
@@ConnerArdman if you're reading from the DOM this isn't an issue as you'll always get a string, otherwise in my opinion it's better to be explicit and check for null and undefined.
W, no bullshit, no annoying stuff, straight forward, not only clean code, also clean video
he "forgot" to ask to subscribe and hit the bell icon :)
0:00 1. Eliminate if/else branching; early termination
2:16 2. Ambiguous definitions: ‘is’ function prefix to denote boolean return
4:05 3. Self documenting code: avoid belaboured comments
5:37 4. Consistent formatting. Use Eslint + Prettier to automate code style
7:14 5. DRY business logic. Look for opportunities to refactor. Make sure to test!
8:37 6. Fail or exit functions fast. Related to 1.
9:28 7. Avoid magic values - declare and use CONSTANTS instead.
10:41 8. Avoid violating single responsibility. Prefer to use pure functions (no side effects)
11:57 9. Overly clever code (code golf). Leads to impenetrable single liners (have to rewrite in order to debug)
14:00 10. Premature optimisations.
thanks for the summary buddy
1. Is also called Guard Clauses or reducing nesting
The isPrime example, you use Math.sqrt in the condition, this will in many languages, including js, cause the sqrt to be calculated on each pass of the loop so you should break that out to a variable and the comment can then be added to the creation of the variable, this will make it even more clear that the comment is for why we use Math.Sqrt and improve performance and reduce line complexity since the loop conditional will be a simple i
Good call, putting the smart in Smartensson
@@ConnerArdman the s is actually from my real middle name and I never realized it was part of the visible name :D.
Try to convert comments to names. For example, name the variable nonPrimeWillHaveFactorBelow and assign 1 + the Sqrt.
This might be the first UA-cam video I've seen in well over a decade where the content actually starts at 0:00
Subscribed
For real LOL it's refreshing to see
Fallowed all 10 principles consistently from last 5 years .. still nobody appreciated 😢
Haha don’t get me started. Ive worked with senior developers who still don’t work with principles.
Over commenting. I’m in university and I have to comment everything line for line and have a massive comment block on the top explaining how it works overall. Why is this taught if that many comments is actually a bad thing?
My guess would be it’s probably for the benefit of the grader to essentially “show your work.” Hard to say for sure though 🤷♂️
Actually learning how to comment is a skill that is difficult to teach. Your prof’s approach is likely because he is just a tad lazy, but is also not totally terrible. As long as your comments aren’t just rewording the code, you’re doing ok. Explain the thinking behind it, why a more obvious approach isn’t valid, etc. Have fun!!
When you are writing a comment, think about the why not that what. The code already does and should be written in a manner that what is doing is clear. There are occasions that a “what” type of comment is needed. For example, the algorithm is complicated and long, or obscure, or using some hidden feature that it’s not so easy to understand by just looking at the code. Normally, a comment like is more useful when the piece of code is doing something that it’s not common for the environment/industry.
#1 Mostly agreed, but I think the last part when there are two ways of ending function, one with return and the other one with no return is more confusing than just one else statement
#4 There was a semicolon missing in one line ;)
Yeah that’s valid. Or if there is going to be a return, it should have been an empty return in hindsight.
Glad someone else noticed on #1. Especially important in JS since the showChildrenVersion could be modified and the compiler wouldn't warn you.
The whole #4 point could be fixed with an extntion like prettier, i can't see myself formating my code by myself all day long.
13:14 the reason why the bitwise expression is confusing in that example is because it evaluates to a number, 1 or 0, instead of true or false. Js deals with truthy/falsy for conditional expressions so it still works, but it should really evaluate to a boolean if being used in a conditional, e.g. n & 1 !== 0
Great tips otherwise 🔥
"easy to understand" vs. "more performant" while I agree, creating code that is complex for the sake of convolution is bad. I am not in agreement with easy to understand code should be used over performant code. Just comment your complex functions or lines stating what it does. In applications that are running 100s or 1000s of actions these things don't really matter. When you're running millions of actions asynchronously sometimes milliseconds matter.
Bad Performance is often a result of poor data structure usage, or api calls, etc. VS something like “how should I sort this array”. In these cases I easy to understand is preferred imo.
Though of skipping the video, but it immediately got my attention due to how objective it is. Thanks for the content.
I always eye-roll at reduce being labelled "hard to read". Maybe don't dump it all in one line?
His habit of clean code shows in his way of doing a video. Clean and crisp
The code at 5 got made worse IMO. Before three functions encapsalated 3 actions you can do. Now logAction takes in some ambigous param action and I got to read the function to have any clue what it's doing
and you don't even know what to expect in the action
Just a small addition on the example of DRY; what's covered here is to replace three functions that do the same thing with one function that can do anything. If you want to enforce the passed-in value is always one of a specific set of strings, it should still be fine to use these other three functions. They can cover an abstraction, enforcing the passed "action" to be a specific value. Such as "return logAction("logged in")" in the first example function.
Yep. DRY is dangerous advice because many times you don't repeat yourself but rhyme. Code should be allowed to rhyme, if it isn't then you've created an abstraction layer that will need logic. In worst case in the abstraction layer. And the more rhyming code you try to fit in the more logic you need, thus the abstraction starts growing and growing and growing.
Don't repeat yourself. But don't be afraid to rhyme.
You aren’t going to comment on the square-root being calculated on every iteration (5:35)?
I have been coding since 1969 and constantly learning. With ober 13 Lang under my best (1st love is assembly on a mainframe) I always agonize over "is it readable?" If not them clean it up! I write with the intention that someone else may have to maintain this.
I also never take code personally, as I have seen many coders do. Instead I will show my code to others and ask them "is this easy to understand?" If the answer is no, I need to fix it.
On each function, I place "function notes block" which are a block of comments, right before the function definition. It describes why the function is used, all the variables used, along with global variables, and in the case of assembly, what registers are touched or referenced.
I used to run the code through a custom print program to output all these "function note blocks" to be used along any documentation I have. It shows the functions sorted alphabetically, the module they are in along with the line number where they are defined. Comes in very handy when something goes wrong
Thank you for this 🙏 ❤🎉
This video is so good. So many gold nuggets that you don't learn in traditional coding bootcamps or tutorials.
Glad you enjoyed it! 😀
i compress my code into 10 lines, nobody can read it but it looks cool.
Try ESLint & Prettier & JSDoc
Nice video, I agree with most of your principles.
But I disagree with #8. I think modifying global variables is totally fine most of the time. And I think functions can and should do lots of things if it makes sense. I find the "single responsibility principle" to be silly. Long functions are much better than a bunch of small ones.
#9 example is tough to see. I think both examples look equally "readable".
#10 is solid advice
I know these principles, but I can't pass a job interview cause my code solving brain isn't as good as yours XD
Well in code interview it's lame but they dont care about clean code, they just throw you with random interview question which does not represent the job of a developer.
Wish you good luck on your next interviews, you got this !
@@Variant_Delta 🫶
Yes string interpolation, it works great with double quoted strings. "code: {$example}"
Your first advice was fine until you reach the test on the age, where it doesn’t hold anymore and really makes no sense. Inverting doesn’t provide anything useful and actually removing the else here makes the code look a bit weirder.
The rule is that nesting should be done when it makes sense, and early-return on errors is fine, but the rest feels like you’re trying to apply a General Fundamental Ultimate Rule™ and really you should not take things to heart like that.
2:25
If it is just the comparison of two numeric values, then why we are sending the object to this utility function? Namely, that function does not need to know how the "length" of a "password" object is retrieved. Rather the place that is taking care of the business logic already know what password object is and how its length can be retrieved, so we can directly send the value instead of the object. With doing so we can convert this utility functions into a library which would not be depend on any object (e.g. StringUtils in Java Apache Commons). Plus, minimum password constant value can be retrieved from another constant util class's function instead of directly referencing to the variable from a function, so that the checkPasswordLength does not need to know also where actually that constant is located. My point is that, there should be minimum change in the rest when we change something in somewhere.
Suggestion:
It's a very good useful video, but instead of “Principle #n” for the names of the timestamps, it would be more useful if they were meaningful names.
I like to read the description and jump to specific topics.
@sidouglas did something similar. It can be more succinct.
For instance, instead of “Eliminate if/else branching; early termination”, it can be “Guard clauses” or “Return early”.
🎯 Key points for quick navigation:
00:00 *🌐 Avoid unnecessary nesting and branching to improve code readability and maintainability.*
02:16 *📝 Clarify ambiguous code by using descriptive names and function names that reflect their behavior.*
04:09 *🔍 Use comments sparingly and effectively to explain complex logic rather than reiterating what the code does.*
05:32 *🛠️ Maintain consistent code formatting for readability and reduce potential errors.*
07:25 *🔄 Apply the DRY principle to eliminate code duplication and enhance maintainability.*
08:50 *⚡ Fail fast and early in functions to minimize unnecessary processing and enhance code efficiency.*
09:47 *🎩 Replace magic numbers or values with named constants to improve code readability and maintainability.*
11:27 *🔧 Ensure functions adhere to the Single Responsibility Principle to enhance clarity and maintainability.*
12:08 *🔄 Prefer clear and readable code over overly clever solutions for better maintainability and understanding.*
14:08 *⏳ Avoid premature optimization; optimize code when necessary based on actual performance bottlenecks.*
Made with HARPA AI
Does practicing all these things before seeing this video already makes me a senior dev? I don't even know what stage i am.. Maybe junior, intermediate or senior.. but whose checking
The most important principle should be "avoid using JavaScript"
13:25 solution on line 3 worse also because it has O(n^2) complexity: spread in reduce. Don't do like that
I just watched first part of the video, u removed if else and added more ifs, the pronlem with your code style is that when it will come to priority of your ifs, because just swap two of them and your code does not work as expected, it mean if i have 10 ifs i should keep in mind not to change the order od ifs in future when i add or remove a condition, good video and thanks for sharing but who made if else knew better than us if not they just made if without else.
Is that all there is to it? I thought Clean code was some magic way of writing code, but hey, then I don't need to change anything
the if else principle really help me, sometime i was confused why my else block code didnot work. thank you
Clean everything what is wrong in the code. No more.😊
The code with guard clause saves a lot of time while debugging a code
I would use the ternary operator for the age verification
when it comes to quotes (in languages that accept both), I use single quotes generally, unless the string contains a single quote, in which case I use double quotes (I prefer that to escaping).
Amazing video, thanks for this.
A bit misleading to have curly braces around single statements in your first code layout, then remove them for the improved version. You artificially make the bad layout look more cluttered.
I get what you're saying, but I actually think the bad version needs them. Without curly braces, nested ifs get pretty confusing imo, whereas when they are just vertically stacked and single lines I don't think they are necessary. Regardless though, if you include the curly braces in the improved version, it will still look vastly better.
Basically throw error checks first, lastly do what should be done last lol
Hello Conner,
This is absolutely great advice! Please make videos like this :)
🫡
Nice content, good job. The first tip is a double edged sword. Too many control statements can also be confusing. You have to check the entire method to understand what all it can return. Sometimes the if-else blocks which populated a variable and return at the end is easier to understand.
Don't return the value of a function you did not intend to return. This WILL cause subtle bugs later than you will spend hours trying to figure out.
Return values you intend to return as per the contract of the function you are writing. Don't use return as a shortcut to end the function while forwarding another function's return value. Right now it returns nothing, but later on it might, and that value will propagate to places you did not intend it to.
The proper way is it to write "{ my function(); return; }" but that doesn't change anything in JS if the function is void: you just get undefined. Now if someone doesn't understand the concept of a void function and tries to read its return value, then it's their fault and their code deserves to break.
There's a principle I've been talking about that might fall under "single use" but I call it "avoiding code omniscience". When we develop things in a shared project, we don't want our code to impact current code or potential future code in a way that we didn't anticipate. But we also don't want our code to increase the complexity of the project such that people working on it require knowledge of your code - i.e. requiring code omniscience. Like if we have a validation process that prevents certain items being added to a cart in an ecommerce system, unless it's hooked in directly to the add to cart system, every controller that implements add to cart will need to be updated to add this - you've increased the complexity. Or similarly, if the code we write adds a flag to the item being added, and if it's there, the validation occurs. Someone rocking up years later would have to be aware of the flag if they want to make a new system that creates gift boxes (bundles of items) or something. Documentation and tests can solve this problem but....
Just a question, for the exemple 2, it isn’t better to declare the const password length in the function ?
It can depend, but generally speaking no. It's a pretty common practice to add constants to the top of the file that sort of act as a configuration setup. That said, I don't think it would be the worst thing for this to be inside the function either.
The side-effect with "never nesting" is you have a default behavior if a combination of checks unexpectedly work (either though a bug or unanticipated inputs). Could be good, could be bad, depending.
For those on a tight schedule, his 10 principles start at 0:00
Couldn't agree more with all of these, though Python has instilled a habit of using 'SINGLE_QUOTES' for constants and identifiers, and "double quotes" for misc./ "natural" text in me
Well Done! Solid advice. It's Saturday night, I've had a few drinks, and you STILL held my attention!
example 1 in Principle 9 is actually rather subtle O(n^2) because the reduce is O(n) and the spreading again is O(n), so its two nested loops. Another reason why the second approach is plain better ;) The second is only O(n), becasue its two consecutive loops.
For comments I would use doc blocks
Nothing against the Conner but I hate JavaScript, just having the variable type and return type speaks volumes.
I learn with bible teacher john adam teacher
Clean code also means using curly braces 😅
On #8 I would possibly rename it to calculate circular area or something as "calculateArea" could be for any shape but it only calculates a circle.
Principle 1. Don't throw. Respect your caller and Be true to the signature of the function.
I program PLCs and I had an argument with a coworker stating magic numbers are the way to go, I was so pissed, my industry is so outdared...
Omg, thank you for starting right away. I’m tired of these 2 minute beginnings that makes no sense
Just came across this and immediately subscribed 1 minute in because I need Jesse Eisenberg talking about coding in my life.
I stopped watching at throw an exception for control flow… 😢 Ugh.
Triple equals or !user that null check
Hey Conner) thanks for the useful tips.
But something is not clear for me in example with reduce and filter.
If I'm not mistaken distructuring in reduce will cause the time complexity
Am I right?
Hi i have a question , how much JavaScript enough to start react js im should i build big projects with js or just simple projects
Example number nine does not have to be two loops, a compiler can reason about this and just make one reduction for it.
Yes we need return the same follow code
For the "return boolean" functions, I used "has'" and "can" also, depending on my needs.
Failing fast and early, loved it.
Really nice 👌👍. Thanks 😊