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

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.

This might be the first KZfaq video I've seen in well over a decade where the content actually starts at 0:00 Subscribed

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

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.

W, no bullshit, no annoying stuff, straight forward, not only clean code, also clean video

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.

Though of skipping the video, but it immediately got my attention due to how objective it is. Thanks for the content.

Really love your content, straight to the point with examples 👍🏻

Always great reminders. Keep up the hard work! 💪

the if else principle really help me, sometime i was confused why my else block code didnot work. thank you

This video is so good. So many gold nuggets that you don't learn in traditional coding bootcamps or tutorials.

Thank you so much this is gold!!!

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.

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.

Amazing video, thanks for this.

This was excellent in that it's a practical and straightforward explanation, thank you!

Hello Conner, This is absolutely great advice! Please make videos like this :)

Great video! Beginners should take a lot of notes from here.

Thank you for this 🙏 ❤🎉

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

excellent content thanks Conner.

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

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

For the "return boolean" functions, I used "has'" and "can" also, depending on my needs.

Going to use this in my lessons!

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.

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.

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?

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.

Just came across this and immediately subscribed 1 minute in because I need Jesse Eisenberg talking about coding in my life.

I appreciate your videos!

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 🔥

Very nice video mate

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!

5:37 I use a combination. If I have variables at the beginning or end of the string, I don't use ${var} but var + or + var because that's two less character [4 chars VS. 2 chars]. If it's variables inside a string, it's more effective to use ${var} because it's less characters than using " + var + " [4 chars VS. 5 chars]. 8:37 I use if(variable?.trim?.()) [ I know it's not bulletproof because an object with a trim() method might come in, but in many cases it's legitimate to use my way, especially if I've tested somewhere before that it's not an object. ]

In Principle 3 you should also extract Math.sqrt so it wont call it again and again at each iteration

Thank you for this

#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 ;)

thanks...this helped

Now a days, I write the code and get my code reviewed by AI to see if there can be any potential improvements or refactoring we can do in terms of clean code and it helps me to write clean code. Anyways these tips are really golden! A lot of times I make these mistakes and get review comments from my Tech lead about these mistakes

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 🤷🏻‍♂️

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.

Try ESLint & Prettier & JSDoc

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

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

Amazing 💯

You aren’t going to comment on the square-root being calculated on every iteration (5:35)?

Example number nine does not have to be two loops, a compiler can reason about this and just make one reduction for it.

I wish more people used principle #2

very good, thank you

I always eye-roll at reduce being labelled "hard to read". Maybe don't dump it all in one line?

Very nice logic.

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?

Nice, thanks

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

what i like to do is convert a null or undefined value into a boolean value, in this case if(!user)

at 2:00 you are missing return statement.

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

For 9:33 i would say that it would be clearer if we did: "let price = 10.0" so we know it is double

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.

You should have your own eslint rules

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.

First programming video I see done by Michael Cera

For the first principle, inverting if..else only works in general with if..else throw or if..else return) but in most cases it will make everything worse. Here are some tips to keep track of what clause brackets corrsepond to -corresponding bracket have the same color on vscode you can clearly see it on the video. Maybe with another color theme they would be more visible -there is a keyboard shortcut to go from a closing/opening bracket to the corresponding opening/closing bracket -when your mouse is over a bracket the corresponding one will be highlighted .

2nd one can be solved by using jsdoc

For the first example, in cases where you have to log all exceptions, you'll really need nested if else.

Generally I do agree, just some things I would argue against. The second example the variable isn't ambiguous you see the .length before it so it obviously is length. Frankly I don't really care for variable names, I come from a time where variables were often just memory addresses unless you had an assembler. I love the golang single letter variable idioms, like I said I coded so much assembly I really don't care about variable names. Why use a build-in uppercase function? You can easily write that in 1 line yourself and you can handle a decent error as well. And that function name is very verbose a toUpper is enough. But the get is actually misleading, as you are not getting something from a class or a struct. This is just a static stand alone function. So arguably toUpper is enough imo. Bitwise operations are no more or less legible then a mathematical approach -- you are not a programmer if you have difficulty understanding bitwise operations imo. I prefer the bitwise operating because it will ALWAYS (despite your compiler or interpreter) going to be fast. With a modulo (division) you never know. Especially if you end up using your code on a small microcontroller that has no division and multiply then no massive maths function is included that perhaps could blow your program beyond the capacity of the memory of the microcontroller. I literally had this happen with a person who wrote a task distributor on two physical machines using a % in Python and it was so slow! I changed it to & and it went from 25 seconds to 7 seconds. Luckily in Python 3 this sort of thing is optimised but that's why you should just stick with binary operations.

I know these principles, but I can't pass a job interview cause my code solving brain isn't as good as yours XD

Fallowed all 10 principles consistently from last 5 years .. still nobody appreciated 😢

I'd still go with the reduce one and made it more readable 😂

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.

Principle 10 is not an argument against "premature optimization", it's an argument for unnecessary pessimization. Premature optimization is when you make the uninformed decision to switch to assembler to squeeze a few CPU cycles out of a function. Premature Optimization is not a thing in purely high level code as you have it in languages like javascript. Unfortunately, this misconception is very widespread and it is leading to incredibly slow code, where the whole codebase is the bottleneck, because everything it pessimized to a point where you can't even find a place to start optimizing. With all the pessimizations stacked on top of each other, we today have the issue that simple operations like starting a program can take 10 seconds and more, where it should take less than half a second.

so using double equity is best practice (1st example)? While making "clean code principles" video maybe you should also be careful about some easy best practices. use triple equity. because you look like experienced developer, so maybe there are new comers which may think double equity is better in js

👍

Nothing against the Conner but I hate JavaScript, just having the variable type and return type speaks volumes.

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

so basically clean code made a code looks like python as possible ? haha iam joking nice content about clean code

LoL. In your first example you actually alter what the code does. So I think I'll take the rest of your video with a grain of salt. I'm really surprised I haven't seen a comment that refers to this.

Turned the video off as soon as I saw he was using == and not ===.

Strongly disagree with Principle #1, for multiple reasons. I know that what you've demonstrated is super common, and I may not be in any majority about this opinion, but there are other ways to limit the number of nested conditions without inverting every function's conditional logic. One of those ways is to abstract some/all of those conditions into a different function for validation, name it as such, and put that function call in an if-condition to neatly replace them. This is smelling like great example of a failure to follow the 'S' of the SOLID principles. The main gripe I have with your first principle is that writing code with inverted/negative logic goes against the essence of your function name. The function name isn't negatively expressed, so neither should the internal logic. Exceptions and invalid value checks should not get primary/preferential treatment before the code for which your function is named. I personally hate when curly brackets are excluded for one-liner conditions, but that's just me. And your abuse of the return statement to shortcut having to use 'else' is just misleading and lazy. Again, if the function name doesn't suggest that it's going to return something, it probably shouldn't, especially if you're returning from a function call that itself doesn't return anything. That's called a wild goose chase for the next programmer to interpret your code. Don't do that, please.

For the love of gods, please use curly brackets even for one sentence...

No mid-function returns please

CLEAN CODE, HORRIBLE PERFORMANCE

its not code its just javascript :D