3 ms·

Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requ

Well no, I think the argument is that this kind of comment gets outdated easily, so if the program works as expected, the comment is probably outdated (new requirement, the program was changed to print every line, forgetting about the comment). If the program does not work as expected, then it's a bug and the comment is still valid. This does not happen in your function name example: if the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug.

dsp1234 10y ago
no sane programmer would If this were only true.
alexbecker 10y ago
> If the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug. Unfortunately many programmers seem not to be sane.
cmontella 10y ago
> if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that. I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand. So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.
- ifdefdebug 10y ago
  A function can be called from different places, maybe it will be used in code not yet written. So a programmer has a need to print every line. The code to be changed calls printEveryOtherLine. They won't change that function to print every line, because they know that would break things elsewhere.
- mklim 10y ago
  >So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion. I think this is a reasonable claim, even though as you've said there's nothing strictly enforcing this behavior. Function names are generally highlighted by the editor/IDE, and the developer is forced to stare at them and at least begin to type them out while calling them. They're brief and repeated over and over again in the source code. They're just harder to ignore. Comments on the other hand only appear once per comment, tend to be italicized and greyed out by IDEs, are generally at least one sentence in length and can span multiple paragraphs, and are never going to be directly referenced from within the code itself. It's still very possible to change a function without updating its name to suit its new purpose. But I know for me personally I'm much more prone to missing comments that I need to now delete or reword. I have to acknowledge the function name when I write code calling it or read code referencing it, but comments are just sort of there, hovering in the background. It's easier to read them once and then tune them out and forget that they're there.
- derefr 10y ago
  People have to call a function, using its name. The function name is the mental-model handle you have on the function. If the name is a bad representation of what the function does, then the function probably just won't ever get called, because nobody will be able to build a mental model of it. Indeed, someone else will probably end up duplicating the effort of writing the same function over again—but with an accurate name this time—because they aren't aware that the functionality they want exists in the codebase already. And this is all an implicit consideration made by every programmer, every time they define—or later modify—a function. We all know that we'll "lose track of" functions if we don't call them something memorable for their purpose. So we put thought into naming functions, and put effort into renaming functions when they change. (Or, with library code, to copy-pasting functions to create new names for the new variant of the functionality; and then factoring out the commonalities into even more functions. We go to that effort because the alternative—a misnamed function—is almost effectively beyond contemplation.)

dsp1234 10y ago

no sane programmer would If this were only true.

alexbecker 10y ago

> If the program requirement changed to print every line, no sane programmer would change the code in this function, they'd write a new function printEveryLine() instead and use that. So you can be pretty sure this is a bug. Unfortunately many programmers seem not to be sane.

cmontella 10y ago

> if the program requirement changed to print every line, no sane programmer would change the code in this function they'd write a new function printEveryLine() instead and use that. I'm not sure I understand the distinction you are making here, so I'd like to try and understand. From my perspective, function names are just another form of comment. After all, in many languages, as soon as you press "compile", your function names are mangled into something a machine can understand. So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion.

ifdefdebug 10y ago
A function can be called from different places, maybe it will be used in code not yet written. So a programmer has a need to print every line. The code to be changed calls printEveryOtherLine. They won't change that function to print every line, because they know that would break things elsewhere.
mklim 10y ago
>So you feel that programmers are more inclined to treat the function name as an authority, as opposed to a comment. Is that an accurate? I'm curious what lead you to this conclusion. I think this is a reasonable claim, even though as you've said there's nothing strictly enforcing this behavior. Function names are generally highlighted by the editor/IDE, and the developer is forced to stare at them and at least begin to type them out while calling them. They're brief and repeated over and over again in the source code. They're just harder to ignore. Comments on the other hand only appear once per comment, tend to be italicized and greyed out by IDEs, are generally at least one sentence in length and can span multiple paragraphs, and are never going to be directly referenced from within the code itself. It's still very possible to change a function without updating its name to suit its new purpose. But I know for me personally I'm much more prone to missing comments that I need to now delete or reword. I have to acknowledge the function name when I write code calling it or read code referencing it, but comments are just sort of there, hovering in the background. It's easier to read them once and then tune them out and forget that they're there.
derefr 10y ago
People have to call a function, using its name. The function name is the mental-model handle you have on the function. If the name is a bad representation of what the function does, then the function probably just won't ever get called, because nobody will be able to build a mental model of it. Indeed, someone else will probably end up duplicating the effort of writing the same function over again—but with an accurate name this time—because they aren't aware that the functionality they want exists in the codebase already. And this is all an implicit consideration made by every programmer, every time they define—or later modify—a function. We all know that we'll "lose track of" functions if we don't call them something memorable for their purpose. So we put thought into naming functions, and put effort into renaming functions when they change. (Or, with library code, to copy-pasting functions to create new names for the new variant of the functionality; and then factoring out the commonalities into even more functions. We go to that effort because the alternative—a misnamed function—is almost effectively beyond contemplation.)