4 ms·
> Commented-out code should not exist, granted .... I'll remove it later, I promise. In my opinion, you should never commit commented out code. Here's why: 1.
by gitgud 7y ago
> Commented-out code should not exist, granted .... I'll remove it later, I promise.
In my opinion, you should never commit commented out code. Here's why:
1. Commented out code, just confuses and clutters people's interpretation of the project. It's meaning is not clear as it's not a functioning part of the system.
3. It can incorrectly inflate the apparent complexity of a project.
2. It reduces the impact of meaningful comments, so people end up ignoring all comments.
Commit a working-state of the system only. If you're working through a problem, save the functions without commenting them out and completely remove them when you don't need them... you can always go back and find it in the source-control later when you need it.
Also, one of the first things I do when coming onto a new project is (switch to a new branch) and remove all the dead code.
- hibbelig 7y ago>> Commented-out code should not exist, granted .... I'll remove it later, I promise. > In my opinion, you should never commit commented out code. But the editor works on uncommitted code, too. GP doesn't want to be distracted by that.
- gitgud 7y ago> ... so please don't distract me. I'll remove it later, I promise. It could mean people are literally looking over his shoulder at his screen and complaining. But to me, it implies that commented code is becoming part of the project source...
- gugagore 7y agoThanks to distributed version control, you can commit all sorts of trash in your own branch while figuring things out. These commits should not clutter the project source, though if you like hoarding data like I do, you might still preserve this history somewhere else in the repository.
- sacado2 7y agoNo, I'm talking about my own "private" code in my own editor. This is a conversation with my editor while I'm "in the zone". I (usually) don't commit commented-out code, for the reasons you mentioned above.
- gitgud 7y agoAh I see the context now, sorry for assuming the intent.
- barrkel 7y agoHow about code that dumps internal state to logs or standard out and really helps when debugging a unit test? Don't want it running in production because it's a whole bunch of database queries that just tax the DB, and production volumes are bigger than test cases. Dead code, but useful dead code. (Whether excluded by switch or comment makes little odds; it has no value in being turned on dynamically, so it's statically verifiably dead.)
- ClassyJacket 7y agoMaybe we should have a second kind of comment, for code you don't want to be run. Then it can be highlighted (or the opposite) differently and not pollute real comments.