My short comment on why you should stop using comments in your code (unless in special cases)
Tl;dr
Please, think twice before adding c...
For further actions, you may consider blocking this person and/or reporting abuse
One question that I find useful to know if a comment should be added or not is: Is it at the same level of abstraction as the code?
If it is at an higher level of abstraction, it provides context and might be useful. If it is at a lower level of abstraction, it provides constraints and might be useful. Both help explain a technical decision. And this the purpose of comments, to explain the why. That avoids making others loose their time figuring out a decision or trying something that we found inappropriate.
If it is at the same level of abstraction, it should not be added. It says the same thing the code says. And if it is needed to understand the code, I agree with you that it is a sign that refactoring is needed.
But thinking in level of abstractions might not be easy to grasp. Especially for beginners to whom those kind of tips might be useful.
It's a good tip - thanks for that!
Another tidbit that is useful in a comment is documenting special values in the inputs or outputs. No one wants to trace code to find out what are valid parameters or what meaning a nil or null takes in a parameter. Depending on your language the expected types can be critical as well.
Sometimes this is obvious, but if it isn't a comment is much easier.
comments seem to be an idiot code for the computer
After reading A Philosophy of Software Design (amazon.com/Philosophy-Software-Des...) my take on this is that comments that describe WHAT the code is doing on the same abstraction level as the code should not be written. If the comment is describing WHAT the code is doing on a higher abstraction level it might be something good to write, might be, it depends on the situation and how the comment is written (so that it really is on a higher abstraction level).
Comments that describe WHY the code is doing something or doing something in a specific way should be written when needed (and also sometimes when not needed) to tell the other developers (and future you) why a specific way was chosen. A good example from my personal work life is when I wrote a function with about 20 lines of code doing a thing that could be done using a one-liner with a regular expression, the reason for me to chose the 20 line method was that it was much much quicker and this specific method would be running many times so how quick it was running was more important than if if could be written using fewer lines of code or not.
What about doc-comments, for example in Rust with
///?Those are used to generate documentation later on and IDEs like VSCode use it to give you helpful descriptions when hovering over types.
Adam Crockett (whose name I swear I've seen before) makes a good example of this in their comment.
This. I never use comments for functions because the name should be a good enough description.
However, I almost ALWAYS put comments over my properties because I HATE not knowing what the property is used for when I have to use another teams stuff. And also it helps when you get the intellisense bubble... and also with Storybook.
I have a good advice for every developer.
If possible turn color of your comments to red so that you see them as an error and then try to delete them as fast as possible.
If you still think comments are useful, read this book amzn.to/3B3yUB8
And if you do not want to read the book, see this presentation by the author: https://www.youtube.com/watch?v=7EmboKQH8lM&t=1s
Also, Uncle Bob explains in the book (and in the presentation) how clean, readable and maintainable code can be produced.
To be honest, everybody should read this book!
I would say that if you read Clean Code then you should also read A Philosophy of Software Design (amazon.com/Philosophy-Software-Des...) to get another view on the matter. Just because Uncle Bob wrote something in Clean Code doesn't make it the only way to see things. There are some problematic things with the Clean Code view that makes code harder to read.
Iโve read Clean code and Iโm pretty sure heโ he didnโt say comments are bad. He provided cases in his experience where they were and were not useful.
No he did not say that in his book.
But within his presentation (the YouTube link) he explains how he personally does it with his IDE just to avoid having comments all over the place.
The main problem with comments is that they will not be updated after changing some lines of codes. Or maybe a function has a comment how this function solves a problem by using XY. But if XY gets changed maybe the comment for XY will be updated but the calling functions will not receive an comment update.
as an example lets think about you have a function that uses another function to sort an array:
This is just an very easy, understandable problem that should describe the problem with having comments everywhere. You can easily exchange the sorting algorithms and the call hierarchy with other things, but the comment-problem still exist.
This is dumb advice if taken literally. 99% of code comments may be useless. But the comment that says "this seems like it should be done more easily with this other feature, but bug-NNN forced us to do this" can save a lot of work in the future.
Honestly, these comments that say please refactor are the worst.
Please avoid them in a team. Use your Repository Tool (Bitbucket, GitHub, Gitlab, etc) to add a comment within the tool and add an issue/ticket as soon as possible to fix the bug.
Using comments instead of refactoring/fixing the code is one of the worst things to do.
It will lead to unreadable, not maintainable code. Because if you do it once, you will do it everywhere. And instead of having clean readable code you will have old, wrong, buggy, not-optimized functions within the whole codebase. And then you fix one bug and will create multiple others because you did not read the comments... ALL comments because you never know where a lazy developer has done such a thing...
Please, don't do that.
Never... Really... Never
One case where lots of comments are welcome is working on legacy code that nobody on the job wrote and nobody fully understands. When you figure out some complicated interaction --- please by all means leave a big fat warning comment. Nobody will complain about it.
The premise of this article is the same as what I read in Clean Code (by Robert Martin). Basically, don't state the obvious and write self-documenting code instead. Thank you for reminding developers how to write cleaner code.
As I previously stated he didnโt flat out say to not comment, just not to make obvious comments. Doc blocks and complex code is still okay to document.
Was there something about my comment you were disagreeing with? I agree with what you're saying.
Totally agree! Variable and function names should be descriptive in and of themselves. I even wrote a post about it some time ago lol
I'd add one more case in which comments are allowed, it's kinda similar to the business logic - hacks lol. When you break your head over a problem and end up using a hack to go around it, it's useful to know if the hack is redundant or still needed.
It should include links to your research too, to be able to pick it up when you (or a colleague) has more time.
If you do not use docblocks, you are not writing code that meets standards for the majority of modern languages and it should not be accepted in any project. Please ignore this advice if you are learning to develop and use docblocks and follow other important standards!
If you are writing comments that confuse. It's not the comment, it's the writer.
Bro, let me be honest with you, I disagree with your points to some extent until someone answers the following:
First, you said comment makes your code longer and can be misleading. I don't see how it can be misleading if you're doing the proper thing in your code, but it helps a lot.
You add comments to your code knowing that it will help you and other developers a lot in the future so that you can remember what you did and what you were thinking then. Therefore, this should not bother you even if it makes your code longer.
This alone goes a long way in helping to enable you make updates to the code that will not break your project at all.
Now, there is one thing that majority of developers are not thinking ๐ค about. And the thing is, even if you use meaningful names instead, what if a function is doing one task before, let's say you created a function called "uploadExcelFile()" and after some weeks or months, you come back and add another task to the function, how do you update the name of the function to reflect its current behavior after you have used the name in so many files? Do you change the name.of the function to reflect the current update and also change the name in every file as well or you leave it like that when commenting is not an option? But if you leave the name of the function as it were before you updated the code, then the name will still be showing that the function has not been updated when in fact, it has been updated (because you cannot know the future name you will give a function until you write a code for it).
Would it not be better to also add extra comment on top of the function to explain the current update than changing the name of the function in every file that you have used it? Can someone answer that one? I guess you guys aren't thinking towards that direction ๐
I have heard someone talk like this on Quora before, and I'm sure you must have used some of the points from there too.
We use the rename-command to change the name automatically everywhere it is used.
Yes for you. But some developers don't do that. They just leave the first name like that. What of in a case where the editor you use doesn't have the rename command? Can you do that conveniently with notepad++, vscode, atom, sublime text, etc?
You asked, whether it would not be better to add a comment. No, it would not. The function name is the information that shows up in code completion and is the first thing people see. If you can, you should make sure that it reflects what the function does.
You might still be forced by your tooling to add a comment instead, but thatโs then a question of tooling not of whatโs the right thing to do.
Also you may want to add a comment anyway, because the three-to-five words you use in a function name are often not capable of capturing the more subtle information you need when using the function. Look at the Javadoc of some of the Java Collections methods.
You could make the name much longer, but then it is polluting the code where it is being used with information you only needed when writing the code, but usually not while reading it, because there you can usually assume that the original author made the right choice.
(Sidenote: your argument would be much stronger, if you asked what to do for public API of libraries. There it is impossible to change the name of the function where it is used, because you donโt control those parts of the code).
Read my comment very well. It seems you don't understand it. Plus, you're even contradicting yourself bro ๐ค .
No, Iโm not contradicting myself. Iโm telling you that you make a weaker argument than you could.
In my first message I answer your general claim (what would you rather do? If I can, Iโll refactor; depending on the IDE that can be as simple as a single keyboard shorcut). In my second answer I add the limitations and fine details that must be checked to take a good decision.
Donโt expect a simple yes/no answer when it comes to comments.
Also Iโm not your bro.
And my reply then was "Is it everybody that uses IDEs?" Most developers I Know use vscode and do they keep replacing the function name in every file they used them when they add new features to it? This is my main point. You can speak for yourself but don't try to speak for everybody. Because you can't.
And also, it's your choice whether you are a bro or not.
I won't reply you again. Because it seems you are proving obstinate.
I agree with @arnebab
VSCode has the features required to rename the function. Even vim has it if well configured.
If people choose to code with a dumb editor, they are not using adequate tooling to make good software.
And if you choose not to use the features of the editor then I can't argue that you will have to find hacks like generic function names and comments. But that code will not be as clean as it can.
I answered you โYou might still be forced by your tooling to add a comment instead, but thatโs then a question of tooling not of whatโs the right thing to do.โ
Thatโs for the ones without working rename tooling.
Very well written Dominika and thank you for the tldr pointing to common sense and writing better code overall!
I'm not in favor of comments which do not get generated into docs but I don't agree with rigid opinions like this one. We cannot control the need of comments but should reduce them as much as possible by maintaining good readability.
This is the correct take.
If you are writing a reusable library, you should definitely add documentation comments.
These kind of comments are there to explain how to use your library and allow Doc tools to generate the user documentation.
I think you missed the main point of when comment are useful and what good comments are all about, explaining intent and purpose. Why things were done that way. No matter how clean or good your code are, these are never going to be readable from the code.
Very well written and explained! ๐
It was an interesting article. I rarely use comments
Code speaks to the machine and humans, comments only speak to humans. Thatโs why comments can always be easier to understand and give more context than code.
They may not always do that, and if the code gives the information sufficiently easy to take in as the comment, I prefer just having the code, but I spent the last years working on a codebase of which a part suffered from having no comments due to adhering strictly to clean code.
The parts with comments are always easier to understand.
Leaving out comments leads to code that replicates the comments but does not actually make a difference.
The main differences between the name of your function and a comment is that you have more constraints in spelling the function and that the function shows up in code-completion and at any place your function is used (which can be an advantage, but also adds more constraints).
I disagree with the fact that comments are bad. I tend to favour comments as they are extremely helpful (even if they might seem redundant).
I worked many times in legacy code bases with 0 documentation and 0 comments. I wasted many many days trying to figure out code logic (just to much later understand that in fact the logic was only half of the problem and the other half was lying in business logic - comments would have definitely helped there).
For the reduntant comments, I think they will be good for any new joiner on the project (they might be redundant to you the one who wrote the code but not to some1 completely new).
Yeah you can have descriptive names and yeah code is self explanatory (if the functions/blocks have a decent length and you don t have like 400 + lines functions) but the why behind it is critical in understanding everything.
For my projects I make it as a rule in PR to have comments changed if you edit the function underneath otherwise PR won't pass.
Comments help me understand what's happening at a glance as I'm working, especially with new things I'm trying out to keep me focused on what it's supposed to do. It's also a form of rubberducking for me if I get stuck for a minute. I will add stuff above functions for clarity but that's about it. They get stripped after I'm familiar enough with what I'm doing to explain it to myself and others without missing a beat.
Learn to ignore comments and read them when you don't understand the code. It's just so simple.
Visit W3Schools.com!
[url=w3schools.com/]Visit W3Schools.com![/url]
Visit W3Schools.com!