33 ms·

That's one way to comment out code

by gohwell 13y ago

filipedeschamps 13y ago
That's also one way to not use version control.
- dchest 13y ago
  Versioning doesn't have anything to do with this piece of code.
  - _sabe_ 13y ago
    Why would you commit this code? If it's a test, put it in a branch and once the problem is solved, merge it in?
    - dchest 13y ago
      Have you read the comment? This disabled part of code is used for communication: "If someone is able to circumvent this problem, please email me". When someone reads the code to discover why it works in a certain way, they'll instantly learn that the developer thought about this, and tried to do something, but discovered that an external bug prevents him from enabling this code. It's also common to include TODO, FIXME, or BUG comments into code. Sure, you can put them into issue tracker, but having them directly in code gives more context.
  - dreen 13y ago
    I think the point is that the developer should stash it or use a branch or something, instead of having code in master that never runs. The technique itself is useful for debugging, but not much else.
    - chris_wot 13y ago
      Yeah, but it does tend to highlight to anyone reading the code that this code should work, but to look at the comment before the if statement. I'd very rarely use this sort of thing, but in this case I'd say it's OK.
- mschuster91 13y ago
  I only delete code I know I'm not going to use later. Refactoring, especially renaming files, WILL make it next to impossible to find "that one bit of code you know that does the trick", because even with a rgrep or git blame it will not turn up. As soon as the commit history is >50 commits, it's also not feasible any more to scroll through hundreds of pages of diffs. Side note: find a way to easily store "intentionally dead" code in a file, in a way that it does not show up in the code, but can be searched at least on the commandline - easy way to get rich. Devs all over the world will love you. (I'd imagine replacing a block of code e.g. with /* REMEMBERME /, git detecting this block (and inserting a / REMEMBER-ID 12345 */ instead), and git supporting a command like "git show-dead file.c" which shows all the dead code, too.)
  - spuz 13y ago
    Maybe you are unaware of git pickaxe. See the -S option of git log: https://www.kernel.org/pub/software/scm/git/docs/git-log.html https://www.kernel.org/pub/software/scm/git/docs/git-log.htm...
    - mschuster91 13y ago
      Indeed I was, yet still this forces me to remember a part of the string of the code I deleted... which may not be the case if the commit was a month or two (or more!) ago. I mostly remember just "ah, this was in class XYZ"... open it, quickly scan the file for the comment blocks and voila, there's my code.
  - stinos 13y ago
    I only delete code I know I'm not going to use later. Refactoring, especially renaming files, WILL make it next to impossible to find ... It won't, if you use proper commit messages. Once you start doing that, you'll soon discover it will make everything much more discoverable. Apart from that, death to dead code! Having worked on a project where about 10 to 20% of the code was effectively dead (either simply unused, commented out, #ifdef'ed away of if( 0 )'d away) I can assure you I never ever want that again, mainly since the dead parts still turn up in every search/grep/find reference.
- yread 13y ago
  I also hate it when people comment out code without commenting on why is it removed, why doesn't it work, what to do to make it work, who has done it, who is going to make it work and so on...
- lotsofcows 13y ago
  And then the next person looks at the code and thinks why don't they just do x. Then x doesn't work so they delete it again. Then the next person looks at the code...

That's one way to comment out code

by gohwell 13y ago

That's one way to comment out code

filipedeschamps 13y ago

That's also one way to not use version control.

dchest 13y ago
Versioning doesn't have anything to do with this piece of code.
- _sabe_ 13y ago
  Why would you commit this code? If it's a test, put it in a branch and once the problem is solved, merge it in?
  - dchest 13y ago
    Have you read the comment? This disabled part of code is used for communication: "If someone is able to circumvent this problem, please email me". When someone reads the code to discover why it works in a certain way, they'll instantly learn that the developer thought about this, and tried to do something, but discovered that an external bug prevents him from enabling this code. It's also common to include TODO, FIXME, or BUG comments into code. Sure, you can put them into issue tracker, but having them directly in code gives more context.
- dreen 13y ago
  I think the point is that the developer should stash it or use a branch or something, instead of having code in master that never runs. The technique itself is useful for debugging, but not much else.
  - chris_wot 13y ago
    Yeah, but it does tend to highlight to anyone reading the code that this code should work, but to look at the comment before the if statement. I'd very rarely use this sort of thing, but in this case I'd say it's OK.
mschuster91 13y ago
I only delete code I know I'm not going to use later. Refactoring, especially renaming files, WILL make it next to impossible to find "that one bit of code you know that does the trick", because even with a rgrep or git blame it will not turn up. As soon as the commit history is >50 commits, it's also not feasible any more to scroll through hundreds of pages of diffs. Side note: find a way to easily store "intentionally dead" code in a file, in a way that it does not show up in the code, but can be searched at least on the commandline - easy way to get rich. Devs all over the world will love you. (I'd imagine replacing a block of code e.g. with /* REMEMBERME /, git detecting this block (and inserting a / REMEMBER-ID 12345 */ instead), and git supporting a command like "git show-dead file.c" which shows all the dead code, too.)
- spuz 13y ago
  Maybe you are unaware of git pickaxe. See the -S option of git log: https://www.kernel.org/pub/software/scm/git/docs/git-log.html https://www.kernel.org/pub/software/scm/git/docs/git-log.htm...
  - mschuster91 13y ago
    Indeed I was, yet still this forces me to remember a part of the string of the code I deleted... which may not be the case if the commit was a month or two (or more!) ago. I mostly remember just "ah, this was in class XYZ"... open it, quickly scan the file for the comment blocks and voila, there's my code.
- stinos 13y ago
  I only delete code I know I'm not going to use later. Refactoring, especially renaming files, WILL make it next to impossible to find ... It won't, if you use proper commit messages. Once you start doing that, you'll soon discover it will make everything much more discoverable. Apart from that, death to dead code! Having worked on a project where about 10 to 20% of the code was effectively dead (either simply unused, commented out, #ifdef'ed away of if( 0 )'d away) I can assure you I never ever want that again, mainly since the dead parts still turn up in every search/grep/find reference.
yread 13y ago
I also hate it when people comment out code without commenting on why is it removed, why doesn't it work, what to do to make it work, who has done it, who is going to make it work and so on...
lotsofcows 13y ago
And then the next person looks at the code and thinks why don't they just do x. Then x doesn't work so they delete it again. Then the next person looks at the code...