Removing commented code not only makes it harder to find later, but it also makes it so people in the future don't know it existed before. For finding the code, there are tools and git commands to help you look at the history of a file. I've had to do this before, going back months even years in a file was actually quite trivial. As for knowing of its existence, if it's that important, you could add a comment that explains briefly that something important existed there before and people can find it in the git history.
I believe this is an extremely rare case and can't think of personally ever needing to do this. Do you have more questions? Add a comment here or ping me on twitter. Kent C. Dodds is a JavaScript software engineer and teacher. He's taught hundreds of thousands of people how to make the world a better place with quality software development tools and practices.
He lives with his wife and four kids in Utah. You will love these ones as well. Back to overview 23 what's this? No translations available. Add translation. We can grab those changes and boom! If added properly, your IDE will show you exactly what a method does and why when you scroll over it. I would reformat your code comment to include at the very least the what and why.
The developer can see that just by looking at the parameters. Assign each baseball player an order in a lineup. The lineup determines when each player gets to bat. Comments are like landmarks on the highway. They may not contain verbal meaning, but they add visual impact, and make it easier to navigate. Oh, how many times people left a comment describing something and then that something changes but the comment stayed now making no sense.
You should be testing your code, and testing will tell you what your code is doing. And should write methods and lines of code that are readable. I know some ppl like to chain code like there is no tomorrow… super pro.. Variable naming. Method naming. Will help more than comments. Save my name, email, and website in this browser for the next time I comment.
CronDose Daily Dev Guides. The Case Against Code Comments. Industry Thursday. Should I Comment My Code? When code comments go bad I remember back when I learned how to code. Code Organization First and foremost, I will utilize code comments for code organization. Trust me. Reminds me of a fellow who swore he could optimize a mechanical theorem-proving algorithm I wrote years ago in an AI project.
He did improve performance but then the code didn't work Hmm, haven't I seen this one somewhere? If it doesn't have to work, I can optimize any code to a runtime of zero.
That's what source control is for. Waste a few hours trying to optimize it, and then if it doesn't work out, just roll back. The funniest part is that ti's placed in a finally block, which means it should always happen Yes, that was the joke. If you have a System. Reason to use Debug. PSD is not a good format.
PSD is not even a bad format. PSD makes inconsistency an art form. Here, though, it is not included. A sane format would pick one. The line right after that and its comment really top the cake. What sanity? The format ate it all Now it matches my thoughts. I pity that programmer for having to go through such a pain!!!
But awesome piece of comment. Has poured his heart out. In today's market 10 now has a value of only 9. Maybe someday we will evolve more fingers Calling Fortran from C - Fortran only does call-by-reference so you need variables for all constants.
Show 15 more comments. That's a win. A huge win OK I am going to use this next time I need four empty arrays and two hashes! A loud "FAIL! I doubt that he didn't know about the format-free language. I'm still trying to figure out how to comment an XSLT in a way that makes sense. We really need more dragons in our code. Initially I thought of en. I cried out in anguish. Did someone call for me? Looks like Lisp! That comment is probably there to fix a compiler bug.
Show 16 more comments. Makes me think about the far vs. It still works perfectly fine. We first put it in our compiler at Convex about 25 years ago because DMR suggested that that should be the name for our 64 bit-bit ints.
Honestly in comment! I love the honesty. The first step to improvement is to acknowledge the deficiency. A long time ago, I accidentally fixed a segfault in Java3D by adding a comment.
As long as the comment was there, it worked fine. I assume it was some bizarre timing issue, but I never did figure out exactly what was happening. This is sort of like a virus. Name u. On top of some obvious problems there, what those comments tell us is that we're dealing with bad design. There are a number of concerns with this function, such as:.
There is more that we could say about this piece of code, but let's focus on the comments and why they're indicative of the above-mentioned issues. First, if the function had complied with the single responsibility principle, we wouldn't have needed those comments at all.
The function is called updateName , and as long as what's happening inside the function is the update of a name, then there is no need to add any comment. It's self-explanatory! Second, it's clear in the example that the comments are enabling us to keep adding lines of code doing all sorts of things. A thoughtful programmer would feel unjustified in adding more and more lines of code to a single function.
But, because there are nice little comments telling us what's happening line by line, then it feels like it's not a big a deal after all. In the above example, virtually any piece of code that's preceded by a comment should be in its own function. There is no way around that. Comments are only a shortcut in this case, and they should be treated as such.
This is an easy one to identify. A piece of code that used to be running and that gets commented out should have no place in your code. As a code reviewer, it's your responsibility to point this out.
The reasons for leaving a piece of code commented instead of removing it completely are typically related to either not being sure if that code will ever be needed again, or wanting to leave it there as a point of reference for everyone else. But then, how do you preserve a piece of code that could be needed for the future? The short answer to that is: You don't. The longer answer comes in two points:. We've looked at a number of specific examples that should help you identify bad comments when you see them as you perform a code review.
But comments should almost always make you stop and carefully consider whether they're needed or not. Here's why:. With few exceptions, the only comments that can be considered good are the ones that give us a high-level description of a construct such as a class, a type, an interface, or a function. This is a perfectly acceptable comment that gives us context as to what the Car interface is about. We probably would have understood it without the comment as well, which is the whole point.
But the comment is helpful and doesn't take anything away from the correctness of the code. As we've seen, there are some cases however limited where comments can be useful for the person reading them.
0コメント