I’m Bill I don’t comment my code (except complex parts), instead I try to make code clear, including using proper variable and function names and try to keep functions short. I don’t think I ever got lost in my own code in my 20+ years of experience. Even got complements about it.
The programming language is meant for humans to read/write, if you need to put comments to understand your code then your code sucks.
When writing basic business code, structuring the code well and having good naming standards means you shouldn't need a ton of comments, but you should still have some. Plus, using structured function content blocks gives you intellisense in some languages and IDEs, which is important for code reuse in teams.
However, when I was doing scientific programming I'd have comments for almost every line at times where I put the mathematical formula and operations the line represents. Implementing a convolution neutral network with parameters to dynamically scale the layers or MPI stochastic simulations is much different than writing CRUD functions or basic business logic.
Comment only in extraordinary situations, when something you read can confuse someone. And by that I mean the business logic, not that you used a method that’s confusing to people since they only know the basics of the language.
Honestly, after a few years of working with juniors (and being one myself before that), I have to disagree with the last part. Sure, it’s fine for solo projects but people’s programming skills can vary heavily. I know people who will pull the wildest C++ compile time tricks you’ve ever seen, but a pointer to a pointer would somehow break their brain.
I would disagree. I love to use comments to format my code and separate the sections. I think it’s so beautiful. Also I love when libraries have ASCII art in the comments at the top of the main file lol. It makes the code more fun in my opinion.
I went to college with a guy who would treat the code as art when presenting projects. His code was always beautiful. Not super functional but always beautiful. It always stuck with me. I want my code to always be functional and beautiful. Easy to read and a pleasure to work with. That’s my goal at least. Comments help with that.
If your code needs comments, it’s either because it’s unnecessarily complex/convoluted, or because there’s more thought in it (e.g. complex mathematic operations, or edge-cases etc.). Comments just often don’t age well IME, and when people are “forced” to read the (hopefully readable) code, they will more likely understand what is really happening, and the relevant design decisions.
Rare?
Where do you guys work that all you do is write basic AI generatable code?
The only thing I can think is that you are a bunch of freelance devs who never have to maintain anything or add functionality to old code. Either that or you are all new and are just full of theoretical bullshit that you read on the internet.
Yes. I mean often enough that I wouldn’t call it rare.
You are a front-end js/ts devel, aren’t you? That makes sense. I can understand why you would have such a skewed view of programming. When everything you write is disposable and might be scrapped every 2 - 3 years, comments would seem like nonsense and a waste of time.
But that is definitely not everyone’s experience. More than half the code I have written has had a minimum 15 year life expectancy. Comments are essential to remember what I was doing in whatever random language I had to use at a given point. I might not comment on “x++;” but I sure as shit will on “x += (xDelta * yDelta + 31) / 32;” Actually, that’s not true, if the logic is complex enough for the rest of the code chunk, I might just comment on “x++;” to make it clear what x is in this case and why it needs to unconditionally be incremented here. Even if the reason seems ridiculously obvious right now. Because that shit might not be obvious at all in 10 years.
My job title is actually a data scientist. I’ve seen few pieces of code that couldn’t have been made more explainable by just using a more clear and concise naming of variables and functions. Don’t try to be so overly clever with your single letter variables and Greek alphabet. Just explain what it is with a good name.
If I’m lucky I get to write a cool new algorithm once per quarter or so. Usually it’s just a standard algorithm that has an explanation in a Wikipedia page, so I just give the name of the algorithm and a link to that page.
Most of the time we’re just doing basic data processing building on the preexisting solutions. These generally don’t need comments.
The worst code is usually when someone has tried to be overly clever (including myself). Often a simple and straightforward solution had been overlooked. Simple solutions are easier to understand and maintain. Anyone can just look at the code and get a sense of what’s going on without any comments. In many cases a simple solution has also more accurate and faster to compute.
In my work, having explainable results far outweighs anything else, and you don’t get that by writing difficult to understand code.
Exactly that! Everyone can See “what” is happening, the code is right there. But the code usually doesn’t tell you “why” that is happening - good comments help understand the authors intent and give context, so you don’t have to guess.
Good comments should explain the things that are not obvious.
Good comments more than once prevented me from accidentially undoing a fix.
I was running out of time so this it’s mostly copied from (stack overflow url)
refactor when time allows
This is a side effect of doing lots of tiny websites , microcontroller code and mini web apps for under budgeted marketing projects with constantly changing designs and requirements that don’t need to last too long.
comments are for explaining why you did things a certain way
A while back I spent more than a year modifying my company’s iOS apps so that they would work properly with VoiceOver (Apple’s screen reader technology for blind people) and be compliant with FCC regulations for accessibility (and save us from $1 million per month fines lol). The thing about VoiceOver is that it’s bizarrely buggy (or was - maybe they’ve fixed the problems since then) and even when I didn’t run into VO bugs, the way that developers tended to architect these apps often made getting them to behave properly with VoiceOver extremely difficult.
I often had to resort to very strange hacks in order to get things to work, and I would always leave comments explaining what I had done for this. My manager was one of the new breed who not only thought comments were unnecessary in ALL cases but also thought comments were a “code smell” and indicative of professional incompetence on the part of anyone who used them. Whenever he reviewed my code, he would leave in the hacks (after trying and failing to fix the problems without them) but remove my comments. This resulted in many cases later of developers contacting me to ask me why some bizarre bit of code was in the app in the first place. I always referred them to my manager with an NMP (Not My Problem any more).
I think most people fail to understand what code smell really is. They think code smell means bad code. A code smell is actually an indication that something else might be bad with the code. The code smell itself might not be bad.
So when a code smell appears, it means you should identify the reason it exists and potentially fix it. In this case the bad code is a buggy external library, which is difficult for you to fix. Therefore, leaving the “code smell” is the best course of action.
Your manager was in the wrong and you were right to write comments.
This resulted in many cases later of developers contacting me to ask me why some bizarre bit of code was in the app in the first place. I always referred them to my manager with an NMP (Not My Problem any more).
I hope this isn’t a real story. It would have taken you just as long to refer them to the commits with your comments still in, and run a git blame to show your manager took them out. Instead you just make yourself look unhelpful and incompetent.
Or just name the variable delaySeconds if you really want to store it as an int. Bonus is that every use of the variable perfectly communicates what it is.
This mindset is good, but unfortunately enforces bad programmers to leave their undocumented code in critical places where someone eventually has to figure out what the hell they were doing or refactor the whole damn thing because they got promoted to middle-management and can’t remember why they even wrote it.
If the comments tell you “what” happens, then yes, they can geht outdated fast. The details of how something works can change quickly.
But comments documenting “why” something is done (a certain way) - explaining the intent - are probably valid for mich longer.
In the best case comments aren’t viewed as something that is seperate from the code, but part of it. So that if someone changes the code, the comments has to be checked aswell (if the explanation of “why” something is done actually changed).
This is something that is always stated by people who are opposed to comments, but I’ve never seen any such thing in practice. If being mislead by incorrect comments is so common, there should be a bunch of stories around about disasters caused by them - and I’ve never read a single such story.
One example was when a method's documentation said that it would throw a certain exception. Turns out it was actually throwing a different exception (deep into the code), so no wonder why we never captured it in time.
Code comments are useful for browsing a script and understanding it at a glance. I shouldn’t have to scroll up and down across 700 lines of code to figure out what’s happening. It’s especially useful with intellisense, since I can just hover over a function and get a tooltip showing the comment, explaining what it does. It also helps when using functions imported from other files, since it’ll populate the comment showing me what parameters are needed and what each should be. Comments save time, and time is valuable.
If you’re working with others, even simple code benefits from comments explaining what it’s intended to do. Sure you can read code and get a good idea of what it seems to do, but you can’t be sure that’s what it was meant to do, or why it was meant to do that. Having a quick statement from the author enables you to work faster. And if you find a mismatch between the comment and the code, it’s a smell that could mean a bug.
And for methods and functions it’s particularly helpful to have a description at the top. Many IDEs will pop this up when you’re using the method, so you can quickly confirm that it’s appropriate for your needs and get your arguments in the right order.
I even comment code for myself because it will save me time when I return to the project months later.
No comments would be fine if you could trust that everyone writes code that does what it’s intended to do and you can read code as quickly as you can read English. Maybe I’m a poor coder but I find neither of these is usually true.
Or you’re stuck within the confines of a horrible legacy system which the business will not allow you the time to refactor/rewrite but still want your code to be somewhat readable.
But in general, I agree with your argument. When writing from scratch or improving reasonably well designed code, often documentation could be replaced by breaking it up into another function or naming variable better. It’s a bit of a code smell for violating the SRP. And yet there are times that documentation is needed for the “why”. Things are nuanced I guess.
Sounds very theoretical, my experience working on some 40 year old software full of business logic, where customer A got some feature but customer B needs it to work slightly different. Aka something approaching spaghetti.
Regarding old comments I have several times used ~15 year old comments by the original author, close to the actual code to piece together the use of that code, and if I can add my fix there.
In this setting You write comments for yourself, when you in two years need to fix a bug in the new code caused by your old code. And for the next developer that will look at your code decades after you left the company.
Sometimes you, against good practice, comment out a section, with a note why, because you know this will have to be re-enabled in a few months.
I have such a love-hate relationship with that video. On the whole, I think that video is bad and should be taken down. The creator is arguing against a very specific type of commenting but is harassing comments in all forms. It even addresses as such with a 20 second blurb 2/3 of the way into video distinguishing between “documentation comments” - but doesn’t really provide any examples of what a good documentation comment is. Just a blurred mention of “something something Java Doc something something better code leads to better documentation” but doesn’t elaborate why.
It’s a very devious problem in that I don’t feel like any particular claim in the video is wrong, but taken within the context of the average viewer, (I teach intro. comp. sci courses and students LOVE to send this video and similar articles to me for why they shouldn’t have to comment their spaghettified monstrosities), and the inconsistent use of comments vs. code duplication vs. documentation, the video seems problematic if not half-baked.
In fairness, it is great advice for someone who has been working in the industry for 15 years and still applies for junior positions within the same company - but I can’t imagine that was the target audience for this video. In my experience, anyone who has been programming on a large-ish project for more than 6 months can reach the same conclusions as this video.
I’m from the camp that thinks if you’re trying to make a case (about any subject), you should start with your strongest point and work to your weakest point. Every argument I’ve ever seen against code comments starts off with the weakest imaginable points. Usually the first point made is sample code like “x = x + 1” with the absurdly unnecessary comment “add 1 to x” - as if that’s ever something that pro-comment programmers do. This video at least started off with a novel weak point (somebody using a comment with a magic number instead of making it a constant) although it’s just as weak as the “x = x + 1” argument.
That’s like saying a book’s synopsis shouldn’t exist because you can just read the whole book. Sometimes comments can save you a lot of time and point you in the right direction.
Nah, it’s not, code is modular (IME should be kinda tree-structured), a book is linear.
So the API should be in your analogy the synopsis. And I haven’t said, that there shouldn’t be any comments. E.g. doc-comments above functions, explaining the use-cases and showing examples are good practice.
One day you will inherit a code base so bad that you’ll end up commenting old code just to make sense of it for yourself because nobody in the company has touched in a couple years and the last people that did no longer work there. It will be dangerously coupled, if you make the right change somewhere it will break everything else. It will be true spaghetti code where you spend 30 min just following a code path to figure out what and why an input into a function needs to be what it is to able to come out of another function in an exact format for anything to work.
Your so called comment standards and principals are fine if you are building something from the ground up, but the other 95% of the time, you do what you gotta do because your were blessed with a turd that is impossible to polish.
One day you will inherit a code base so bad that you’ll end up commenting old code
Will not be the case, I won’t take a job, where I have this situation (or I’ll quit pretty quickly)…
Yeah my “comment standards” (btw. as others mentioned here, I was unprecise/unlucky with the choice of words, I meant “comment the why” or doc-comments totally fine and should be aimed)
Your so called comment standards and principals are fine if you are building something from the ground up
Yes that was also targeted with my comment. But what you’re referring to is just missing documentation, and I think this should be done on a higher level. The “comment why” rule applies for spaghetti code non-the-less…
<span style="font-style:italic;color:#969896;">// Greetings, intrepid explorer, to the magnum opus of verbosity – the exhaustive elucidation
</span><span style="font-style:italic;color:#969896;">// of the venerable "Hello, World!" program in the illustrious realm of C++.
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">// Our inaugural act involves the summoning of external powers through the sacred rite of inclusion.
</span><span style="font-style:italic;color:#969896;">// The venerable library is invoked, opening the gateway to input and output sorcery.
</span><span style="font-weight:bold;color:#a71d5d;">#include </span><span style="color:#183691;"><iostream>
</span><span style="color:#323232;">
</span><span style="font-style:italic;color:#969896;">// Brace yourself, noble adventurer, for the initiation of our journey transpires within the sanctum
</span><span style="font-style:italic;color:#969896;">// of the 'main' function – the veritable heart and soul of our C++ odyssey.
</span><span style="font-weight:bold;color:#a71d5d;">int </span><span style="font-weight:bold;color:#795da3;">main</span><span style="color:#323232;">() {
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// Let us forge a pact with the realm of 'std', alleviating the syntactic tribulations
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// through the divine power of the 'using' declaration. Behold the namespace, a sanctuary
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// where the gods of C++ convene, rendering our code free from the shackles of verbosity.
</span><span style="color:#323232;"> </span><span style="font-weight:bold;color:#a71d5d;">using</span><span style="color:#323232;"> namespace std;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// As we stand on the precipice of expression, the 'cout' oracle emerges.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// This venerable entity, an emissary of the standard output stream, awaits our command.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// With the '<<' conjuration, we channel the essence of our proclamation, "Hello, World!",
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// and cast it into the void of the console, where it shall resonate for eternity.
</span><span style="color:#323232;"> cout </span><span style="font-weight:bold;color:#a71d5d;"><< </span><span style="color:#183691;">"Hello, World!" </span><span style="font-weight:bold;color:#a71d5d;"><<</span><span style="color:#323232;"> endl;
</span><span style="color:#323232;">
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// The denouement approaches, where our protagonist, the 'main' function,
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// bestows upon the cosmic arbiter – the operating system – a token of acknowledgment.
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// The triumphant 'return 0' is a symphony of numerical reverence, echoing
</span><span style="color:#323232;"> </span><span style="font-style:italic;color:#969896;">// the harmony of a flawless performance in the grand opera of computational artistry.
</span><span style="color:#323232;"> </span><span style="font-weight:bold;color:#a71d5d;">return </span><span style="color:#0086b3;">0</span><span style="color:#323232;">;
</span><span style="color:#323232;">}
</span>
// increase the dynamically allocated memory space of a word sized integer stored at the memory address represented by the symbol “x” by the integer 1 and terminate the instruction
You know what, this is on us. Chat GPT is just a prediction engine that tries to say what words it thinks follow a preceding prompt, and it’s looked at millions of examples (written by us) and it’s seen hapless clients and users complain about bugs and be told: “user error, works fine” so often chatGPT just thinks it’s just the culturally accepted polite response to a bug report, in the same way as responding to “thank you” with “you’re welcome”. This is a dark mirror on our profession.
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.