This should help. Simplify your code. Don't do, x=1+1+1, just do x=3. This saves on memory, time , and it's easier to read. In this very basic example you save about 57% of memory that you would have used.
1. Always name your properties or variables in such a way that leaves absolutely no room for confusion/misunderstanding/ambiguity 2. Always capture a complicated piece of logic in a very descriptive, self-reading variable. 3. Avoid double negative (`const isNotBlocked = false` --> `const isBlocked = true`)
@@RohanDaDev I don't think you should watch it actually. Those 3 points cover everything in the video, which is aimed at novice programmers IMO and accounts for less than 5% of what it actually takes to produce clean code.
The tip I would like to add is "Don't get obsessed about premature abstractions, sometimes let there be two are more functions that look similar, dont generalize them into a single function"
Very interesting approach on how to write clean code. I really believe that the main key to write clean code is to always think on other developers. The quicker your team mate understands your code, the better (or cleaner) it is.
Another principle I try to follow: Whenever you have a chunk of code that logically belongs together, make a function out of it, even if it is not used anywhere else. It makes it much easier to read code and find the section that might cause errors.
I have to say i am impressed by the simplicity of your explanation of this - most often - fuzzy seeming concept. I am feeling like the one thing i have to understand and to put a punchline in my head: make your code readable to a human that does not think like a programmer. That makes life easier for a programmer. Great stuff!
I love these tips. Clement can catch things that is so true but rarely talked about. This is true in all of your videos, and this is why you are so awesome
This is so important even when you are new you still need to learn this i think this is important more than making your code works. Because if you understand your code you can actually figure out whats wrong with your code and fix it.
Stumbled across your channel and I love the concise and descriptive way you explain things. I was also surprised to find out that, like me, you are of Romanian descent! Multumesc mult pentru ajutor :)
Hello Clement, I love watching your videos and I am inspired by your story. I am Deaf and I am aspiring software engineer because I love coding. I am customer of your product - Algoexpert.io and I have learned some amazing things. It is tough for a Deaf software engineer to get job but I don't let my deafness limits my abilities. And other thing that I would like to ask is to add closed captions so it would be beneficial for me and other deaf people who could be watching your videos. Accessibility is valuable for me in order to gain the information.
I have taken this advice like four times and always revert back to complex code blocks because I want to save lines. This is so important. Just reading over my code from a few weeks ago it takes time for me to get back into my state of mind when I was writing it. Sometimes I look over my code and just trust that I knew what I was doing when I wrote it. I need to make a sign above my monitor telling me to write it cleaner. >.>
Thank you so much, I've started a degree in multimedia engineering and I've had trouble with the time I had to spend reading several times the code I've written the previous days so that I could continue coding. I know this will help me a lot to reduce that time spent
Minor tip, since Typescript 3.7 you can replace (!!meeting.permissions && meeting.permissions.canCancel) jwith just !!meeting.permissions?.canCancel. Much cleaner :) Great video!
Such important pieces of advice that I advocate in my codebase as well :) , its not hard to write clean code, it just takes some clear thought on what exactly you are trying to say. Never allow ambiguity into the code or if its needed, then try to simplify it was best as you can. Putting comments everywhere. Also one thing that Clem should add is add comments, even oneline comments to explain things, It helps readability significantly! You should relegate LARGE code block comments when you have complex logic that needs specific calling out. Good variable names are a must in all codebases too, avoid that double negative.
Another tip that's worth noting is to avoid things like `data.error.code != 3` (around 13:30). That 3 represents something human readable so put it in a enum, constant or something else that lets the reader know what it means.
For example 2, I would abstract the logic into a function. I really like the idea breaking the Boolean expression into parts and assigning those parts to descriptive variables
Man I did all of this, every single tip you mentioned, in a production code. I am that dumbass bastard. Cant believe I am so called "software engineer". I literally feel dumb and exposed now. Straight to the point man.
I disagree with your tip of adding the "string" word in the variable name to say expirationDateString. I'd say this is bad code actually, as it encodes to the type in the variable name. The type is already in the typescript, that's what it's there for. We should avoid redundant encoding.
Thanks - really enjoyed this. I’ve seen that double negative stuff before and that made me laugh 😂. Here’s a tip I like. Use a declarative style. Instead of telling the computer exactly what to do, describe what you want as a result instead. A good example is to map over an array, instead of using a loop to iterate over it’s contents. The abstraction of the process makes the code easier to read and the meaning and intention of the code is much clearer to whoever reads it in future.
Using object properties (canX, canY, canZ) is a big L. Just use one number for flags. Then wrap the cryptic bitwise operations in a function. interface IUser { permissions: number; } function can(permission) { return permission & permissions == 1; } On the server side you can have an enum like this: enum Permission { cantDoShit = 0; canX = (1
I'd love more of these types of videos too 🙂. Code structure/organization, clean code.. best practices in general for the individual coder and for a coder on a team. One thing I actually don't ever see, though I'm yet to experience (yet hear is important), is knowing what sorts of issues come up in teams and how to best deal with them. Maybe disagreements on deadlines? Coding styles (if the company doesn't have an agreed style already)? I dunno.
nice! Can you make video about how to correctly name variables, constants, functions, classes, files... and what form should they have (capitals, underscores, what to avoid, ...). I know, that some of this things are different based on programming language that you use, but at least some general tips would be rly nice.
According to Clément, Good Naming practices - Boolean naming practices (isBlocked instead of isNotBlocked) - Condensing complex code into a well-defined variable name Good naming practices also avoid ambiguity - whether a variable is a string, integer, boolean, etc.
Make your code as grepable as possible, there are times where your refactoring tools will not save you. Especially when you do C/C++ and have multiple platform parts where no semantic refactoring tools work on the whole code base.
Great examples, clear explanation ! I'm relieved using several variables are recommended (I wasn't sure about it before), that should come very intuitively. But I'm also laughing because "you wouldn't know what this means!" when you read a lot of messy beginner code in group projects you start to get used to it hahah
The negative variable name thing is sometimes necessary in low-level languages like C, because in C it's very easy and efficient to initialize the entire data structure to zeros. So to have the variable's default value be false and yet have a sane meaning, the variable name sometimes needs to be negated. I'm not saying that this is the correct way to do things, especially for modern languages, but I think it's a valid argument.
Great tips, btw just a remark (as i have made this mistake before on a critical PR) : - new Date() < new Date(meeting.startTime) isn't the same as !(new Date() > new Date(meeting.startTime) - !(new Date() > new Date(meeting.startTime)) is the same as new Date()
The isBlocked better than isNotBlocked suggestion is debatable IMO. It depends on what your code is doing, and that's because the "!" negation could be easily overlooked and add cognitive overhead especially when the if statement has multple conditions. I totally agree with you that if (!isNotBlocked) is not good all. However, if (isNotBlocked) is a lot easier to read than if(!isBlocked). But that's just my opinion. Great stuff. Keep it up!
A good default value for any boolean is False, and a good way of avoiding negations in variable names is to use a synonym. Taking these guidelines into consideration, I would prefer either "IsAllowed" (= False) or "IsBlocked" (= False), instead of "IsNotBlocked".
I'm a big fan of hungarian or reverse hungarian; isExpired is arguably hungarian-like and expirationDate is reverse-hungarian-like; ie type is appended What do you think of the argument that consistency between one or the other improves codebase quality? On my corporate team my peers seem to think this is too nitpicky
Hi @clement mihailescu, this video was good, thanks for sharing. One improvement on tip number 2 - it's good put showcancelmeetingbutton logic in seperate function and call it from main function, so that it can be unit tested and it looks more clean 😉
Great video. I do slightly disagree with #3. I think it's "clean" to use isNotBlocked especially if it's used to drive your #2 point and used uniformly within a class or function. However, I think you're totally right that once that usage changes and you start needing to use both positive and negative forms, then it's better to go with isBlocked.
unrelated but for some reason I believe you need water after every sentence you speak . Not taking away your content is awesome but seems all your muscles are on high octane when you speak. Your platform is one of the clean , organized and helpful kudos!!
He's too dogmatic. Lots of good stuff but also a lot of weird things like NEVER have a boolean parameter to a method, NEVER have your methods more than 4 lines long. Where I think "fkn relax man".
@@jamesevans2507 well, boolean as an argument to a function would contradict with his statement that functions should do one thing and one only - with boolean you kinda expect the function do 2 things based on its value. But I agree with you
Good stuff. Uncle Bob had a maxim that "a function should represent 1 level of abstraction" and I stress that one at work everyday. It's a little hard to be a purist about that with front end function components (because they are sometimes incapable of "doing only one thing"), but on the backend it's easier to be a purist about it. What you end up finding is a lot like example 2-- you find yourself building towers of logic? Break them up, move them to a place for just that logic. Are there conceptually different chunks of that logic? Do it again. Repeat until you can't anymore (without being silly). Write code this way and your towers and rightward-shifting pyramids go away. You get a bunch of little hemmingway sentences.
Uncle Bob is an Anti-Pattern. I follow John Ousterhouse. Write long code and methods and then abstract them. If you can't handle a 500 line function then your life as programmer failed. The only thing that must be small and good designed is your API.
I'm so glad i'm doing that without even knowing that is a good practice(it just seems easy to myself) but in your tip 3, I am the same I have a code base that does that alot and every time i'm scratching my head and and saying to myself WTF is that what do they mean and it takes couple of cycles and going up and down though the whole code to understand what is going on. Anyways thanks for sharing that with us! :)
As a non-English speaker, when using a variable to store a unix timestamp, I have struggled to determine which expression is grammerly correct: expire_time, expired_time, expiry_time, expiration_time. Finally, it turns out that all the phrases above exist in my code. I found that while I was reviewing my historical code.
expire_time is probably the most reasonable. grammatical matters really shouldn't be a consideration when naming things. the grammar of the programming language is enough to communicate the grammatical role of the symbol.
@@healthy7219 no, its mainly because its the simplest. That just happens to coincide with shortness here, but for example, I would not choose "tm_xpry" over "time_expiry", because while shorter, its not simpler to understand the intended meaning.
I really like that you spent time on number three back on number two I was considering why wouldn't you just say meeting hasn't started instead of has meeting started for your variable and that would have been a double negative!!! Also for #1 I love having a readonly boolean set to if the current date is greater than the expiration so nothing could tamper with that subscription except the date that controls the expiration--love this video!
This video was really good, the "Wtf is that?" got me good lol Just wondering though, would anyone consider the creation of all of those variables to handle complex logic poor memory usage? I'm fairly new to this, and it's also not the 1970s anymore in terms of RAM lol, but you see what I'm saying?
Don’t think too much about this. Compilers can optimize this stuff and inline variables/functions. Write clean code and it will work fast enough most of the times
It obviously depends on the context of the specific situation, but I'd guess that the benefits of having clean code (i.e saving time when future devs read that piece of code) outweigh the negatives of using slightly more RAM.
Using the appropriate keyword like "const" in JS/TS/C or "final" in Java will let the compiler knows that the variable will never change and it will optimize your code before executing it. Sometimes, trying to outsmart the compiler can even be counterproductive.
@Clément Mihailescu , I guess this video can be a small part of the "Problem-solving pattern": 1. Understand the Problem 2. Explore Concrete Examples 3. Break It Down 4.Solve/Simplify 5. Look Back and Refactor
I really appreciate the video , it will be great if you do a video about how to architecture your projects , and the steps to do before implementation ^^
Great video! 2 questions, for maybe a next one: 1. I see you're using interfaces instead of type aliases for the Props of you React component. But I've seen already a few times that someone is saying that you should use a type (now) for that instead of an interface. Thing is that I did not found a good answer/reason for doing that... I just think that an 'interface' expresses the purpose of it better than 'type' does. What's your opinion, is there a clear good answer to this, type vs interface? 2. Again, I saw you're using an enum in this video where I thought a string literal union would have been more helpful?! I just can't find any use for enums, unless when you would need a list of constants that needs to have a strict unchangeable order.
Why format code line length < 80 characters? 17:11 line 23,24,25 To me this is ugly and yet we have big monitors, even laptops can comfortably allow the occasional line of long code. thoughts?
So who's gonna join me in cleansing their code of its filth?
probably not me
im too lazy :D
🙌
rm -r /my-code . Done it’s cleansed !
You always bring the value, the mvp
This should help.
Simplify your code. Don't do, x=1+1+1, just do x=3. This saves on memory, time , and it's easier to read. In this very basic example you save about 57% of memory that you would have used.
1. Always name your properties or variables in such a way that leaves absolutely no room for confusion/misunderstanding/ambiguity
2. Always capture a complicated piece of logic in a very descriptive, self-reading variable.
3. Avoid double negative (`const isNotBlocked = false` --> `const isBlocked = true`)
Thank you for saving me 17 min of my life.
@@fanyinU Still worth watching the video. He provides thorough relatable examples
@@fanyinU u should watch still
@@RohanDaDev I don't think you should watch it actually. Those 3 points cover everything in the video, which is aimed at novice programmers IMO and accounts for less than 5% of what it actually takes to produce clean code.
Thanks your explanation is more short and clean rather than his spaghetti explanation
Clean code series idea: Would be really great if you'd do a video on how to use OOP concepts correctly or more efficiently.
advanced and needs time, but very good idea!
Good idea
The tip I would like to add is
"Don't get obsessed about premature abstractions, sometimes let there be two are more functions that look similar, dont generalize them into a single function"
do not split everything to tiny piece too.
Amen. Especially don't add abstractions when the code is very easy and straightforward and would save you just a few hundert lines.
Very interesting approach on how to write clean code. I really believe that the main key to write clean code is to always think on other developers. The quicker your team mate understands your code, the better (or cleaner) it is.
Another principle I try to follow:
Whenever you have a chunk of code that logically belongs together, make a function out of it, even if it is not used anywhere else. It makes it much easier to read code and find the section that might cause errors.
this video single-handedly helped me SOOO much more than the hours of coding videos I have watched. Thank you.
I have to say i am impressed by the simplicity of your explanation of this - most often - fuzzy seeming concept. I am feeling like the one thing i have to understand and to put a punchline in my head: make your code readable to a human that does not think like a programmer. That makes life easier for a programmer. Great stuff!
I love these tips. Clement can catch things that is so true but rarely talked about. This is true in all of your videos, and this is why you are so awesome
This is so important even when you are new you still need to learn this i think this is important more than making your code works. Because if you understand your code you can actually figure out whats wrong with your code and fix it.
The way you described all the tips with examples was greatl Love your content!
17 min video from clement POG
Edit: Hell yeah, we want more of these vids
I just wanted to say I subscribed immediately after the "WTF does that mean?!?" part. lmfao. Great Content man. Can't wait to watch more.
Helpful video! For me clean code is:
1. Easy to read
2. Easy to understand
3. Less code - better code
Stumbled across your channel and I love the concise and descriptive way you explain things. I was also surprised to find out that, like me, you are of Romanian descent! Multumesc mult pentru ajutor :)
Hello Clement, I love watching your videos and I am inspired by your story. I am Deaf and I am aspiring software engineer because I love coding. I am customer of your product - Algoexpert.io and I have learned some amazing things. It is tough for a Deaf software engineer to get job but I don't let my deafness limits my abilities. And other thing that I would like to ask is to add closed captions so it would be beneficial for me and other deaf people who could be watching your videos. Accessibility is valuable for me in order to gain the information.
the captions were recently removed by youtube unfortunately
I have taken this advice like four times and always revert back to complex code blocks because I want to save lines. This is so important. Just reading over my code from a few weeks ago it takes time for me to get back into my state of mind when I was writing it. Sometimes I look over my code and just trust that I knew what I was doing when I wrote it. I need to make a sign above my monitor telling me to write it cleaner. >.>
Thank you so much, I've started a degree in multimedia engineering and I've had trouble with the time I had to spend reading several times the code I've written the previous days so that I could continue coding. I know this will help me a lot to reduce that time spent
I’m new to coding and very much appreciate these tips. Thank you!!
Please make more these type of vids, it looks pure gold to me
Minor tip, since Typescript 3.7 you can replace (!!meeting.permissions && meeting.permissions.canCancel) jwith just !!meeting.permissions?.canCancel. Much cleaner :) Great video!
Such important pieces of advice that I advocate in my codebase as well :) , its not hard to write clean code, it just takes some clear thought on what exactly you are trying to say. Never allow ambiguity into the code or if its needed, then try to simplify it was best as you can. Putting comments everywhere. Also one thing that Clem should add is add comments, even oneline comments to explain things, It helps readability significantly! You should relegate LARGE code block comments when you have complex logic that needs specific calling out. Good variable names are a must in all codebases too, avoid that double negative.
I'm still new to coding and these tips make a lot of sense. Thanks a lot man for your help 👍
Dude, that last one. I HAVE SEEN THAT THING HAPPEN SO OFTEN IT DOES NOT SEEM REAL. 10/10 great video.
Another tip that's worth noting is to avoid things like `data.error.code != 3` (around 13:30). That 3 represents something human readable so put it in a enum, constant or something else that lets the reader know what it means.
🤣😂
For example 2, I would abstract the logic into a function. I really like the idea breaking the Boolean expression into parts and assigning those parts to descriptive variables
Simply outstanding. Understood every bit of the explanation. Really clean code is very important. Thank you for such informative videos
Man I did all of this, every single tip you mentioned, in a production code. I am that dumbass bastard. Cant believe I am so called "software engineer". I literally feel dumb and exposed now. Straight to the point man.
I disagree with your tip of adding the "string" word in the variable name to say expirationDateString. I'd say this is bad code actually, as it encodes to the type in the variable name. The type is already in the typescript, that's what it's there for. We should avoid redundant encoding.
this guy is literally every software engineer and it's beautiful
Thanks - really enjoyed this. I’ve seen that double negative stuff before and that made me laugh 😂. Here’s a tip I like. Use a declarative style. Instead of telling the computer exactly what to do, describe what you want as a result instead. A good example is to map over an array, instead of using a loop to iterate over it’s contents. The abstraction of the process makes the code easier to read and the meaning and intention of the code is much clearer to whoever reads it in future.
Yes! I love it when a framework will let me give it just an anonymous function which it applies to everything.
Thanks for this amazing video Clem! We would definitely want a series on this !
Anyone else check their slack at 10:57 when he got a notification or just me? 😂
For that moment I thought I still had my job and they were messaging me :-p
Using object properties (canX, canY, canZ) is a big L. Just use one number for flags. Then wrap the cryptic bitwise operations in a function.
interface IUser {
permissions: number;
}
function can(permission) {
return permission & permissions == 1;
}
On the server side you can have an enum like this:
enum Permission {
cantDoShit = 0;
canX = (1
For the 3rd tip... If you were reviewing my code , I would write that everywhere ..just to get that expression at 14:05 ...priceless
Make sense in all what you said. Hopefully more programmers will know this coding and evaluate their way of coding. Thanks for the vid!
I'd love more of these types of videos too 🙂. Code structure/organization, clean code.. best practices in general for the individual coder and for a coder on a team. One thing I actually don't ever see, though I'm yet to experience (yet hear is important), is knowing what sorts of issues come up in teams and how to best deal with them. Maybe disagreements on deadlines? Coding styles (if the company doesn't have an agreed style already)? I dunno.
I have the same wonders
nice! Can you make video about how to correctly name variables, constants, functions, classes, files... and what form should they have (capitals, underscores, what to avoid, ...). I know, that some of this things are different based on programming language that you use, but at least some general tips would be rly nice.
Great video. As they say, good code uses comments, great code is self-explanatory.
Just subscribed-great video! This advice should be followed by every programmer.
Finaly someone talking about real life applicable tips in a video starting with "x tips to..." :)
Please make it a series, it's amazing
According to Clément,
Good Naming practices
- Boolean naming practices (isBlocked instead of isNotBlocked)
- Condensing complex code into a well-defined variable name
Good naming practices also avoid ambiguity - whether a variable is a string, integer, boolean, etc.
Make your code as grepable as possible, there are times where your refactoring tools will not save you. Especially when you do C/C++ and have multiple platform parts where no semantic refactoring tools work on the whole code base.
Great examples, clear explanation !
I'm relieved using several variables are recommended (I wasn't sure about it before), that should come very intuitively.
But I'm also laughing because "you wouldn't know what this means!" when you read a lot of messy beginner code in group projects you start to get used to it hahah
Love this video. Especially 14:05! LOL I must said that many times at code reviews. I kept rewinding.
The negative variable name thing is sometimes necessary in low-level languages like C, because in C it's very easy and efficient to initialize the entire data structure to zeros. So to have the variable's default value be false and yet have a sane meaning, the variable name sometimes needs to be negated. I'm not saying that this is the correct way to do things, especially for modern languages, but I think it's a valid argument.
Any idiot can write code that a computer can understand, but only genius can write code that a human can understand
-a wise man
Nice
Great tips, btw just a remark (as i have made this mistake before on a critical PR) :
- new Date() < new Date(meeting.startTime) isn't the same as !(new Date() > new Date(meeting.startTime)
- !(new Date() > new Date(meeting.startTime)) is the same as new Date()
Love the clean code videos!
Please, keep them coming
Let's see more tips on cleaning up code! Great video!
Since isBlocked is a const at 15:49 and set to true, the else block will never run!
Sorry for being pedantic :)
Awesome videos Clement!
The isBlocked better than isNotBlocked suggestion is debatable IMO. It depends on what your code is doing, and that's because the "!" negation could be easily overlooked and add cognitive overhead especially when the if statement has multple conditions. I totally agree with you that if (!isNotBlocked) is not good all. However, if (isNotBlocked) is a lot easier to read than if(!isBlocked). But that's just my opinion. Great stuff. Keep it up!
A good default value for any boolean is False, and a good way of avoiding negations in variable names is to use a synonym. Taking these guidelines into consideration, I would prefer either "IsAllowed" (= False) or "IsBlocked" (= False), instead of "IsNotBlocked".
Really enjoyed this one. Doing this caused a good discussion on one of my recent code reviews a month or two ago. Thanks!
13:56 Dude it is 6AM right now and you legit just made me burst out laughing LOL
I love these videos with tips about correct use, I want more
Not to be dramatic but you are a hero 👏 I really like this series! Maybe something with CTE statements 😄
AMAZING video! You should definitely do a series on clean code!!! Not easy to find good quality content about this online
I'm currently reading Clean Code in Javascript. Tried to read Uncle Bob's books, but java made it a little bit hard to follow
I'm a big fan of hungarian or reverse hungarian;
isExpired is arguably hungarian-like and expirationDate is reverse-hungarian-like; ie type is appended
What do you think of the argument that consistency between one or the other improves codebase quality?
On my corporate team my peers seem to think this is too nitpicky
incredible insight, thank you so much Clément
Hi @clement mihailescu, this video was good, thanks for sharing. One improvement on tip number 2 - it's good put showcancelmeetingbutton logic in seperate function and call it from main function, so that it can be unit tested and it looks more clean 😉
Would be nice to have it as a series, thanks.
GREAT VIDEO...Valuable lessons... We need part 2 ... Anyone wants part 2 as well? Like
Thank you Clem. Keep making these videos and educate more programmers. Ciao!
Great video. I do slightly disagree with #3. I think it's "clean" to use isNotBlocked especially if it's used to drive your #2 point and used uniformly within a class or function. However, I think you're totally right that once that usage changes and you start needing to use both positive and negative forms, then it's better to go with isBlocked.
unrelated but for some reason I believe you need water after every sentence you speak . Not taking away your content is awesome but seems all your muscles are on high octane when you speak. Your platform is one of the clean , organized and helpful kudos!!
Please make this a series. I am good at algorithms. But really suck at this type of things.
Loved this video! You could go through different github repos and make a video “Reacting and refactoring unclean code”
Clement always finds a way to advertise his company
😎
That's awesome. It would be definitely great, if we can witness some more of such instances of clean code. Thanks for putting this up
great tips. now i am gonna apply these tips in my every projects. thank u mate.
14:03 this is so true, this confuses me so hard when I see someone use this logic.
14:05 so true XD. I am guilty of yelling something like that in a room meeting XD
How to write clean code ?
Only one tip : watch uncle bob martin's
Clean code series.
His Minecraft sword lol
He's too dogmatic. Lots of good stuff but also a lot of weird things like NEVER have a boolean parameter to a method, NEVER have your methods more than 4 lines long. Where I think "fkn relax man".
@@jamesevans2507 well, boolean as an argument to a function would contradict with his statement that functions should do one thing and one only - with boolean you kinda expect the function do 2 things based on its value. But I agree with you
These tips are not picky at all! It is really really important
Good stuff. Uncle Bob had a maxim that "a function should represent 1 level of abstraction" and I stress that one at work everyday. It's a little hard to be a purist about that with front end function components (because they are sometimes incapable of "doing only one thing"), but on the backend it's easier to be a purist about it.
What you end up finding is a lot like example 2-- you find yourself building towers of logic? Break them up, move them to a place for just that logic. Are there conceptually different chunks of that logic? Do it again. Repeat until you can't anymore (without being silly). Write code this way and your towers and rightward-shifting pyramids go away. You get a bunch of little hemmingway sentences.
Uncle Bob is an Anti-Pattern. I follow John Ousterhouse. Write long code and methods and then abstract them. If you can't handle a 500 line function then your life as programmer failed. The only thing that must be small and good designed is your API.
I'm so glad i'm doing that without even knowing that is a good practice(it just seems easy to myself) but in your tip 3, I am the same I have a code base that does that alot and every time i'm scratching my head and and saying to myself WTF is that what do they mean and it takes couple of cycles and going up and down though the whole code to understand what is going on. Anyways thanks for sharing that with us! :)
You got me on 14:05 Cool video. Hope to see more like this.
Excellent content! I've been learning a lot from your videos. Thank you so much!
As a non-English speaker, when using a variable to store a unix timestamp, I have struggled to determine which expression is grammerly correct: expire_time, expired_time, expiry_time, expiration_time. Finally, it turns out that all the phrases above exist in my code. I found that while I was reviewing my historical code.
expire_time is probably the most reasonable. grammatical matters really shouldn't be a consideration when naming things. the grammar of the programming language is enough to communicate the grammatical role of the symbol.
@@homelessrobot Is your choice of expire_time because it is the shortest, without so much keyboard typing?
@@healthy7219 no, its mainly because its the simplest. That just happens to coincide with shortness here, but for example, I would not choose "tm_xpry" over "time_expiry", because while shorter, its not simpler to understand the intended meaning.
I really like that you spent time on number three back on number two I was considering why wouldn't you just say meeting hasn't started instead of has meeting started for your variable and that would have been a double negative!!! Also for #1 I love having a readonly boolean set to if the current date is greater than the expiration so nothing could tamper with that subscription except the date that controls the expiration--love this video!
Wow, this is fantastic! Thanks Clément!
This video was really good, the "Wtf is that?" got me good lol
Just wondering though, would anyone consider the creation of all of those variables to handle complex logic poor memory usage? I'm fairly new to this, and it's also not the 1970s anymore in terms of RAM lol, but you see what I'm saying?
Don’t think too much about this. Compilers can optimize this stuff and inline variables/functions. Write clean code and it will work fast enough most of the times
It obviously depends on the context of the specific situation, but I'd guess that the benefits of having clean code (i.e saving time when future devs read that piece of code) outweigh the negatives of using slightly more RAM.
Using the appropriate keyword like "const" in JS/TS/C or "final" in Java will let the compiler knows that the variable will never change and it will optimize your code before executing it.
Sometimes, trying to outsmart the compiler can even be counterproductive.
last one was just amazing 😃.. enjoyed watching video ☺. we wanna more such videos . thank you for making such helpful videos .👍
Wow ... Super Duper simple explanation. Loved it man
The double negative implementations normally is the result of straightly implementing logic based on exactly how the requirements are written.
Enjoyed this video immensely, would love to see 3 more! :)
this is my favourite video on the internet and I am including all the cats and dogs videos.
This is amazing dude and crazy. Thank you so much. Keep up please!
Clement this is a great video! Please make more of these :)
isExpired looks read only. It can be user as a function isExpired() or as read only property.
(This is something, I think and use)
@Clément Mihailescu
, I guess this video can be a small part of the "Problem-solving pattern":
1. Understand the Problem
2. Explore Concrete Examples
3. Break It Down
4.Solve/Simplify
5. Look Back and Refactor
I really appreciate the video , it will be great if you do a video about how to architecture your projects , and the steps to do before implementation ^^
Make it a Series! The whole world benefits from cleaner code 🙂
Great video! 2 questions, for maybe a next one: 1. I see you're using interfaces instead of type aliases for the Props of you React component. But I've seen already a few times that someone is saying that you should use a type (now) for that instead of an interface. Thing is that I did not found a good answer/reason for doing that... I just think that an 'interface' expresses the purpose of it better than 'type' does. What's your opinion, is there a clear good answer to this, type vs interface? 2. Again, I saw you're using an enum in this video where I thought a string literal union would have been more helpful?! I just can't find any use for enums, unless when you would need a list of constants that needs to have a strict unchangeable order.
Thank you for the Video, do many Variables slow down the performances?
Why format code line length < 80 characters?
17:11 line 23,24,25
To me this is ugly and yet we have big monitors, even laptops can comfortably allow the occasional line of long code.
thoughts?
"What the F*** does that mean" 😂😂😂
Great video with concepts that really should become standard! Thanks
Great explanation!!! And the funniest part was !isNotBlocked, is blocked or not?!
You can clean up example_1.tsx bit further by optionally chaining meeting?.permissions?.canCancel. Presumably if you're using Typescript 3.7+