4 ms·

Committing commented out code means you're trying to communicate with comments in your code. English isn't the only language that's useful in comments, especial

by codemac 11y ago

Committing commented out code means you're trying to communicate with comments in your code. English isn't the only language that's useful in comments, especially when trying to document something of computable logic. If you have any comments in your code at all, you could make the same argument about "not knowing how to use your version control system" as everything could be in commit logs. And please define "team-friendly", it is absurd to suggest that the git cli makes anything friendly.

pyre 11y ago
> And please define "team-friendly", it is absurd to suggest that the git cli makes anything friendly. Is this how you develop? 1. Comment out old code. Make a note of why this was removed (and maybe the date). 2. Add new code. 3. Commit.
- hobs 11y ago
  I have seen that. I have also seen that, but without the third step. Its the fastest way to get a bunch of comments in your code(as well as code) that is probably meaningless if not actively bad for you to store in your brain.
- codemac 11y ago
  Is this how you document your code? 1. Write comment about code, and commit it. 2. Delete comment about code, and commit the removal. I mean hey - your team mates should be able to use a VCS right? Facetious workflows miss the point, judgment can be used to determine what should be commented out vs not. I strongly prefer source code that is well documented, not at some point in the past, but right there at HEAD/master/main/tip/whatever
  - pyre 11y ago
    While that might be true, keeping an old reference implementation around for 30+ years "just in case" you hit some aberrant behaviour or weird edge-case seems extreme. It seems to me (and I may be wrong) that it would make more sense to either turn the reference implementation into a spec document (and keep that next to the code) or to dub that code the "canonical reference implementation" instead of referencing some ancient version of Emacs. By referencing the ancient version of Emacs (and the subsequent change to the new code), the comment comes across as an anachronism. It was (seemingly) left there in case there were compatibility issues while moving to the new code. This seems out of place now because if compatibility issues haven't come up in 30+ years, then I doubt that they will now (or that there is much code relying on edge-case quirks from such ancient versions of Emacs). At what point does the current implementation (and any quirks that deviate from that ancient version) become the reference implementation? In another 30 years?
stevebmark 11y ago
Committing commented out code clutters the codebase, clutters the commit history, degrades the searchability of the commit history, and is usually a big middle finger to your teammates by saying "this thing I use for debugging belongs in the main branch." Not knowing how to efficiently use the Git API is a fault of the committer, not an excuse to clutter the code. A comment with the exact command to run such as "// To see how this blah blah blah, run `git show 049fa0293f:path/to/file.elm`", as suggested, makes this a moot point anyway.
- codemac 11y ago
  > [commenting the sha] makes this a moot point anyway. No, it does not. Emacs has gone through 4 version control systems, I can't imagine how they'd refer to it in a comment. As someone who's been through several, I guarantee you that git is not the final frontier of VCS. Also - if you intend the comment to communicate to your team (as this commit does.. did you read it?), then your other comments also make little logical sense.

by codemac 11y ago

pyre 11y ago

> And please define "team-friendly", it is absurd to suggest that the git cli makes anything friendly. Is this how you develop? 1. Comment out old code. Make a note of why this was removed (and maybe the date). 2. Add new code. 3. Commit.

hobs 11y ago
I have seen that. I have also seen that, but without the third step. Its the fastest way to get a bunch of comments in your code(as well as code) that is probably meaningless if not actively bad for you to store in your brain.
codemac 11y ago
Is this how you document your code? 1. Write comment about code, and commit it. 2. Delete comment about code, and commit the removal. I mean hey - your team mates should be able to use a VCS right? Facetious workflows miss the point, judgment can be used to determine what should be commented out vs not. I strongly prefer source code that is well documented, not at some point in the past, but right there at HEAD/master/main/tip/whatever
- pyre 11y ago
  While that might be true, keeping an old reference implementation around for 30+ years "just in case" you hit some aberrant behaviour or weird edge-case seems extreme. It seems to me (and I may be wrong) that it would make more sense to either turn the reference implementation into a spec document (and keep that next to the code) or to dub that code the "canonical reference implementation" instead of referencing some ancient version of Emacs. By referencing the ancient version of Emacs (and the subsequent change to the new code), the comment comes across as an anachronism. It was (seemingly) left there in case there were compatibility issues while moving to the new code. This seems out of place now because if compatibility issues haven't come up in 30+ years, then I doubt that they will now (or that there is much code relying on edge-case quirks from such ancient versions of Emacs). At what point does the current implementation (and any quirks that deviate from that ancient version) become the reference implementation? In another 30 years?

stevebmark 11y ago

Committing commented out code clutters the codebase, clutters the commit history, degrades the searchability of the commit history, and is usually a big middle finger to your teammates by saying "this thing I use for debugging belongs in the main branch." Not knowing how to efficiently use the Git API is a fault of the committer, not an excuse to clutter the code. A comment with the exact command to run such as "// To see how this blah blah blah, run `git show 049fa0293f:path/to/file.elm`", as suggested, makes this a moot point anyway.

codemac 11y ago
> [commenting the sha] makes this a moot point anyway. No, it does not. Emacs has gone through 4 version control systems, I can't imagine how they'd refer to it in a comment. As someone who's been through several, I guarantee you that git is not the final frontier of VCS. Also - if you intend the comment to communicate to your team (as this commit does.. did you read it?), then your other comments also make little logical sense.