4 ms·

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

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