Cue the self-documenting, we-don't-need-no-stinking-comments rabble rousers in 3, 2, 1...
AND that's one reason why we're not an actual profession, people.
AND that's one reason why we're not an actual profession, people.
But really, comments are one way to mislead in code. If a comment is made that incorrectly states the intent of code, it's undeniable that this is harmful to the readability of the code.
http://michaelochurch.wordpress.com/2012/11/18/programmers-d...
Comments may mislead yes, but that's a problem with any sufficiently expressive language, and code is one such language: code can mislead. The functionality required of the code may be only half-implemented, then that code is misleading. That code may work for certain easy cases, but it may be harmful to your understanding of what functionality is actually required.
It's easy to see why we prioritize code over comments, why we prioritize the mechanisms over the specifications. It's because code can have some manner of automatic verification, and we're too harried to look into the comments, to do code review. Deadlines abound. We can't stop work and say, no, we can't do this under these time constraints without sacrificing a minimum level of quality, specifically because we're not treated like an actual profession with the clout or the responsibility that comes with such a thing.
And I can say "this can't be done under these time constraints" at my job. If you can't, then you're not being taken seriously because of some other reason, not because you're a programmer.
Who cares about these things, which don't change the code? Anyone who needs to understand the code, which includes anyone working on it, including its original author - writing a brief explanation of a tricky point can help you spot mistakes before you compile or test, or even before you write the code. The goal is to produce correct code, not just code, and the one thing that is faster than continuous testing is avoiding mistakes in the first place.
FWIW, I think the idea that comments need to be complete sentences is silly. Sentences can be as wrong, ambiguous, misleading or uninformative as simple phrases.
You don't need comments to run code.
I think the only thing really stopping software development from becoming a formal profession is a standardized code of ethics (of which there are several proposed) and a professional body to govern it (and let's face it, professional bodies can exert power to satisfy immoral agendas, much like unions).
Then:
Professionals are allowed and expected to dedicate about half their working time to career development and continuing education. Many software engineers will get fired if they get caught in that.
This is pretty much false.
Honestly, given all of this, I don't even think software development becoming a profession is desirable at all.