Totally agree. I hate comments which just say what the next line is doing. They get so distracting that i have set my editor to color comments almost the same as the background color. So they don't interfere when reading code
I've had a boss yell at me for putting so much commenting in my code, specifically why I'm doing something and what else I've tried. I told him "In 6 months, I'm not gonna remember any of this. Or I might get hit by a bus. Would you rather someone spend a day or a week trying to fix or implement something new on top of what I wrote?" He was all about "I want it now" rather than "I don't care about 6 months from now." Interesting that I do a lot of what you mention and only had 2 computer science classes in college. The rest were in Chemistry, yet I only use my degree in the kitchen when I cook. I'm sure there are other who code much faster but I consider myself blessed that I've NEVER had to code anything in Cobol.
@@michaelvilain8457 I would disagree with you on this. Code itself must be self-explanatory with most high-level programming languages. If you cant understand the code, you dont have enough understanding. The comment might be misleading if you update the code and dont update the comment.
@@nghianguyen170192well said! Code should always be self explanatory if possible. Only use docs when it's really needed, like a weird workaround or to mark something that really needs to be changed. For external packages it can still be good to add, just to make things a little bit easier for others / save them from the potential effort to look it up
@@nghianguyen170192Nah, I disagree. Sometimes I'm tired or in a hurry and want a summary of a function, or even a loop. I sure can read and understand what's going on, but comments make it faster.
I have 14 years of experience as a business architect, yet I see people doing better job at summarising concepts in our pipelines here (not to mention, in the most creative way possible). I love your book too. Cheers! Thanks...🎉
00:01 Coding style ensures consistent and readable code. 00:40 Write clean, understandable code with helpful comments 01:24 Robustness is key in coding principles 02:07 Coding principles help create modular and organized code. 02:49 Use single responsibility principle and automated testing for success 03:31 Database class helps keep main app logic clean 04:16 Passing parameters enhances code organization and understandability. 05:00 Security is everyone's job in coding. Crafted by Merlin AI.
Not sure if anybody told you this. But you are awesome. You have this capability to dumb down complex concepts in a brilliant way. "Dumbing down"... that is your super power.
THANK YOU for bringing the obvious truth to the masses: Code tells you 'How', comments tell you 'Why'. My colleagues seem to be to stupid to understand this and will simply deny writing any comments at all.
Getting to the bottom of when and why the pernicious idea of "comments mean not clear enough code" got off the ground could be real interesting. And we'd know who to off when time travel becomes a thing.
Same comment for unhelpful maintenance log entries. "Fixed a date function" - what was wrong? "Added another parm" - to do what? "Initialized a variable" - which one and why? I just never understood the lack of a short in code comment like "Leap year logic". "Extra Last day of Business Month processing." "Prevent zero divide".
Comments are for speed also. Id rather read a comment than a whole block of code. Too much comments is better than too little. Be generous to the next person
@@skyhappy that's not appropriate way to use comments. When your code is long, do refactor. Comments should only be used to explain "why" you do something.
@@TrungNguyen-mj2id I'm not sure how much code you've written. There are always blocks of code that should be in one function and breaking it up only breaks the flow. 1 simple comment allows someone to skip reading 10-20 lines of code. It's much more read optimized
Your comment on 'robustness' is extremely important. People usually write code on the 'happy path.' However handling errors, bad data, and anomalies is critical. Code in production simply can't fail. It has to handle any situation.
I follow you on LinkedIn and RUclips. Out of curiosity, I have one thing mesmerizing about how you are making these beautiful gif. Keep posting content like this.
Thank you for your wonderful contents. P.S: There's a typo in 2:34, eatable interface is estable And Easy to test is East to test in the side of the circle
This is a great video with really valuable recommendations. Thus, please take my comments regarding the typos not as a critique of the content. - At 2:07 in the SOLID principles explanation section, I noticed a typo ISP => Interface Segregation Principle. The word Interface is misspelled. - At 2:30 the interface Eatable is misspelled (Estable in the video) - At 3:02 the last sentence of Security Test. It probably should state "penetration" testing (instead of penetrating testing) - At 4:41 the content of the white circle probably should be Refactor instead of Refractor
2:23 The bad example rectangle class has three getWidth() functions, two of them with identical signature (copy/paste error), the other one probably meant to be a setter
This is a coding principles explanation video. All codedwarfship is of the highest quality. It is encrusted with clear, eye-catching visuals and reassures with simple, easy to apply tips. In the video is a reminder to write comments for "why", not "how". It relates to whole swaths of coders not writing a single line of documentation anywhere. Jokes aside, the quality and density of advice given here is through the roof!
I love your videos and watch every single one of them, but I have a recommendation. I have been noticing an increase in typos over recent videos, like for example in SOLID the Interface Segregation Principle has a typo and a line below that also is having a mistake in DIP acronym. I love your videos but doing a grammar review once before uploading would be a good indicator for your audience to show the amount of effort you put into your videos, and before major typos become a thing. Lovely video otherwise, lots of great information :D
I strongly agree all of them. Nonetheless, I noticed that a passion to do so and a habit to do so are more important. Often times, they compromise and do not spend 1 more hour on writing better comments but simply call it a day.
Commenting is very hard. I like the traditional style emacs lisp is commented: each style starts with a big comment giving some commentary. Each file also ends with a comment, but this is mostly for historical reasons. functions defined by defun, variables defined by defvar and defcustom as well as macros (note: lisp macros aren’t not preprocessor macros) have an in-build document-string. This means that documentation is defined while writing code, but accessed independently of it. If you want to use a function you first pull out the document string, not the definition. The system forces you to write actually useful comments because you can’t rely on the code to explain your documetation. After this, comments on code are rarely needed. You can still make them of course, but you already wrote few paragraphs describing the whole file and you wrote documentation for each function so you rarely need to clarify the implementation. Many comments feel necessary only because the purpose and intended usage of the whole function or module was never written down. After those are clarified, the code can be awkward and non-straightforward, but still be understood. Good types and names can do this, but one brief documentation paragraph or two makes it very clear.
I mean they are vital when you talking about well designed Object Oriented Design, which is good when you want properly abstracted code, it's like yes NoSql DBs are popular but there is use in being able to normalize a SQL table to make queries efficient
No matter how well you name your functions etc. it would never tell you _why_ something had to be done. Nothing replaces good comments/code documentation when it comes to this.
Saying the *_word_* sequel when you mean the *_acronym_* SQL is confusing and illogical. You don't turn an acronym into a word unless the entire acronym IS a word, or you are simply using the word *_the acronym actually represents._* Throwing that entirely unrelated word in as an unnecessary expansion of the shortened acronym is going in the opposite direction of the entire point of using an acronym in the first place, and it is only confusing. Because nobody can tell which letters comprise the actual shortened term, phrase or title and which letters were just arbitrarily thrown in to make it a word. We pronounce SWAT because all the letters are in the word, but we spell out FBI instead of throwing a few more vowels and consonants in to confuse people. We don't call the FBI "FibBIng cops" Sequel is a now defunct proprietary DBMS that stopped being used or sold in the mid 1980s. SQL is an acronym for structured query language. Is you say "ess, kyew, ell" I might have a chance at figuring out s stands for struxtured, q stands for query and l stands for language. When you say sequel I might decide that sequel is how you pronounce the acronym SEQL or SQUL and now I'm thinking you're talking about symmetrical energy quotient levels of Standardized Electronic Quartz Lighting because I lost context and have nothing to work with besides the phonetic sound "sequel."
"remember code tells you how comments tell you why" This is actually so good 🔥
Totally agree. I hate comments which just say what the next line is doing.
They get so distracting that i have set my editor to color comments almost the same as the background color. So they don't interfere when reading code
I've had a boss yell at me for putting so much commenting in my code, specifically why I'm doing something and what else I've tried. I told him "In 6 months, I'm not gonna remember any of this. Or I might get hit by a bus. Would you rather someone spend a day or a week trying to fix or implement something new on top of what I wrote?" He was all about "I want it now" rather than "I don't care about 6 months from now."
Interesting that I do a lot of what you mention and only had 2 computer science classes in college. The rest were in Chemistry, yet I only use my degree in the kitchen when I cook. I'm sure there are other who code much faster but I consider myself blessed that I've NEVER had to code anything in Cobol.
@@michaelvilain8457 I would disagree with you on this. Code itself must be self-explanatory with most high-level programming languages. If you cant understand the code, you dont have enough understanding.
The comment might be misleading if you update the code and dont update the comment.
@@nghianguyen170192well said! Code should always be self explanatory if possible. Only use docs when it's really needed, like a weird workaround or to mark something that really needs to be changed. For external packages it can still be good to add, just to make things a little bit easier for others / save them from the potential effort to look it up
@@nghianguyen170192Nah, I disagree. Sometimes I'm tired or in a hurry and want a summary of a function, or even a loop. I sure can read and understand what's going on, but comments make it faster.
I have 14 years of experience as a business architect, yet I see people doing better job at summarising concepts in our pipelines here (not to mention, in the most creative way possible). I love your book too. Cheers! Thanks...🎉
00:01 Coding style ensures consistent and readable code.
00:40 Write clean, understandable code with helpful comments
01:24 Robustness is key in coding principles
02:07 Coding principles help create modular and organized code.
02:49 Use single responsibility principle and automated testing for success
03:31 Database class helps keep main app logic clean
04:16 Passing parameters enhances code organization and understandability.
05:00 Security is everyone's job in coding.
Crafted by Merlin AI.
great... use single responsibility principle and automated testing... my fail :(
Not sure if anybody told you this. But you are awesome. You have this capability to dumb down complex concepts in a brilliant way.
"Dumbing down"... that is your super power.
THANK YOU for bringing the obvious truth to the masses: Code tells you 'How', comments tell you 'Why'. My colleagues seem to be to stupid to understand this and will simply deny writing any comments at all.
Getting to the bottom of when and why the pernicious idea of "comments mean not clear enough code" got off the ground could be real interesting. And we'd know who to off when time travel becomes a thing.
Same comment for unhelpful maintenance log entries. "Fixed a date function" - what was wrong? "Added another parm" - to do what? "Initialized a variable" - which one and why? I just never understood the lack of a short in code comment like "Leap year logic". "Extra Last day of Business Month processing." "Prevent zero divide".
Comments are for speed also. Id rather read a comment than a whole block of code. Too much comments is better than too little. Be generous to the next person
@@skyhappy that's not appropriate way to use comments. When your code is long, do refactor. Comments should only be used to explain "why" you do something.
@@TrungNguyen-mj2id I'm not sure how much code you've written. There are always blocks of code that should be in one function and breaking it up only breaks the flow. 1 simple comment allows someone to skip reading 10-20 lines of code. It's much more read optimized
I really like your content and I really like the “5 minute video” format, I think this length is optimal for tech video.
Your comment on 'robustness' is extremely important. People usually write code on the 'happy path.' However handling errors, bad data, and anomalies is critical. Code in production simply can't fail. It has to handle any situation.
I follow you on LinkedIn and RUclips. Out of curiosity, I have one thing mesmerizing about how you are making these beautiful gif.
Keep posting content like this.
Thank you for your wonderful contents.
P.S:
There's a typo in 2:34, eatable interface is estable
And Easy to test is East to test in the side of the circle
Finally getting serious about this path and was happy to run across this site. Looking forward to benefiting from past and future tips and guidelines.
This is a great video with really valuable recommendations. Thus, please take my comments regarding the typos not as a critique of the content.
- At 2:07 in the SOLID principles explanation section, I noticed a typo ISP => Interface Segregation Principle. The word Interface is misspelled.
- At 2:30 the interface Eatable is misspelled (Estable in the video)
- At 3:02 the last sentence of Security Test. It probably should state "penetration" testing (instead of penetrating testing)
- At 4:41 the content of the white circle probably should be Refactor instead of Refractor
2:23 The bad example rectangle class has three getWidth() functions, two of them with identical signature (copy/paste error), the other one probably meant to be a setter
This is a coding principles explanation video. All codedwarfship is of the highest quality. It is encrusted with clear, eye-catching visuals and reassures with simple, easy to apply tips. In the video is a reminder to write comments for "why", not "how". It relates to whole swaths of coders not writing a single line of documentation anywhere.
Jokes aside, the quality and density of advice given here is through the roof!
I love your videos and watch every single one of them, but I have a recommendation. I have been noticing an increase in typos over recent videos, like for example in SOLID the Interface Segregation Principle has a typo and a line below that also is having a mistake in DIP acronym. I love your videos but doing a grammar review once before uploading would be a good indicator for your audience to show the amount of effort you put into your videos, and before major typos become a thing. Lovely video otherwise, lots of great information :D
Yea i guess its a case of the video editor may not be from a CS background or may not be an English speaker
I strongly agree all of them. Nonetheless, I noticed that a passion to do so and a habit to do so are more important. Often times, they compromise and do not spend 1 more hour on writing better comments but simply call it a day.
Code style != Code structure, always remember to make your code extensible and maintainable with design patterns
A great step by step explanation of principles developers should employ!!
Commenting is very hard. I like the traditional style emacs lisp is commented: each style starts with a big comment giving some commentary. Each file also ends with a comment, but this is mostly for historical reasons.
functions defined by defun, variables defined by defvar and defcustom as well as macros (note: lisp macros aren’t not preprocessor macros) have an in-build document-string.
This means that documentation is defined while writing code, but accessed independently of it. If you want to use a function you first pull out the document string, not the definition. The system forces you to write actually useful comments because you can’t rely on the code to explain your documetation.
After this, comments on code are rarely needed. You can still make them of course, but you already wrote few paragraphs describing the whole file and you wrote documentation for each function so you rarely need to clarify the implementation.
Many comments feel necessary only because the purpose and intended usage of the whole function or module was never written down. After those are clarified, the code can be awkward and non-straightforward, but still be understood. Good types and names can do this, but one brief documentation paragraph or two makes it very clear.
Excellent reminders and suggestions! 😎✌️
Really love your videos, very informative 🙂
In the SOLID section the header says Robustness
Great graphics! Who does them for you?
i want to know too, tell me if you find please
Hello! I love it! And how to create those awesome visuals like in the video? Anyone know? Thanks
adobe illustrator and after effects
Great 👍
This is Nice, thanks 👍
You will make more content on each topic?
imagine the pain you have to go through having him as your pull request reviewer
Good video.
Awesome video ❤
请问您的视频中的动画是用啥软件制作的？May I ask what software you used to create the animation in your video?
What tools do you use for your animation and video? Thanks :)
Adobe Illustrator and After Effects
SOLID has been way over hyped, and people continue to blindly cite it.
I mean they are vital when you talking about well designed Object Oriented Design, which is good when you want properly abstracted code, it's like yes NoSql DBs are popular but there is use in being able to normalize a SQL table to make queries efficient
@@danielvayalil8453 The only vital one might be Liskov. The others are just rules of thumb - occasionally useful.
you are awesome
informative!
Gold
Who spotted the typo at 2:32?
assertions? never seen those
Just do TDD.
"How to write clean code" : never contract work to anyone in Bangalore.
Haha
hahah
Or hire a good Indian engineer. You pay peanuts, expect peanut butter.
Bad code knows no borders.
@@teeesen agreed. It's a mean stereotype.
These 5min videos get very fast. They don't solve the purpose unless you already know the topic well and you just want to revise.
don't think anyone opened this ~ 5 min video expecting in-depth analysis of 10 complex concepts but that's just me
100%
these ofc arent dogmas
I disagree on the comments, good good does not need any comments, the functions/methods/classes names should speak for itself ...
No matter how well you name your functions etc. it would never tell you _why_ something had to be done. Nothing replaces good comments/code documentation when it comes to this.
Yes, my mashine code speaks for itself.😂
@@ryanstephen6163My functions have no name, but an address to call in memory.
@@ryanstephen6163 exactly!
Saying the *_word_* sequel when you mean the *_acronym_* SQL is confusing and illogical. You don't turn an acronym into a word unless the entire acronym IS a word, or you are simply using the word *_the acronym actually represents._* Throwing that entirely unrelated word in as an unnecessary expansion of the shortened acronym is going in the opposite direction of the entire point of using an acronym in the first place, and it is only confusing. Because nobody can tell which letters comprise the actual shortened term, phrase or title and which letters were just arbitrarily thrown in to make it a word. We pronounce SWAT because all the letters are in the word, but we spell out FBI instead of throwing a few more vowels and consonants in to confuse people. We don't call the FBI "FibBIng cops"
Sequel is a now defunct proprietary DBMS that stopped being used or sold in the mid 1980s. SQL is an acronym for structured query language. Is you say "ess, kyew, ell" I might have a chance at figuring out s stands for struxtured, q stands for query and l stands for language. When you say sequel I might decide that sequel is how you pronounce the acronym SEQL or SQUL and now I'm thinking you're talking about symmetrical energy quotient levels of Standardized Electronic Quartz Lighting because I lost context and have nothing to work with besides the phonetic sound "sequel."
“Everybody in the world is now a programmer. This is the miracle of AI.”
Jensen Huang, 2024
too much of a blunt commercial !!!
Buy a new mic, or improve audio editing skils, ty;)
I thought it was fine.
audio is fine, buy a new ear or improve hearing ❤
@@TanveerAhmed10 sarcasm is for smart ppl
Audio is fine buy a new life
his audio is fine but you probably need to get new speakers or headset