@tomershechner
Smooth transitions between concepts, meaningful commentary and instructive examples. What a nice video!
@cajonesalt0191
I've never really understood the "don't use comments to explain how something works only why it's in the code" argument, but if the example in this video of explaining "how" is what that rule is supposed to stop, then I totally get it now.
@nerdycatgamer
1:35 You've got the example wrong. We're not `grep`ing the output of the program for the error message (splitting up the error message in the source code isn't going to cause it to be printed any differently anyways): we're `grep`ing the source code for where that error message is, so we can see under what circumstances it gets printed.
@ktostam3478
Strangely meditative, straight to the point and so smooth that it doesn't need outline/introductions to connect the topics. Well done!
@spfy
I was confused by what you said about being able to split up lines by concatenating them. In your example, sure, the program output is still in one line so it's possible to use grep. But what if instead, you wanted to find where that error message was in the actual code? Now you can't find it, because it's split up...
@AlexanderVulpes
I 100% agree about comments, they're supposed to explain the "what" more than the "how". It's a good way to help future devs find bugs too.
@magnusmarkling
How does Linus come into all this? Didn't hear him mentioned even once in the video.
@IgorGuerrero
Two of my favorite rules from Linus is "early returns" and "prefer positive conditions over negative"
@kipchickensout
"Don't trust people who don't put swear words in their code comments" - Fireship, slightly altered
@PJutch
I disagree with 8 tabs example. I used to reading code 2 times more zoomed in than an example you've showed. This makes "too far to the right" mark go to, like, 4 levels of indentation. And also you've showed an example in Go which isn't an OOP-obsessed language. In C++ you'll get 3 levels of indentation just from method in a class in a namespace, and having 24 space nothing always at the start of the line seems bad for me.
@unexpectedkAs
Excellent examples! Usually guidelines are difficult to convey because most examples are too trivia, simple and or unrealistic/ academic.
@1schwererziehbar1
god created eight character indentation to protect us from excessive nesting.
@HansBezemer
Where in the world is it "self evident" that src is "source" and dest is "destination"? Hint, it isn't. Counter hint, list your variables at the very start of your function or program and comment on them - like explaining what they stand for. Note that "modern" languages, especially monsters like Java, C++ or PHP (but essentially every OOP language) has long lists of object names and method names, so column 80 is never far away. Also note that some "gurus" are claiming "self evident" names are 16, 24, 32 characters or even longer. Ok, that means that when I've just referenced an object with a property, we might already have reached column 64 - and we've not assigned it to anything. So yeah, 8 character wide tabs are fine in theory - but in practice it's just another lousy idea that we will most certainly mock five years from now - just like the "kill the parenthesis" frill and the "you don't need comments" frill. Fortunately, I don't care for gurus - nor for frills. I'm still happily maintaining sources, 10, 20, 30 years old. I even understand what I put down yesterday.
@RavenMobile
I use 3 spaces for tabs, and keep the code not wider than 80 characters except in special circumstances. If code will be much longer than 1-2 pages, I start refactoring and adding well-named functions.
@Rekwalde_PoE
I generally think about it like "Will I ever print this code via my printer?", the answer usually gives me clarity on what my print width should be. Because I don't have a printer.
@vankouver32
That "switch/case" with animals is diabolical :D This could be done in 3-4 lines!
@MrHaggyy
With comments, it depends on what the code is for. When learning a language, they are a great place to dump ideas. Explain to you what you are trying to do and give each implementation some text what it's actually doing. Helps to understand what the heck you did 3 weeks ago, benchmarking, writing assignments, etc ... When writing code that people work with drop the explanation. If you can't read the code you have a skill gap or communication issue in your team. But keep your problem description and the scope of your implementations. For example copy data/error_msg/log to buffer in the string example. When reviewing you can count the occasions where "text" needs to be copied into a buffer and reason about how many "copy to buffer" functions you need. Maybe one is a fast copy of 16 chars for an ID number, while the other copies a name like your version in the video. Then there would be code for teaching. In that case, explaining the code is the primary job of comments. But it would be great if more sources were already adding a mature way of commenting and how to work with comments, so people get used to it from the start.
@chonkusdonkus
tabs are configurable in your editor and objectively better
@steinarst9084
3:45 - "So that how it works, is obvious." - does cool animation with code, proceeds to put ad over code - you villain xD Great video. Loved the bit about indentation.
@sven-o