4 ms·

> 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

by 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?

by pyre 11y ago

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?