sorry to be so offtopic but does someone know a method to get back into an instagram account? I was dumb forgot the login password. I appreciate any tips you can offer me
I've been mulling over downloading the video and re-editing them so that when he's talking about the code, the video actually shows the code. Novel idea I know, but these videos deserve better editing.
sometimes its not enough to test the software. You also need to test the person. I have a picture of a monkey typing on a machine but not having any clue what its working on.
hahahahaha this comment section is killing me :D I was gonna make some smartass comment too, but too many have gone before me and it made go from frustrated to LOL in 10 seconds, thank you.
@@Rob81k I know a few nice shortcuts on YT but I didn't know that one. ,Thanks for the tip but the point is you shouldn't have to bother with it. At most be able to pause the video. I tried your shortcuts and they don't seem to work on my side.
0:00 Where did the moon come from? 4:56 What is the Purpose of the Comment? / About Fortran 8:47 Schindler List / Right and Wrong reason to do comment 10:02 Comments are a last resort / The proper use of comments 11:02 Comments Lie 13:07 Comments do not make up for bad code / Explain Yourself in code 15:11 Legal and Informative Comments / About Design Patterns book 20:43 Explanation of Intent / Clarification 23:21 Warning of Consequences / TODO Comments 25:59 Amplification / Javadocs in Public APIs 27:35 Bad and Redundant Comments / Mumbling 31:25 Mandated Comments 33:01 Journal Comments / Source code control system 34:16 Noise Comments / Scary Noise / Use explanatory code, not comments 36:20 Position Markers / Closing Brace Comments / Attributions and Bylines 37:43 Commented - Out Code / HTML in comments ICK! 40:05 Non - Local Information 41:45 How many lines should there be in a source file? 46:31 Analysis of the lengths of lines 50:11 Names are Everywhere / Reveal your intent / Rules to write Names 58:44 Disambiguate / Avoid Convenient Mispellings 1:00:41 Number Series / Noise Words / Distinguish Names Meaninfully 1:02:55 How much time should you spend on a Code Review?
"Comment"(s), well, tons of it, C# Project template, or Flutter Project Template. It very useful, 1st time. After that, 1st I do, with new project, is to delete all the comments. But, it is important, for others, 1st timer. Most of the topics, are pointless as the "Comment" thing. In practice, there are no absolute rules, alway, it depends.
The editing is very frustrating. It's as if it was edited with the sound turned off, the camera never addresses the screen while Bob is talking about it, and several slides were never visible on the video. Great lecture but poor video.
Especially when he takes a laser pointer to the screen, but the screen doesn't change from being a close-up of Bob. You would think that would be a pretty good cue to show what he's pointing at.
I doubt if it was the uploader who was editing it. It looks like a ripped livestream with baked transitions. Ineffective transitions, but for running it live by pure contexual clues it seems alright.
Regardless of my opinion of whether something needs to be commented or not, the changing the color of the comment text to Red in the Editor was a gold nugget in this talk.
With his head turned to the side, so that he couldn't see what he's writing. And got smacked through the head every time he overwrites something already written.
These 2 lessons from Uncle Bob are changing my life right now; I finally have a specific way to clean up my code (using is "one thing" principle that was always arbitrary to me before, plus it's fun to refactor it, and reduces lines of code! That said, the editing of this video could be better. Many times it's cut to the presenter while he's specifically referencing something on screen, and then you can't read it well (or at all in several cases where the shot is of him talking while he's behind his tablet, and you can't see anything of what he's doing).
I was just working on an application while listening to this and I had an unexpected crash.... digging into one of the libs I found: "// TODO(regis): Remove temp constructor identifier 'withInvocation'.", such is life.
The LEARNING's. Like the comment if you found it useful. 🙂👍 Part-2 COMMENTS, FORMATTING & NAMES 1. Look at comments as failure. Only write them as last resort. 2. Write bad code, clean and then if you fail, comment it out. Preferably, delete it. 3. Never push comments to production. 4. Much better to write meaningful variable names and function names than comments. 5. If writing TODO comments, either do it or don't check it in production. 6. Amplify those parts of code which people usually ignore. Ex - trim() usage if it is used differently in your code. 7. Do not mumble aka speak to yourself in your comments. If a comment says something, make sure it does what it says. Don't lie. If the code for which the comment is, is in other place, don't write the comment at all if you can't show that piece of code aka show what the comment says. 8. Don't write redundant, useless comments. 9. Do not write commented out code. Ever. 10. Never scroll right. Ideally, limit line length to 150 characters. 11. Variable names should reveal your intent. 12. Length of a variable name should be directly proportional to it's scope. Conversely, function names length and class names is inversely proportional to it's scope. Ex - If variable has a single line scope, single character variable name is enough. 13. Avoid noisewords. Ex - int productData, product. What's the difference, duh? 14. Distinguish names meaningfully. Do not write ambiguous, confusing names.
4:56 Uncle Bob speaks of Fortran as if it were a thing of the past. True that 1950's FORTRAN was quite limited vs. modern computer languages. But Fortran 90 et seq. allow longer names, for example. We still use Fortran for fluid dynamics simulations. Check out MODFLOW, SWAN, or ADCIRC, for example. Fortran is still a great choice for what it was designed to do: number crunching. If you want a web browser or GUI, of course you would program in something else.
@William Hill, I don't know Fortran. Do the Fortran math libraries make dealing with floating point numbers less errror prone than programming languages such as Python or JavaScript?
Yeah, but _why_ code it in something such obscure as Fortran when there's a lot of more modern and well-known alternatives that more people would understand? Are there any features that only Fortran has which are unavailable in other languages or something?
As an exercise I wrote a Fortran interpreter once and used it as a replacement for Microsoft Basic on a Z80 CP/M system. It was a hell of a ride. BASIC has idiosyncrasies, FORTRAN has straitjackets. There’s an old book I remember “FORTRAN, A Structured, Disciplined Style”.
@@dmitripogosian5084 Is Fortran more efficient than other languages then? :q As for understandability, I beg to differ. Give me an inefficient code, and if I can understand it, I can make it efficient. But give me code that I can't understand, and there's no way I could make it efficient. I'm pretty sure Uncle Bob said something similar in one of those lectures, so it's not just me.
1:00:51 A legitimate use case for Product, ProductData, and ProductInfo would be electronic components. Product would be the component itself; ProductData would be the datasheet; ProductInfo would be different packages the component is available in and RoHS status, e.g. the TL072 op amp is available in PDIP and TSOP packages, but its specifications don't change significantly depending on packaging. It is reasonable for these to be maintained separately, especially as PDIP packaging becomes obsolesced.
@32:20 curiously this type of coment reminds me of the Microsoft Documentation - where the variable is echoed into the comment with no light as to its purpose.
yeah, usually it's the Remarks section where things are properly explained. (these days though, they've open-sourced their documentation to some degree I think at least in some cases)
The best way I’ve found to make the “compareTo” and similar assert patterns readable is to have a little function that parses infix expressions (like what was in the comments), computes the expression values and passes them to assert. Such a function factors out into nice small functions and isn’t a burden on test suites. It gets rid of those ugly comments. And if the language got an eval, then the whole thing can simplify to rewriting the expressions, eval-ing them, and passing each result to assert. It’s not uncommon that the little parser is smaller than all the comments it replaced. Also, it is almost guaranteed to catch bugs in the test suite.
48:50 Screens getting bigger wouldnt really have much to do with the *average* length of lines but instead the max length. I think with screens getting bigger that the maximum allowed line length should be readjusted. Right now it seems to be around 80 but fitting twice that wouldnt be too difficult either (not saying it should be to t hat extreme)
I don't think so. Because even with classical paper documents of any nature (letter, book, you name it) you prefer reading short lines than lines that force you to widely pan with your eyes or rotate your head). We prefer reading top to bottom with the least horizontal pan possible. That's much more effective not to say efficient.
Uncle bob is the Gordon Ramsay of coding, he is a legend but you don't want him to review your coding because you know you will be in some serious shiz afterwards lol.
I disagree, but for exactly the reason you say this. I want my code ripped to shreds. I know I'm a good developer, but I need someone better than me to show me where I can improve.
Surely that person is Linus Torvalds? For example who said this: "Guys, this is not a dick-sucking contest." Linus/Gordan? "Finally your head is coming out your arsehole" Linus/Gordan? "I'll take real toilet paper over [ redacted ] any day, because at least that way I won't have splinters and ink up my arse" Linus/Gordan? It's not easy to tell without google.
30:28 I once was in a Company, where we had this convention. We wrote down every information, you could get from the line below, an formulated it as a sentence When I asked, why we do this. "You get all the informations in a way, even the project manager could understand it..." ...I've been called a fool to question this instruction 🥳 When I said that comments can be corrupted, I was asked whether I had read our coding conventions at all and that it was clearly defined there, that comments should always be revised as well.
Regarding the comments for all the fields in the "From Tomcat" code at 30:12 or the code at 34:40. It might be if they're using Lombok to generate Getters, but want to document the getters with Javadoc for API users. Lombok will take the javadoc comments on the fields and put them on the Getters (and Setters if selected).
It’s bad form to have documentation-producing comments that are indistinguishable from those that are “for your eyes only”. Always use the doc prefix is my mantra, and disable passing along of un-prefixed comments, even if they are on the fields.
Amazing, priceless lecture! Thank all the people who made this possible! Thanks a lot! Firstly, I was a little bit unsatisfied because of some camera issues, but later I realized that they are so insignificant things, that there is no reason to think about them. Genius lecturer! Super professional director and his staff! Thank you so much!
I'm pretty happy that I learned with all these old IDEs and the wild west of source control and deployment but did not start working with development until a couple of years back. Standing on the shoulders of giants. From linking source files and compiling manually to setting up template projects and deploying them to another part of the world within minutes. Really enjoying the lectures. Thanks.
Design Patterns: Elements of Reusable Object-Oriented Software (1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch.
I'm watching this after watching Davepl do his code review of Windows Task Manger (he was the original author). One of his comments in the original code was : // Yes, I could use virtual destructors, but I could also poke // myself in the eye with a sharp stick. Either way, you wouldn't // be able to see what's going on.
Bob is not a god. He is skillful, but doesn't mean he knows it all. As a junior IT I could teach a few things to seniors. No wonder seniors are much more knowledgeable than I am. That said, there is always a dark spot that could be filled by apparently less skilled people. That's why you should always listen to apparently less skilled people too. They might come with interesting point of view.
For the code at 22:29, the more expressive way to write that is, assertThat(a).isEqualTo(a); assertThat(a).isNotEqualTo(b); assertThat(ab).isEqualTo(ab); assertThat(a).isLessThan(b); assertThat(aa).isLessThan(ab); assertThat(ba).isLessThan(bb); assertThat(b).isGreaterThan(a); assertThat(ab).isGreaterThan(aa); assertThat(bb).isGreaterThan(ba); HTH
I need to like make all of my staff watch this series... I'm glad that I've managed to learn a lot of "polite syntax" without anyone having to show me.
Anyone complaining about the video editors should take a look at the book "Clean code", everything (code, keywords) is there. You could boost your learning speed by watching the video together with that book.
NOTES -- (Comments) INTRODUCTION - Purpose of comments: To explain code that can't be explained by itself - Comments aren't pure good. They can lie, be misleading, and/or degrade overtime - When properly used, it should compensate our failure to express ourselves in code. Therefore, every use of a comment represents a failure. - Don't comment first, try everything else then comment as a last resort (An unfortunate neccessity). Don't be a boy who cried wolf, comment when needed and where it matters or people will end up ignoring it - Read the Design Patterns book. It helps to know established patterns/ideas to communicate with others GOOD/ACCEPTABLE COMMENTS - Consider solving with a renamed function first - Informative comments: Simplifies the takeaway for a portion of code (eg. Return value of function of formatting of regex) - Explanation of Intent/Clarification comments: What is this bit of code doing (eg. convoluted assertions) - Warning of Consequence: Warnings programmers should note (eg. testing function may take a long time to run, certain classes aren't thread safe) - TODO Comments: Should be done or deleted before being commited - Amplification comments: Emphasize an important part of the code that may have otherwise been overlooked - Javadocs works for public APIs BAD COMMENTS - Don't talk about code somewhere else/non-local information - Mandated comments - Journal comments (Thank goodness for git) - Noisy comments like "// object constructor" - Closing brace comments (Never seen this personally) - Attribution and bylines (Git will handle that) - Commented out code (Git will also handle that) RULE OF THUMBS - Strive for file sizes of 50 -
Best advice was to highlight comments in "red". I did that immediately and "there they are these crazy little comments".... It helps so much! (I think I'm going to stick with that)
Maybe Uncle Bob could write a book called "Clean video editing" in which the central theme is that when you say "look at this slide", the video shows the bloody slide.
Bit late to realize, it's actually walk through of his book clean code. Nice to have it handy on your side since the editing is missing the point. 😁 All the examples are from the book.
I feel like the line length analysis could be explained by just the syntax of the language. Once the lines got to the long half they became jumbled messes, likely because of lines with lots of parameters/long comments/the types of lines that wouldn't have to follow a specific convention, like an if block or a switch statement, or the similar length of a line calling a method or declaring a variable. I feel like it would be weird to say that you should follow a specific line length curve as a guideline, as opposed to just trying to make your code readable, however long those lines end up.
At the minute 23m of the video : there are comments about the "meaning" of the compareTo() function in the assertions... and Uncle BOB tells us, it's hard for him to get rid of those comments and I don't see why. In C++, I usually define three local macros : equalTo(a, b), greaterThan(a, b) and lessThan(a, b) and use them in the assertions. I did that a lot of time, and in many places locally, to help me get rid of those ugly testing functions that returns 3 types of results... ^_^~
Genuine Question: On the assertTrue calls, why not put the parameters that you would be comparing in an array, then just write a function that receives assertions to execute and what it does is loop through them using the parameters placed on each element? I bet you'd end up with good looking elements of array that would be easy to read as your comments and execution would be simple since it's just a for loop
Bob: "Now look at this line, do you see it? What's wrong with it?" Editor: Well would you look at this wide shot of this glorious auditorium, composited with the back of everyone's head and a close-up vista of Bob drinking a glass of water.
Funny, Qt's date formatting code is also not thread safe for the same reason that Java's is, and I recently spent the whole evening debugging the rare multithreaded crash caused by it.
The problem with these names is that they don't convey their meaning. Why is that "data" and "info" not inside the Product class? And what do they contain anyway? Imagine you wrote those ProductInfo and ProductData classes, and someone asks you: "hey, what's the difference between those?" What would your answer be? Then refactor those classes, so that you won't get the same question again. It must be clear for the reader what they are. "Info" and "Data" don't tell you what they contain, what their purpose is. Therefore it's noise.
@@GerbenWijnja Ah, I see! Thank you! I thought there was something wrong with naming variables based on these classes names. I can agree that these class names doesn't tell anything. Cheers!
Only thing I can think of is it throws a null pointer exception when a is null, while assertNotNull() doesn't throw a null pointer exception but an assertion error. No idea why you would want the null pointer exception. I did some testing, a.compareTo(b) would also result in a null pointer exception, but then it isn't clear whether a or b is null by just looking at the top frame in the stack trace, they are the same for when either a or b is null. When you add a.compareTo(a) it's clear a is null.
*compareTo* functions return *-1* for "less than", *0* for "equal", and *1* for "greater than". so this is asserting that the implementation of the *compareTo* function for whatever *a* is should return *0* (equal) when comparing *a* to itself.
It is very annoying to not see the slides that the uncle bob talking about. You frequently display uncle bob or stage intstead of the slide which is more important for us. Uncle bob talking something about in the slides but we cant see it.
Once picked up a SQL job (so horrific to start with) where the original developer wrote as a warning in comments “this cute abomination is because of…” I felt his pain but never forgave him!
Good code is code that your read one time from begin to end and then you know what it does and why. I agree that boolean parameters in a function always suspicious but only IF they in most cases called with a constant. For example a function which replaces some text by another in a string might look like replace(String text,String searchText,String replaceWithText ,boolean replaceAllInstances) might be in most cases with with either a constant TRUE or constant FALSE for replaceAllInstances) - and when it might make sense to have to different Replace function - one named ReplaceFirstInstance and the other ReplaceAllInstances But there also cases there a boolean parameter is called normally with a variable and then it is normally better to have that boolean parameter because otherwise you would need always an IF-THEN-ELSE in the calling code to call the "right" function
in this case, I would make `replace` a private method called by both `replaceFirstInstance` and `replaceAllInstances`. Both functions would call the generic `replace` using the corresponding boolean flag, but the mess would be contained to the proxy methods. After removing all references to `replace` from the code base, and If then I could refactor the `replace` method, I'd convert the boolean expression to an enum (FIRST_INSTANCE, ALL_INSTANCES) that would explicitly tell which operation is being performed. Some languages like Swift do away with this problem by making the name or the parameter required, so it turns into something like this: `replace(..., allInstances: true)`
I recently lean more on Kevlin HEnneys idea of naming exception derived classes. Instead of NullPointerException/NullReferenceException I'd rather have NullDereferenced or something like that.
this show is like a self-help book, it is logical, it can make your life better but then you have to come back to reality and maintain legacy code and can't refactor 3000 files project :)) still fun though and could be helpful for some small project that starts from scratch.
Yepp. The most frustrating thing with working on legacy code is having team members who won't approve your refactoring PRs... as I think bob mentioned in the first video, so many devs have gotten used to reading shitty code they start writing and even enforcing those same shitty styles on everyone else -_-
![Noob To Max With DRAGON REWORK In Blox Fruits [FULL MOVIE]](http://i.ytimg.com/vi/LnBMOinoOvA/mqdefault.jpg)
I love that no matter what background we're coming from, no matter part of the world we are from, we are united in our hatred for the video editor.
Uncle bob: *changes slide* "This is the same function"
Me waiting for the new slide to appear: 🤡
I wish I could like this comment twice.
sorry to be so offtopic but does someone know a method to get back into an instagram account?
I was dumb forgot the login password. I appreciate any tips you can offer me
@Brentley Matias instablaster :)
I've been mulling over downloading the video and re-editing them so that when he's talking about the code, the video actually shows the code. Novel idea I know, but these videos deserve better editing.
Uncle Bob: look at this piece of code
Cameraman: ah I think it's the signal for a zoom shot of uncle bob's face
Thats a couple of wtf for the cameraman
Ye it's funny the editting is like "oh coders don't need to see the code they've got it" uh ah I mean maybe but can we still see it? :D
😂🤣😂
Lol
sometimes its not enough to test the software. You also need to test the person. I have a picture of a monkey typing on a machine but not having any clue what its working on.
Uncle Bob: Look at this
Editor: haha you wish
I'm laughting so hard. It is frustrating.
TOTAL waste of time.
I reported as spam.
Bob always does it, makes him seem cleverer than he actually is, so you believe his clean code stuff without thinking or challenging it
@@ajtan2837 u dumb
@@Alkis05 I don't understand the joke...
18:00 - "Do you see it?" - "Yes, we see you seeing it"
hahahahah lol
hahahahaha this comment section is killing me :D I was gonna make some smartass comment too, but too many have gone before me and it made go from frustrated to LOL in 10 seconds, thank you.
40:51 "They wrote a whole little essay" - the slide is shown for six (6) frames. Jesus christ.
Actually lold
You can seek frames using the comma and period keys. Edit: probably how you counted them :)
@@Rob81k I know a few nice shortcuts on YT but I didn't know that one. ,Thanks for the tip but the point is you shouldn't have to bother with it. At most be able to pause the video. I tried your shortcuts and they don't seem to work on my side.
thanks, i hate that mobile doesn't have frame seeking
That comment got more sidetracked than Trump at a campaign rally
0:00 Where did the moon come from?
4:56 What is the Purpose of the Comment? / About Fortran
8:47 Schindler List / Right and Wrong reason to do comment
10:02 Comments are a last resort / The proper use of comments
11:02 Comments Lie
13:07 Comments do not make up for bad code / Explain Yourself in code
15:11 Legal and Informative Comments / About Design Patterns book
20:43 Explanation of Intent / Clarification
23:21 Warning of Consequences / TODO Comments
25:59 Amplification / Javadocs in Public APIs
27:35 Bad and Redundant Comments / Mumbling
31:25 Mandated Comments
33:01 Journal Comments / Source code control system
34:16 Noise Comments / Scary Noise / Use explanatory code, not comments
36:20 Position Markers / Closing Brace Comments / Attributions and Bylines
37:43 Commented - Out Code / HTML in comments ICK!
40:05 Non - Local Information
41:45 How many lines should there be in a source file?
46:31 Analysis of the lengths of lines
50:11 Names are Everywhere / Reveal your intent / Rules to write Names
58:44 Disambiguate / Avoid Convenient Mispellings
1:00:41 Number Series / Noise Words / Distinguish Names Meaninfully
1:02:55 How much time should you spend on a Code Review?
Where can we find the PPT for reference ?
"Comment"(s), well, tons of it, C# Project template, or Flutter Project Template.
It very useful, 1st time.
After that, 1st I do, with new project, is to delete all the comments.
But, it is important, for others, 1st timer.
Most of the topics, are pointless as the "Comment" thing.
In practice, there are no absolute rules, alway, it depends.
Please put this comment in the video description so that RUclips would split the video into sections that are easy to navigate.
Please fire the person who edited the video.
@@detach8 Hopefully that is not the guy who posted the video... :)
The editing is very frustrating. It's as if it was edited with the sound turned off, the camera never addresses the screen while Bob is talking about it, and several slides were never visible on the video. Great lecture but poor video.
Especially when he takes a laser pointer to the screen, but the screen doesn't change from being a close-up of Bob. You would think that would be a pretty good cue to show what he's pointing at.
I doubt if it was the uploader who was editing it. It looks like a ripped livestream with baked transitions. Ineffective transitions, but for running it live by pure contexual clues it seems alright.
Video editor programs in DreamWeaver
@John Smith nice xenophobia bro
close your eyes and enjoy uncle Bob then
>"clean code - lesson 2"
>starts talking about the origin on the moon
>camera man points at an empty sofa
Me: wtf am I watching
lmfao
😂
It should be called "part 2" instead of "lesson 2". It's a single talk split into multiple videos, not separate lessons.
At least it didn't point at the actual moon...
Lmao, i can accept the moon talk, but empty-sofa shot xDD
Regardless of my opinion of whether something needs to be commented or not, the changing the color of the comment text to Red in the Editor was a gold nugget in this talk.
This is absolutely a gift.thank you Bob and the team behind it
15:58 Design Patterns ( Elements of Reusable Object-Oriented Software ) ...book suggestion, cheers!
Thanks man! I’ve been searching for a comment about the book he mentioned
Show the f***ing screen when the presenter is refering to it ffs. Great talk anyhow :)
The camera man is not a programmer apparently.
@Sepp Huber I originally had this vid thumbs-up. I changed it to thumbs-down after watching half of it and shouting what you just commented.
@@michaeldeng1981 maybe it is a program then :P
@@stefanheiler2329 then maybe the programmer was supposed to be the camera man
Coding videos always have the best comment sections. This is my tribe for sure.
I love the lecture, but I want to make the person who edited the video write on an old chalk blackboard “I will not obscure information” about 5000x
This reaction made me laugh, which I needed. Thank you for your reaction and I'm really curious what your MBTI type is
With his head turned to the side, so that he couldn't see what he's writing. And got smacked through the head every time he overwrites something already written.
Insightful but very hard to follow because of the camera not knowing what to focus on...
These 2 lessons from Uncle Bob are changing my life right now; I finally have a specific way to clean up my code (using is "one thing" principle that was always arbitrary to me before, plus it's fun to refactor it, and reduces lines of code!
That said, the editing of this video could be better. Many times it's cut to the presenter while he's specifically referencing something on screen, and then you can't read it well (or at all in several cases where the shot is of him talking while he's behind his tablet, and you can't see anything of what he's doing).
Jess Hines I’d recommend you get his books too :)
I was just working on an application while listening to this and I had an unexpected crash.... digging into one of the libs I found: "// TODO(regis): Remove temp constructor identifier 'withInvocation'.", such is life.
Closing brace comments get added in automatically with things like flutter dev. Loving these videos, thanks!
as long as the IDE keeps them updated if you change something so they cannot be wrong, it's alright, though you should be able to disable them too
The LEARNING's. Like the comment if you found it useful. 🙂👍
Part-2 COMMENTS, FORMATTING & NAMES
1. Look at comments as failure. Only write them as last resort.
2. Write bad code, clean and then if you fail, comment it out. Preferably, delete it.
3. Never push comments to production.
4. Much better to write meaningful variable names and function names than comments.
5. If writing TODO comments, either do it or don't check it in production.
6. Amplify those parts of code which people usually ignore. Ex - trim() usage if it is used differently in your code.
7. Do not mumble aka speak to yourself in your comments. If a comment says something, make sure it does what it says. Don't lie. If the code for which the comment is, is in other place, don't write the comment at all if you can't show that piece of code aka show what the comment says.
8. Don't write redundant, useless comments.
9. Do not write commented out code. Ever.
10. Never scroll right. Ideally, limit line length to 150 characters.
11. Variable names should reveal your intent. 12. Length of a variable name should be directly proportional to it's scope. Conversely, function names length and class names is inversely proportional to it's scope. Ex - If variable has a single line scope, single character variable name is enough.
13. Avoid noisewords. Ex - int productData, product. What's the difference, duh?
14. Distinguish names meaningfully. Do not write ambiguous, confusing names.
You forget one:
0. The origin of the Moon is messed up ;)
Am gonna copy paste this to my team 🦾🦾
@@budgeter4807 Glad it'd be useful! Good luck 😄
4:56 Uncle Bob speaks of Fortran as if it were a thing of the past. True that 1950's FORTRAN was quite limited vs. modern computer languages. But Fortran 90 et seq. allow longer names, for example. We still use Fortran for fluid dynamics simulations. Check out MODFLOW, SWAN, or ADCIRC, for example. Fortran is still a great choice for what it was designed to do: number crunching. If you want a web browser or GUI, of course you would program in something else.
@William Hill, I don't know Fortran. Do the Fortran math libraries make dealing with floating point numbers less errror prone than programming languages such as Python or JavaScript?
Yeah, but _why_ code it in something such obscure as Fortran when there's a lot of more modern and well-known alternatives that more people would understand? Are there any features that only Fortran has which are unavailable in other languages or something?
As an exercise I wrote a Fortran interpreter once and used it as a replacement for Microsoft Basic on a Z80 CP/M system. It was a hell of a ride. BASIC has idiosyncrasies, FORTRAN has straitjackets. There’s an old book I remember “FORTRAN, A Structured, Disciplined Style”.
@@bonbonpony Understanding is not the prime issue for scientific code. Maximum efficiency is
@@dmitripogosian5084 Is Fortran more efficient than other languages then? :q
As for understandability, I beg to differ. Give me an inefficient code, and if I can understand it, I can make it efficient. But give me code that I can't understand, and there's no way I could make it efficient. I'm pretty sure Uncle Bob said something similar in one of those lectures, so it's not just me.
I have got a big list of slangs for the editor
Imagine how would you feel if you are a programmer and an editor and watching all this.. omg I'm dying 😩
1:00:51 A legitimate use case for Product, ProductData, and ProductInfo would be electronic components. Product would be the component itself; ProductData would be the datasheet; ProductInfo would be different packages the component is available in and RoHS status, e.g. the TL072 op amp is available in PDIP and TSOP packages, but its specifications don't change significantly depending on packaging. It is reasonable for these to be maintained separately, especially as PDIP packaging becomes obsolesced.
Why not ProductDataSheet and ProductPackage?
@32:20 curiously this type of coment reminds me of the Microsoft Documentation - where the variable is echoed into the comment with no light as to its purpose.
yeah, usually it's the Remarks section where things are properly explained. (these days though, they've open-sourced their documentation to some degree I think at least in some cases)
The best way I’ve found to make the “compareTo” and similar assert patterns readable is to have a little function that parses infix expressions (like what was in the comments), computes the expression values and passes them to assert. Such a function factors out into nice small functions and isn’t a burden on test suites. It gets rid of those ugly comments. And if the language got an eval, then the whole thing can simplify to rewriting the expressions, eval-ing them, and passing each result to assert. It’s not uncommon that the little parser is smaller than all the comments it replaced. Also, it is almost guaranteed to catch bugs in the test suite.
48:50 Screens getting bigger wouldnt really have much to do with the *average* length of lines but instead the max length. I think with screens getting bigger that the maximum allowed line length should be readjusted. Right now it seems to be around 80 but fitting twice that wouldnt be too difficult either (not saying it should be to t hat extreme)
I don't think so. Because even with classical paper documents of any nature (letter, book, you name it) you prefer reading short lines than lines that force you to widely pan with your eyes or rotate your head). We prefer reading top to bottom with the least horizontal pan possible. That's much more effective not to say efficient.
Tell that to eclipse devs to change default comment line length
That feeling when you think that word processors solved that problem decades ago with line wrap… :q
Shorter lines allow for multiple files open at once, side by side, but 80 is still too short for Java, where the names tend to be humongous.
Uncle bob is the Gordon Ramsay of coding, he is a legend but you don't want him to review your coding because you know you will be in some serious shiz afterwards lol.
I disagree, but for exactly the reason you say this. I want my code ripped to shreds. I know I'm a good developer, but I need someone better than me to show me where I can improve.
Surely that person is Linus Torvalds?
For example who said this:
"Guys, this is not a dick-sucking contest." Linus/Gordan?
"Finally your head is coming out your arsehole" Linus/Gordan?
"I'll take real toilet paper over [ redacted ] any day, because at least that way I won't have splinters and ink up my arse" Linus/Gordan?
It's not easy to tell without google.
@@not_ever I just googled it and realized, that I didn't really know who Linus Torvalds is.
//He reminds me of Skipper from Penguins of Madagascar
Amazing talk, but the editing is a pure failure.
What is the point of the lights that are pointing right into the projection area???
Love these videos... all of them
30:28 I once was in a Company, where we had this convention. We wrote down every information, you could get from the line below, an formulated it as a sentence
When I asked, why we do this. "You get all the informations in a way, even the project manager could understand it..."
...I've been called a fool to question this instruction 🥳
When I said that comments can be corrupted, I was asked whether I had read our coding conventions at all and that it was clearly defined there, that comments should always be revised as well.
Really crap editing. Way too often you spend time watching Bob describing code that he and the audience can see but viewers can't.
It could be intentional, so you attend or buy a book.
@@martinmendez695 xddd
When was this session (s) actually delivered??
Regarding the comments for all the fields in the "From Tomcat" code at 30:12 or the code at 34:40. It might be if they're using Lombok to generate Getters, but want to document the getters with Javadoc for API users. Lombok will take the javadoc comments on the fields and put them on the Getters (and Setters if selected).
It’s bad form to have documentation-producing comments that are indistinguishable from those that are “for your eyes only”. Always use the doc prefix is my mantra, and disable passing along of un-prefixed comments, even if they are on the fields.
Amazing, priceless lecture! Thank all the people who made this possible! Thanks a lot! Firstly, I was a little bit unsatisfied because of some camera issues, but later I realized that they are so insignificant things, that there is no reason to think about them. Genius lecturer! Super professional director and his staff! Thank you so much!
33:27 my contra argument is: what is faster? look on comment header, or search version tree (GIT/clearcase/whatever)?
What do you think about Python docstrings? Are they a good practice?
I'm pretty happy that I learned with all these old IDEs and the wild west of source control and deployment but did not start working with development until a couple of years back. Standing on the shoulders of giants. From linking source files and compiling manually to setting up template projects and deploying them to another part of the world within minutes. Really enjoying the lectures. Thanks.
Which Design Pattern book was he talking about? There are a few to choose from...
"There can be only one." but they are a gang of four.
Design Patterns: Elements of Reusable Object-Oriented Software (1994) by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch.
By any chance anyone know if it's possible to get access to the slides presented? I would love to follow it while I watch the video
57:33 Bob: that's the same code. Editor: nope
Who tf edited these videos? He is talking about the code and the camera is pointed at his face.
Lean closer and I'll whisper this great secret into your ear: SOMEONE WHO DIDN'T CARE!
I think there's universality to the notion of a pair (or more) of people working on something being vastly superior to an individual.
I'm watching this after watching Davepl do his code review of Windows Task Manger (he was the original author). One of his comments in the original code was :
// Yes, I could use virtual destructors, but I could also poke
// myself in the eye with a sharp stick. Either way, you wouldn't
// be able to see what's going on.
The angle brackets in comments are used as within source code for fast editor searching. Surprised Bob didn't know this one.
Bob is not a god. He is skillful, but doesn't mean he knows it all. As a junior IT I could teach a few things to seniors. No wonder seniors are much more knowledgeable than I am. That said, there is always a dark spot that could be filled by apparently less skilled people. That's why you should always listen to apparently less skilled people too. They might come with interesting point of view.
I didn't know that, but why angle brackets? wouldn't it be better as a prefixing # symbol or something similar? lot easier to type?
@@Ashalmawia because someone wrote an add-on that works that way ...
This is absolutely a gift. Thank you Bob and the team behind it!
At 4:57
My ears: "A complete change of topic, lets talk about comet."
My brain: "A comet? That's still on the same topic."
Nope. Comets and moons are in fact wildly different objects.
Does anyone know per any chance what's the video that's been linked to at 41:35? It doesn't seem to exist anymore on Vimeo.
@44:00 file size can be boosted up by including automatically generated code files - which are usually large.
i also wonder if it includes starting whitespace (I presume so), and especially trailing whitespace
I thought he said "Let's talk about comets"
I heard him saying that more than a couple times just after being talking about the moon, so it was a logical connection...
and as a developer, I'm worried why I didn't know the purpose of comets xD
Learning so much! Thank you infinitely for uploading this series
For the code at 22:29, the more expressive way to write that is,
assertThat(a).isEqualTo(a);
assertThat(a).isNotEqualTo(b);
assertThat(ab).isEqualTo(ab);
assertThat(a).isLessThan(b);
assertThat(aa).isLessThan(ab);
assertThat(ba).isLessThan(bb);
assertThat(b).isGreaterThan(a);
assertThat(ab).isGreaterThan(aa);
assertThat(bb).isGreaterThan(ba);
HTH
I still think the operators are more readable, but at least this gives better error messages! :)
57:34 - 58:20: When my urge to slap the video mixer or editor out of their chair with a rolled-up newspaper peaked.
Love the talk. Super fun to discuss. He is wrong about line length though. IDEs have soft-wrap and you should be using it.
I need to like make all of my staff watch this series... I'm glad that I've managed to learn a lot of "polite syntax" without anyone having to show me.
I feel like he keeps switching between impressions of Lewis Black, Louis Anderson, and Patton Oswald, and I love it.
yeah definitely get lewis black vibes watching him
Anyone complaining about the video editors should take a look at the book "Clean code", everything (code, keywords) is there. You could boost your learning speed by watching the video together with that book.
NOTES -- (Comments)
INTRODUCTION
- Purpose of comments: To explain code that can't be explained by itself
- Comments aren't pure good. They can lie, be misleading, and/or degrade overtime
- When properly used, it should compensate our failure to express ourselves in code. Therefore, every use of a comment represents a failure.
- Don't comment first, try everything else then comment as a last resort (An unfortunate neccessity). Don't be a boy who cried wolf, comment when needed and where it matters or people will end up ignoring it
- Read the Design Patterns book. It helps to know established patterns/ideas to communicate with others
GOOD/ACCEPTABLE COMMENTS
- Consider solving with a renamed function first
- Informative comments: Simplifies the takeaway for a portion of code (eg. Return value of function of formatting of regex)
- Explanation of Intent/Clarification comments: What is this bit of code doing (eg. convoluted assertions)
- Warning of Consequence: Warnings programmers should note (eg. testing function may take a long time to run, certain classes aren't thread safe)
- TODO Comments: Should be done or deleted before being commited
- Amplification comments: Emphasize an important part of the code that may have otherwise been overlooked
- Javadocs works for public APIs
BAD COMMENTS
- Don't talk about code somewhere else/non-local information
- Mandated comments
- Journal comments (Thank goodness for git)
- Noisy comments like "// object constructor"
- Closing brace comments (Never seen this personally)
- Attribution and bylines (Git will handle that)
- Commented out code (Git will also handle that)
RULE OF THUMBS
- Strive for file sizes of 50 -
Best advice was to highlight comments in "red". I did that immediately and "there they are these crazy little comments"....
It helps so much! (I think I'm going to stick with that)
the camera director is not listing what Uncle Bob says :(
Which design patterns book is uncle talking about?
Design Patterns ( Elements of Reusable Object-Oriented Software )
Maybe Uncle Bob could write a book called "Clean video editing" in which the central theme is that when you say "look at this slide", the video shows the bloody slide.
Bit late to realize, it's actually walk through of his book clean code.
Nice to have it handy on your side since the editing is missing the point. 😁
All the examples are from the book.
So this is basically the book, except in "for the illiterate" version ;)
Where we can have these slides?
I feel like the line length analysis could be explained by just the syntax of the language. Once the lines got to the long half they became jumbled messes, likely because of lines with lots of parameters/long comments/the types of lines that wouldn't have to follow a specific convention, like an if block or a switch statement, or the similar length of a line calling a method or declaring a variable. I feel like it would be weird to say that you should follow a specific line length curve as a guideline, as opposed to just trying to make your code readable, however long those lines end up.
plot twist: Tom actually wrote the line /* Added by Rick */
At the minute 23m of the video : there are comments about the "meaning" of the compareTo() function in the assertions... and Uncle BOB tells us, it's hard for him to get rid of those comments and I don't see why.
In C++, I usually define three local macros : equalTo(a, b), greaterThan(a, b) and lessThan(a, b) and use them in the assertions.
I did that a lot of time, and in many places locally, to help me get rid of those ugly testing functions that returns 3 types of results... ^_^~
Genuine Question:
On the assertTrue calls, why not put the parameters that you would be comparing in an array, then just write a function that receives assertions to execute and what it does is loop through them using the parameters placed on each element? I bet you'd end up with good looking elements of array that would be easy to read as your comments and execution would be simple since it's just a for loop
Which Design Pattern book is being mentioned here?
This one en.wikipedia.org/wiki/Design_Patterns
Design Patterns ( Elements of Reusable Object-Oriented Software )
Who's the author the Design Patterns book? I'm seeing multiple books titled the same.
Did you find it??.. I can't seem to find the moment where he mentioned that book!! Ha. .... the search continues.
Design Patterns ( Elements of Reusable Object-Oriented Software )
Perhaps create a string for the regex, that is named instead of a comment?
Agreed. That’s the technique I use.
Can someone provide the link of the design patterns book?
Search for Design Patterns, Elements of Reusable Object Oriented Software, that's the title of the book.
What design patterns book is he talking about? Thanks.
Design Patterns ( Elements of Reusable Object-Oriented Software )
@@alamohamed1441 Hey. 3 years later. Finally a response. Thanks.
Are there any of these design pattern books that are in typescript?
Why did y say ts instead of js?
Bob: "Now look at this line, do you see it? What's wrong with it?"
Editor: Well would you look at this wide shot of this glorious auditorium, composited with the back of everyone's head and a close-up vista of Bob drinking a glass of water.
Funny, Qt's date formatting code is also not thread safe for the same reason that Java's is, and I recently spent the whole evening debugging the rare multithreaded crash caused by it.
Who is the author of the design patter book uncle bob is talking about?
The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The
But is the water system working again?
57:40 - One important part of clean code it that your have to actually be able to SEE the code. Otherwise, good code! I think...
So what's noisy about naming variable of type Product product, ProductInfo productInfo or ProductData productData? How should we named them?
The problem with these names is that they don't convey their meaning. Why is that "data" and "info" not inside the Product class? And what do they contain anyway? Imagine you wrote those ProductInfo and ProductData classes, and someone asks you: "hey, what's the difference between those?" What would your answer be? Then refactor those classes, so that you won't get the same question again. It must be clear for the reader what they are. "Info" and "Data" don't tell you what they contain, what their purpose is. Therefore it's noise.
@@GerbenWijnja Ah, I see! Thank you!
I thought there was something wrong with naming variables based on these classes names. I can agree that these class names doesn't tell anything. Cheers!
I'm still trying to understand the purpose of the line _assertTrue(a.compareTo(a) == 0)_ any ideas?
Only thing I can think of is it throws a null pointer exception when a is null, while assertNotNull() doesn't throw a null pointer exception but an assertion error. No idea why you would want the null pointer exception.
I did some testing, a.compareTo(b) would also result in a null pointer exception, but then it isn't clear whether a or b is null by just looking at the top frame in the stack trace, they are the same for when either a or b is null. When you add a.compareTo(a) it's clear a is null.
*compareTo* functions return *-1* for "less than", *0* for "equal", and *1* for "greater than". so this is asserting that the implementation of the *compareTo* function for whatever *a* is should return *0* (equal) when comparing *a* to itself.
Whoever edited this: when he says "look at this" - show the board, not the person!
Great video, great speaker...missed have the slides --> cameraperson ;)
why was the author talking about moon at the start ?
It is very annoying to not see the slides that the uncle bob talking about. You frequently display uncle bob or stage intstead of the slide which is more important for us. Uncle bob talking something about in the slides but we cant see it.
camera man got so motivated by uncle bob he started thinking
"screw this, im trying to learn how to code"
Unfortunate necessity is very different than failure, Uncle Bob! - regarding the use of comments
Once picked up a SQL job (so horrific to start with) where the original developer wrote as a warning in comments “this cute abomination is because of…” I felt his pain but never forgave him!
Exception *is* a noise word. I throw it or catch it. It is obviously an exception. There is absolutely no need to say it is.
we want a certificate of completion to this series
Good code is code that your read one time from begin to end and then you know what it does and why.
I agree that boolean parameters in a function always suspicious but only IF they in most cases called with a constant.
For example a function which replaces some text by another in a string might look like
replace(String text,String searchText,String replaceWithText ,boolean replaceAllInstances) might be in most cases with with either a constant TRUE or constant FALSE for replaceAllInstances) - and when it might make sense to have to different Replace function - one named ReplaceFirstInstance and the other ReplaceAllInstances
But there also cases there a boolean parameter is called normally with a variable and then it is normally better to have that boolean parameter because otherwise you would need always an IF-THEN-ELSE in the calling code to call the "right" function
in this case, I would make `replace` a private method called by both `replaceFirstInstance` and `replaceAllInstances`. Both functions would call the generic `replace` using the corresponding boolean flag, but the mess would be contained to the proxy methods. After removing all references to `replace` from the code base, and If then I could refactor the `replace` method, I'd convert the boolean expression to an enum (FIRST_INSTANCE, ALL_INSTANCES) that would explicitly tell which operation is being performed.
Some languages like Swift do away with this problem by making the name or the parameter required, so it turns into something like this: `replace(..., allInstances: true)`
I recently lean more on Kevlin HEnneys idea of naming exception derived classes. Instead of NullPointerException/NullReferenceException I'd rather have NullDereferenced or something like that.
Damn it, I wanted to talk about pairing!!!
The current software model is over. The future is a new paradigm: Subject Oriented Programming in the Universal Software Model!!
this show is like a self-help book, it is logical, it can make your life better but then you have to come back to reality and maintain legacy code and can't refactor 3000 files project :)) still fun though and could be helpful for some small project that starts from scratch.
Yepp. The most frustrating thing with working on legacy code is having team members who won't approve your refactoring PRs... as I think bob mentioned in the first video, so many devs have gotten used to reading shitty code they start writing and even enforcing those same shitty styles on everyone else -_-
Regular expression comment does not lie. It does not say that the regexp matches ONLY that time stamp format.
1:00:15 looks like there is a man in a large bunny costume in the bottom left of the audience
"He doesn't want to talk about pairing either!" lol
I need to send my boss to an uncle bob lecture
I’m looking forward to the payoff from the astronomy thing in the last part of this
34:22 My compsci java textbook has these as a manadory requirement. If each method is not commented we can loose up to 10% of our grade
That textbook promotes Cargo Cult Programming. Awful :(