I've never seen a language's style guide recommend avoiding comments before
31–40 of 198 posts
Re: I've never seen a language's style guide recommend avoiding comments before
#32Comments say what your code does, your code says how you do it. The swap example is trivial, but for most functions it is good to add an API comment, because how you use the function shouldn't depend on how it's implemented, but what it should do, described in the comment. That way you can change your implementation as long as you don't change the contract. In other words, changing how your code does something should…
Re: I've never seen a language's style guide recommend avoiding comments before
#33I was always told that if someone couldn't tell what your code was doing by glancing at it, you'd done it wrong and should re-write it. I know that's absurd in practice, we don't always have the time but I've always used comments as a last resort. If I need to comment code to make it understandable at a glance, so be it but I'd rather avoid them all together and rewrite until it's clear enough without them.
Using Python or Perl it is easy to go from a for loop to a map or list comprehension. For many less experienced programmers it will make it less readable and more difficult to comprehend. Using a more functional approach will usually lead to less side effects and silly bugs, so I prefer to code this way, and add a comment to explain what the line is doing if it is not obvious.
Re: I've never seen a language's style guide recommend avoiding comments before
#34Re: I've never seen a language's style guide recommend avoiding comments before
#35 ...thus they (comments) tend to diverge from actual implementation.
It happens, you update/refactor code, and forget to update the comments. Thus the comments are outdated or worse not applicable anymore. Common mistake by less-detailed oriented developers. Begs the question, in this case is is better to have confusing/incorrect comments, or no comments at all?Re: I've never seen a language's style guide recommend avoiding comments before
#36This is not convincing to me because the examples are trivial: -- swap the elements of a pair swap :: (a,b) -> (b,a) Yes this is redundant. let b=a+1 -- add one to 'a' Yes this is also redundant Does it mean that every piece of code can be expressed as clearly as in a one-line comment in natural language? I don't think so.
The argument is not to never use comments, but rather to avoid bad comments.
Since I don't think anyone here would argue that "increment a by one" is a useful comment, the part about duplicate/obvious comments isn't adding much to the discussion about the usefulness of comments.
Nevertheless, it's true that comments cannot be checked by the compiler, and that's a more interesting point, I think.
Re: I've never seen a language's style guide recommend avoiding comments before
#37It may be a good idea to comment "what" the code does, if it isn't clear (the code itself is "how" it is done, but "what" does it do may be hard to read, e.g. sometimes you use a clever hack for performance reasons).
As always, handle with care :-)
Re: I've never seen a language's style guide recommend avoiding comments before
#38// get the user $user = $this->getUser();
Times that by the thousands of lines in a project and you have one big headache!
Re: I've never seen a language's style guide recommend avoiding comments before
#39Let's say you are parsing a standard tab delimited file. You find that the tab delimited file has some non-standard features, so you have to write some extra lines of code to handle it. For people who thinks the code just parses a standard tab delimited file, these lines will be confusing, so you comment these lines and say why you included them.