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

@ConnerArdman

Ай бұрын

Turns out people can read the title and don’t need videos to introduce it for 2 minutes! What a novel concept 😂

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.

@brunofilgueiras3518

Ай бұрын

thanks for the summary buddy

@codycortello

Күн бұрын

1. Is also called Guard Clauses or reducing nesting

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

@kresuu3567

2 ай бұрын

For real LOL it's refreshing to see

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.

@ConnerArdman

2 ай бұрын

That’s awesome 🙌

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

@ConnerArdman

2 ай бұрын

Good call, putting the smart in Smartensson

@davidmartensson273

2 ай бұрын

@@ConnerArdman the s is actually from my real middle name and I never realized it was part of the visible name :D.

@BangsarRia

2 ай бұрын

Try to convert comments to names. For example, name the variable nonPrimeWillHaveFactorBelow and assign 1 + the Sqrt.

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

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

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

Always great reminders. Keep up the hard work! 💪

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

Thank you so much this is gold!!!

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.

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.

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

Thank you for this 🙏 ❤🎉

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

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

@ConnerArdman

Ай бұрын

🫡

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

excellent content thanks Conner.

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!

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

@ConnerArdman

2 ай бұрын

Glad you enjoyed it! 😀

I appreciate your videos!

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.

Thank you for this

Very nice video mate

thanks...this helped

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

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?

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

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.

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.

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

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

very good, thank you

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

@ConnerArdman

2 ай бұрын

Yeah that’s valid. Or if there is going to be a return, it should have been an empty return in hindsight.

Very nice logic.

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

@gnack420

Күн бұрын

The number of characters makes absolutely no difference to the effectiveness of the code.

Amazing 💯

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

I wish more people used principle #2

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

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?

@ConnerArdman

2 ай бұрын

My guess would be it’s probably for the benefit of the grader to essentially “show your work.” Hard to say for sure though 🤷‍♂️

@lawrencemanning

Ай бұрын

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

Try ESLint & Prettier & JSDoc

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

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

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

@CallousCoder

Ай бұрын

AI is very very bad at clean and efficient code! I used CODY for code smells and it doesn't even see context it says: "check that pointer" and I always go: "check line xyz for your remark number x" And it sees it's covered. It comes up with idiotic ideas of naming variables really long like n "number" for readability. For fuck sake, it's the only parameter in the function, the type says its an u64 what else do you want, Cody? I am not going to type number everytime :D So my advise is, be very critical because AI is really really bad at coding!

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

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

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

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

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.

@memeproductions4182

2 ай бұрын

so what should you instead of throwing?

@Aedaeum

2 ай бұрын

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

2nd one can be solved by using jsdoc

First programming video I see done by Michael Cera

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

👍

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 .

@asdqwe4427

2 ай бұрын

I'm sure you can find a bunch of cases where this isn't optimal. But generally speaking, the important part of what he is demonstrating is that getting much of the validation out of the way right at the beginning of the function makes the rest of the code much more readable. The return statements on the bottom are ambiguous, but those are not the main point of the principle

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

@Variant_Delta

2 ай бұрын

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 !

@avivshvitzky2459

2 ай бұрын

@@Variant_Delta 🫶

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.

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.

@Adiounys

Ай бұрын

You don't see 'length' before it, you see 'const' before it. The whole point is a variable is defined outside of a function and it may not be defined just before it's usage. It's just an example.

@CallousCoder

Ай бұрын

@@AdiounysI was referring to the function name checkPasswordLength, it implies it’s the number of characters of the password. It’s a very descriptive name already. And having unassigned variables is the death. Especially when you declare those outside of a function. The only types that you may get away with by not explicitly passing in are constants. And even that I’m not a fan off, as it’s not very explicit. Better is to have a configuration singleton and pass that into the function via a parameter. Now a better example here would’ve been: isPasswordMatchingPolicy(string password, PasswordPolicy policy)

@Adiounys

Ай бұрын

@@CallousCoder You wrote "variable". In your example you would still have the 'MIN_PASSWORD' in your policy type so the point mentioned in video is still valid. I such case I would name it simply 'minLength' since the "password" would be implied from the 'PasswordPolicy'.

@CallousCoder

Ай бұрын

@@Adiounys well usually a password has more parameters than length alone.

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

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.

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

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

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

@ConnerArdman

Ай бұрын

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

@MrSpongeHead

Ай бұрын

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

@ConnerArdman

Ай бұрын

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.

@sidouglas

Ай бұрын

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)

@MrSpongeHead

Ай бұрын

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

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.

@ConnerArdman

Ай бұрын

The code does the exact same thing…

@LokiDaFerret

Ай бұрын

@@ConnerArdman your new result will return whatever value is returned from your underage function (if it executes). The original did not return anything. So always returned null

@ConnerArdman

Ай бұрын

Ah yeah that’s what you meant. There’s a note in the video that I shouldn’t have done that and should have just used an empty return or left the final if/else 👍

@LokiDaFerret

Ай бұрын

@@ConnerArdman if it were me I would have used the if else shorthand syntax with colon :. Anyway glad we got that sorted. 👍

No mid-function returns please

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.

@philliplam2704

2 ай бұрын

No you are bad stop coding just go play with Wordpress

@whynot9963

2 ай бұрын

I agree about your 2 last points, but the early exit is much more readable. Hell, they even made whole language around that principle 😅

@SeanLazer

2 ай бұрын

Early exit is way more readable and worrying about SOLID or SRP in a ten line function is a recipe for over designed code that's impossible to actually follow. The control flow and intention of Conner's function is super clear after the changes.

its not code its just javascript :D

CLEAN CODE, HORRIBLE PERFORMANCE

@BangsarRia

2 ай бұрын

This reminds me of when I started a new job at a service bureau for Savings Banks in 1977 and the Head of Programming patiently told me not to make any procedure calls but only use GOTOs, because "when the runtime unit sees a procedure call it has to take two steps back and make a run at it". He added that he knew what he was talking about because he had written the device drivers for the mainframe in COBOL. A lot of people still don't know what Clean Code means. It means that if you want your code to be maintainable then it has to be Clean. Regarding performance, in another comment here I report that in 20 years of production programming I have had to optimize code twice, which required adding one line of code and changing a config parameter.

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