Clean Code - Uncle Bob / Lesson 2
HTML-код
- Опубликовано: 26 июл 2024
- ↓↓ ENGLISH DESCRIPTION ↓↓
"Coding Better World Together" is a set of master lessons from the famous Uncle Bob (Robert Cecil Martin), where he gives us a broad vision of the importance and future of Software in today's society.
In this second lesson, Uncle Bob teaches us the purpose of comments in the code, breaking the paradigm that commenting is something "I have to do" for the simple fact that we mistakenly consider that commenting is a good practice. For Uncle Bob, writing a comment is a sign of failure, since a good code must be able explain by itself: Fewer Comments = Better Code.
↓↓ DESCRIPCION EN ESPAÑOL ↓↓
"Coding Better World Together" es un conjunto de lecciones magistrales del famoso tío Bob (Robert Cecil Martin), donde nos brinda una visión amplia de la importancia y el futuro del software en la sociedad actual.
En esta segunda lección, el tío Bob nos enseña el propósito de los comentarios en el código, rompiendo el paradigma de que comentar es algo que "tengo que hacer" por el simple hecho de que consideramos erróneamente, que comentar es una buena práctica. Para el tío Bob escribir un comentario es señal de fracaso, pues un buen código debe poder explicarse por sí mismo: Menos Comentarios = Mejor Código.
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?
↓↓ OUR MODEL OF SOCIETY ↓↓
- mutualwelfare.org
↓↓ NUESTRO MODELO DE SOCIEDAD ↓↓
- bienestarmutuo.org
↓↓ OUR CRIPTOCURRENCY FOR MONETARY FREEDOM - NUESTRA CRIPTOMONEDA PARA LA LIBERTAD MONETARIA ↓↓
- unitycoin.net
- PRESENTATION: unitycoin.net/presentation/
↓↓ OUR PAYMENT FRANCHISE - NUESTRA FRANQUICIA DE PAGOS ↓↓
- sbmlibre.com
↓↓ OUR SOCIAL PACT - NUESTRO PACTO SOCIAL ↓↓
- e-nation.org
- PRESENTATION: e-nation.org/presentation/
↓↓ OUR SOCIAL NETWORKS - NUESTRAS REDES SOCIALES↓↓
- Facebook: / unitycoin
- Twitter: / unity_coin
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.
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.
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...
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
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
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.
>"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
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
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.
Amazing talk, but the editing is a pure failure.
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... :)
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.
This is absolutely a gift.thank you Bob and the team behind it
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 😩
Coding videos always have the best comment sections. This is my tribe for sure.
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 😄
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 :)
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
Insightful but very hard to follow because of the camera not knowing what to focus on...
Learning so much! Thank you infinitely for uploading this series
57:33 Bob: that's the same code. Editor: nope
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
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
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
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!
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.
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.
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.
I think there's universality to the notion of a pair (or more) of people working on something being vastly superior to an individual.
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.
This is absolutely a gift. Thank you Bob and the team behind it!
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
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!
camera man got so motivated by uncle bob he started thinking
"screw this, im trying to learn how to code"
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.
57:34 - 58:20: When my urge to slap the video mixer or editor out of their chair with a rolled-up newspaper peaked.
plot twist: Tom actually wrote the line /* Added by Rick */
Whoever edited this: when he says "look at this" - show the board, not the person!
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
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.
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.
Love these videos... all of them
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.
Love the talk. Super fun to discuss. He is wrong about line length though. IDEs have soft-wrap and you should be using it.
"He doesn't want to talk about pairing either!" lol
I need to send my boss to an uncle bob lecture
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 ;)
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.
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.
great videos and presentations
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.
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.
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?
@@Sahuagin because someone wrote an add-on that works that way ...
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 -_-
@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
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)
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?
Damn it, I wanted to talk about pairing!!!
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.
What do you think about Python docstrings? Are they a good practice?
@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)
When was this session (s) actually delivered??
Geez, how did the editor know that I was not interested in seeing the slides?
"OH, show them relevant information? Nah! Here's a random shot instead. "
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 -
Unfortunate necessity is very different than failure, Uncle Bob! - regarding the use of comments
What is the point of the lights that are pointing right into the projection area???
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... ^_^~
we want a certificate of completion to this series
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
Comments should explain the code ONLY in terms of things coming from outside of your system/app/code...it has a name: business logic. So easy.
Because it's something You cannot explain by the code. Whatever You code to fulfill business logic, it's exactly this: an implementation of business logic. Not the reason "why" is it so. The "why" can by initiated by a law changes, new studies done, calculation results done outside etc.
Comment things coming from an outside world!
33:27 my contra argument is: what is faster? look on comment header, or search version tree (GIT/clearcase/whatever)?
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!
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! :)
I’m looking forward to the payoff from the astronomy thing in the last part of this
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.
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)`
One thing I can infer from this talk is "git gud, gud" :D
The end was hilarious.. everyone got hungry and seemed eager to go eat , their hunger level rose even higher after Bob mentioned pair programming and the way he joked about it was hilarious. Im joking of course.
Regular expression comment does not lie. It does not say that the regexp matches ONLY that time stamp format.
GOOD EDITING
Keep the slides up longer, at least as long as you are talking about them.
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.
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.
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 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.
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...
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.
Though I agree that good code should need no comments to be understandable a recent example mod in a game made it infinitely easier to understand what line and what variables did what to the game. It was easy to understand what the code did without the comments, but to know WHY it did what it did I would've needed to know what part of the games code was depending on those variables and functions. Meaning I would've head to read the entire games source code for something a comment explained in one line.
Are there any of these design pattern books that are in typescript?
Why did y say ts instead of js?
I once remember worked on the project where I was required to add comments above every funciton :D wtf. I knew it was useless but I had to do it :D
Comments take up lines so I extract them into functions 😎
Perhaps create a string for the regex, that is named instead of a comment?
Agreed. That’s the technique I use.
the camera director is not listing what Uncle Bob says :(
Watching Uncle Bob pointing somewhere important
reminds be a bit of that time i watched some math lecture and the video person kept doing closeups of the lecturers face while he was talking about what was written on the board >D
I'll admit I have written pretty bad code which now I'm going to fix when ever I get a chance.
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!
@04:00 yeah it would have been fun to be there (in Europe) and watch that mars-sized celestial smash into the ... hum ! pacific ocean ... while I am cosily - snuggly watching this on TV.
Would not to be in USA during that event though.
And you think that you wouldn't be affected at all by the tsunami that would follow? You wouldn't be snugly watching TV for long, that's for sure. Even tropical storms from the USA make it to Europe.
@@johnhodgetts6617 tsunami? More like instantaneous vaporization, even asteroids couple kilometers wide can make all life in here go extinct in blink of an eye
while it's true that deleting code instead of commenting it out allows that code to still be found in the history of the repository, that doesn't solve the same problem. Commented out code allows you to retain the knowledge that there was code, which did this thing, that was there before. I agree that usually this isn't needed, and usually if you're doing it then your function was too big to start with. But *sometimes* it's a useful strategy.
Ideally your IDE should make it easy to see where code has changed and to access the historic code, i.e. good version control integration. For example In Sublime Text I see a little red arrow where code was deleted which I can see in two clicks.