4 ms·

Seems like a manifestation of Chesterton's Fence! https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterto

Seems like a manifestation of Chesterton's Fence! https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

aperrien 8y ago
AKA "Most regulations are written in blood."
fzeroracer 8y ago
This is also, as it turns out, one of the most pertinent things a developer should be considering at all times. Sometimes we may get a bit too refactor-happy, not seeing the use behind a certain fix, a line of code or a strange function. Our first instinct isn't to understand it, but to tear it down, gleefully assuming that it's useless.
- xondono 8y ago
  This reminds me of the infamous comment block: // // Dear maintainer: // // Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy // total_hours_wasted_here = 42 Edit: to improve legibility
  - LeifCarrotson 8y ago
    Indent 4 spaces to format as a code block instead of flowing together or separating with blank lines as paragraphs: // // Dear maintainer: // // Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy // total_hours_wasted_here = 42 Note that on narrow windows or mobile screens this doesn't wrap and needs to scroll sideways for long lines (though these are wrapped to 60 characters), which is annoying
    - ergothus 8y ago
      (Increments time wasted counter)
    - logfromblammo 8y ago
      If a viewport cannot handle gracefully lines of 80 characters, it is not the fault of the person writing the 80-character lines. If a code block is the right answer, I would hope that people use it, rather than attempt a workaround just to avoid a flood of gripes from people on mobile who don't want to scroll right. Fix your scrolling issue by fixing your scrolling issue, not by trying to retrain everyone that posts on HN to cater to mobile viewers, in lieu of just marking the text that requires differentiation of newlines from other whitespace. Also, you only need to indent 2 spaces: Everyone- use code blocks whenever you need them. Mobile users- don't complain about code blocks.
      - kortilla 8y ago
        The viewport can handle lines of 80 characters. The problem is that HN indents so far and even truncates on the right so you’re working with like 40 chars visible.
- amelius 8y ago
  Proper testing procedures will catch it, though.
- dri_ft 8y ago
  The trouble comes when the others working on your code are crazy enough that that strange code often is useless, so you have to spend the time trying to work out whether it's tear-out-worthy.
  - javajosh 8y ago
    A sign of maturity is to a) recognize when code is crazy, and b) document why it is so in a comment.
    - couchand 8y ago
      Here let me fix that for you: "document why it is so in an executable test".
      - pure-awesome 8y ago
        Sometimes possible, but not always. An executable test is good for documenting what a piece of code should do, but not always entirely sufficient for documenting why.
        jsight 8y ago
        Exactly, and in the pathological case it ends up documenting the why incorrectly and the code is still wrong.
        pure-awesome 8y ago
        Yes, but this is hardly an argument against using comments. There will always be a pathological case. The question is what approach will increase your chances of success, what's least likely to lead to problems, what's the cost-risk-benefit tradeoff etc. Comments detailing the intent of a non-obvious function are valuable for maintainers wanting to figure out what's happening in the code. They are written in human-oriented business-oriented language, so they don't take effort to read. The intent of the code should not change that often. If they diverge from the code, the effort of changing them should be small enough to be worth it. Ideally they should be treated as important and if they are wrong it should be picked up in the code-review. Comments detailing just the description of what a function does, by contrast, are not valuable, since that information can be deduced from the code itself. Every time the function changes, the comment will change. Reading them is as much effort as reading the code, so if they diverge it won't be picked up as easily. There are always exceptions to these kinds of guidelines, of course, but this at least gives motivation for why I think comments should be used in this way.

Seems like a manifestation of Chesterton's Fence! https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

aperrien 8y ago

AKA "Most regulations are written in blood."

fzeroracer 8y ago

This is also, as it turns out, one of the most pertinent things a developer should be considering at all times. Sometimes we may get a bit too refactor-happy, not seeing the use behind a certain fix, a line of code or a strange function. Our first instinct isn't to understand it, but to tear it down, gleefully assuming that it's useless.

xondono 8y ago
This reminds me of the infamous comment block: // // Dear maintainer: // // Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy // total_hours_wasted_here = 42 Edit: to improve legibility
- LeifCarrotson 8y ago
  Indent 4 spaces to format as a code block instead of flowing together or separating with blank lines as paragraphs: // // Dear maintainer: // // Once you are done trying to 'optimize' this routine, // and have realized what a terrible mistake that was, // please increment the following counter as a warning // to the next guy // total_hours_wasted_here = 42 Note that on narrow windows or mobile screens this doesn't wrap and needs to scroll sideways for long lines (though these are wrapped to 60 characters), which is annoying
  - ergothus 8y ago
    (Increments time wasted counter)
  - logfromblammo 8y ago
    If a viewport cannot handle gracefully lines of 80 characters, it is not the fault of the person writing the 80-character lines. If a code block is the right answer, I would hope that people use it, rather than attempt a workaround just to avoid a flood of gripes from people on mobile who don't want to scroll right. Fix your scrolling issue by fixing your scrolling issue, not by trying to retrain everyone that posts on HN to cater to mobile viewers, in lieu of just marking the text that requires differentiation of newlines from other whitespace. Also, you only need to indent 2 spaces: Everyone- use code blocks whenever you need them. Mobile users- don't complain about code blocks.
    - kortilla 8y ago
      The viewport can handle lines of 80 characters. The problem is that HN indents so far and even truncates on the right so you’re working with like 40 chars visible.
amelius 8y ago
Proper testing procedures will catch it, though.
dri_ft 8y ago
The trouble comes when the others working on your code are crazy enough that that strange code often is useless, so you have to spend the time trying to work out whether it's tear-out-worthy.
- javajosh 8y ago
  A sign of maturity is to a) recognize when code is crazy, and b) document why it is so in a comment.
  - couchand 8y ago
    Here let me fix that for you: "document why it is so in an executable test".
    - pure-awesome 8y ago
      Sometimes possible, but not always. An executable test is good for documenting what a piece of code should do, but not always entirely sufficient for documenting why.
      - jsight 8y ago
        Exactly, and in the pathological case it ends up documenting the why incorrectly and the code is still wrong.
        pure-awesome 8y ago
        Yes, but this is hardly an argument against using comments. There will always be a pathological case. The question is what approach will increase your chances of success, what's least likely to lead to problems, what's the cost-risk-benefit tradeoff etc. Comments detailing the intent of a non-obvious function are valuable for maintainers wanting to figure out what's happening in the code. They are written in human-oriented business-oriented language, so they don't take effort to read. The intent of the code should not change that often. If they diverge from the code, the effort of changing them should be small enough to be worth it. Ideally they should be treated as important and if they are wrong it should be picked up in the code-review. Comments detailing just the description of what a function does, by contrast, are not valuable, since that information can be deduced from the code itself. Every time the function changes, the comment will change. Reading them is as much effort as reading the code, so if they diverge it won't be picked up as easily. There are always exceptions to these kinds of guidelines, of course, but this at least gives motivation for why I think comments should be used in this way.