6 ms·

agreed but that's why we also have // comment. No need to get fancy :)

by laythea 9y ago

ska 9y ago
commenting is not a good replacement for cleaner code, because they can drift and lie.
- laythea 9y ago
  cleaner code is not a good replacement for cleaner comments either though.
  - wolco 9y ago
    But cleaner code can remove the need for a comment.
  - wglb 9y ago
    In "Refactoring", Martin Fowler says that "comments are bugs".
    - anarazel 9y ago
      The amount of damage Martin Fowler has done with his writing...
      - wglb 9y ago
        What in particular has caused damage?
        khedoros1 9y ago
        Well, good code obviates the need for most comments. A comment shouldn't cover up a bug of clarity in a piece of code, in almost any case imaginable (basically, if it isn't a Fast InvSqrt() level of utility, the dev ought to reconsider the "cleverness" of the code). And anyhow, the implementation details of the code are liable to change; the comment becomes outdated, and there's a good chance that it won't be updated. What about a comment that notes what part of a spec some code implements (i.e. something outside the actual behavior of the code)? A comment that answers "why" can be helpful, and can sometimes be worth the high cost that an unchecked, unexecuted part of the program inherently carries. If Fowler's claiming that all comments are bugs, I'd call that damaging.
  - ska 9y ago
    When you need comments, they should be clear. But when you can make the code clear enough to need no commenting, you should do that instead.
    - hermitdev 9y ago
      Comments need to explain why they are doing something, not what the code is doing. I can tell what the code is doing by reading the source. Otherwise, I agree. The code should be clear enough that no comments are needed.
  - dalore 9y ago
    The code is the comment if it's written well.
    - ridiculous_fish 9y ago
      Some clang code: // ISO/IEC TR 18037 S5.3 (amending C99 6.7.3): "A function type shall not be // qualified by an address-space qualifier." if (Type->isFunctionType()) { S.Diag(Attr.getLoc(), diag::err_attribute_address_function_type); Attr.setInvalid(); return; } The comment justifies the code in a way that the code itself never could.
      - mikekchar 9y ago
        A unit test could document that equally well (although the pointer to the spec would still be useful). Whether or not it would fit your style of programming is another matter, of course.
        deleted 9y ago
        [deleted]
        VMG 9y ago
        A unit test would almost certainly explain the behavior in a completely separate place. That's not documentation.
      - dalore 9y ago
        if (isTypeFunction) { showErrAttrDialog(Attr); setInvalid(Attr); }
        khedoros1 9y ago
        Maybe I'm missing something. The code that you've written doesn't look any clearer to me than the code from the compiler itself, and without the comment, there's no "why" for the behavior. Later, if a bug is filed saying that the compiler isn't compliant with the requirements of "ISO/IEC TR 18037 S5.3", how can you be sure to find the code where the behavior is implemented?
- crysin 9y ago
  Whenever the whole comments argument comes up I like to bring up this article[0]. I find that it describes a good balance between when comments are useful and when they are not. [0]: https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/ https://blog.codinghorror.com/code-tells-you-how-comments-te...
- hermitdev 9y ago
  Exactly. /begin rant I'm working on a C++ code base developed by contractors that were lazy and doing things the expedient way instead of the correct way (thousands of circular dependencies between libs - and even apps - apps depending on source from other apps), multiple copies basic functionality with slight changes (largely bug fixed in one place, but they forgot the other X places it was copied). I've gone so far as to write a "cleanup" script in python that runs a number of transformations on the source. Fixing things like inconsistent line-endings (via dos2unix), inconsistent formatting (via clang-formatting), limited conversions of certain Boost uses to std C++, a few pervasive spelling errors (contracts were eastern European, non-native English speakers). Another thing I'm considering is removing all comments. Lots of dead, commented out, code. Also, invalid UTF-8 characters in comments, from an ANSI code page I've not been able to identify (which of course creates problems with the python script treating the source as UTF-8). The comments that are currently present that I've seen are: 1. stupid/moronic/redundant (like merely marking constructors as ctor and destructors as dctor with no more info - like I can't just figure that out by reading the source to begin with) 2. Just plain wrong. As-in, comment no longer matches the code. 3. In a foreign language (Ukrainian/Russian), in an unknown code-page, so also worthless at face value (yeah, I could lookup the code pages for Ukraine and Russia have give it a shot and run the result through a translator), but it's likely the result will also fall under #2. 4. Unnecessary demarcation between functions. e.g. "// -------" out to ~80 characters wide between functions with no other white-space. Want things to be clearer? Don't use K&R notation and but open & close braces on the same indentation level (e.g. don't put the opening brace at the end of your loop/function/if/else/other statement, but put them alone on the next line). 5. Dead code. Don't commit commented-out code. Delete it. That's what version control is for. Want to know what it used to do? Look at the history, not the chain of commented-out code. Commenting out code is fine for quick testing. But don't commit that. People that follow you will see that and wonder "why is this here? is this significant?" 6. Random BOM (byte-order-marks) for UTF-8 source that is actually entirely ASCII. A lot of linux tools don't expect or handle BOM in UTF-8 sources (I'm looking at you, psql). In this particular project I'm working on at my employer, I don't think I've seen a single useful comment in the source. Sadly, the Jira tasks filed by the now-fired contractors are also nearly universally useless. All headline and mostly zero description on what the problem is, usually no steps to reproduce. /rant Sorry for the rant, when I started writing this, I did not intend it to be so. But, as I wrote, I started remembering more and more things that have been driving me nuts.
deleted 9y ago
[deleted]
Retra 9y ago
But isnan is the least fancy way to check if something is NAN. What you're doing is fancy. I mean, that's exactly why you said "it took me a little while to get my head around it."

agreed but that's why we also have // comment. No need to get fancy :)

ska 9y ago

commenting is not a good replacement for cleaner code, because they can drift and lie.

laythea 9y ago
cleaner code is not a good replacement for cleaner comments either though.
- wolco 9y ago
  But cleaner code can remove the need for a comment.
- wglb 9y ago
  In "Refactoring", Martin Fowler says that "comments are bugs".
  - anarazel 9y ago
    The amount of damage Martin Fowler has done with his writing...
    - wglb 9y ago
      What in particular has caused damage?
      - khedoros1 9y ago
        Well, good code obviates the need for most comments. A comment shouldn't cover up a bug of clarity in a piece of code, in almost any case imaginable (basically, if it isn't a Fast InvSqrt() level of utility, the dev ought to reconsider the "cleverness" of the code). And anyhow, the implementation details of the code are liable to change; the comment becomes outdated, and there's a good chance that it won't be updated. What about a comment that notes what part of a spec some code implements (i.e. something outside the actual behavior of the code)? A comment that answers "why" can be helpful, and can sometimes be worth the high cost that an unchecked, unexecuted part of the program inherently carries. If Fowler's claiming that all comments are bugs, I'd call that damaging.
- ska 9y ago
  When you need comments, they should be clear. But when you can make the code clear enough to need no commenting, you should do that instead.
  - hermitdev 9y ago
    Comments need to explain why they are doing something, not what the code is doing. I can tell what the code is doing by reading the source. Otherwise, I agree. The code should be clear enough that no comments are needed.
- dalore 9y ago
  The code is the comment if it's written well.
  - ridiculous_fish 9y ago
    Some clang code: // ISO/IEC TR 18037 S5.3 (amending C99 6.7.3): "A function type shall not be // qualified by an address-space qualifier." if (Type->isFunctionType()) { S.Diag(Attr.getLoc(), diag::err_attribute_address_function_type); Attr.setInvalid(); return; } The comment justifies the code in a way that the code itself never could.
    - mikekchar 9y ago
      A unit test could document that equally well (although the pointer to the spec would still be useful). Whether or not it would fit your style of programming is another matter, of course.
      - deleted 9y ago
        [deleted]
      - VMG 9y ago
        A unit test would almost certainly explain the behavior in a completely separate place. That's not documentation.
    - dalore 9y ago
      if (isTypeFunction) { showErrAttrDialog(Attr); setInvalid(Attr); }
      - khedoros1 9y ago
        Maybe I'm missing something. The code that you've written doesn't look any clearer to me than the code from the compiler itself, and without the comment, there's no "why" for the behavior. Later, if a bug is filed saying that the compiler isn't compliant with the requirements of "ISO/IEC TR 18037 S5.3", how can you be sure to find the code where the behavior is implemented?
crysin 9y ago
Whenever the whole comments argument comes up I like to bring up this article[0]. I find that it describes a good balance between when comments are useful and when they are not. [0]: https://blog.codinghorror.com/code-tells-you-how-comments-tell-you-why/ https://blog.codinghorror.com/code-tells-you-how-comments-te...
hermitdev 9y ago
Exactly. /begin rant I'm working on a C++ code base developed by contractors that were lazy and doing things the expedient way instead of the correct way (thousands of circular dependencies between libs - and even apps - apps depending on source from other apps), multiple copies basic functionality with slight changes (largely bug fixed in one place, but they forgot the other X places it was copied). I've gone so far as to write a "cleanup" script in python that runs a number of transformations on the source. Fixing things like inconsistent line-endings (via dos2unix), inconsistent formatting (via clang-formatting), limited conversions of certain Boost uses to std C++, a few pervasive spelling errors (contracts were eastern European, non-native English speakers). Another thing I'm considering is removing all comments. Lots of dead, commented out, code. Also, invalid UTF-8 characters in comments, from an ANSI code page I've not been able to identify (which of course creates problems with the python script treating the source as UTF-8). The comments that are currently present that I've seen are: 1. stupid/moronic/redundant (like merely marking constructors as ctor and destructors as dctor with no more info - like I can't just figure that out by reading the source to begin with) 2. Just plain wrong. As-in, comment no longer matches the code. 3. In a foreign language (Ukrainian/Russian), in an unknown code-page, so also worthless at face value (yeah, I could lookup the code pages for Ukraine and Russia have give it a shot and run the result through a translator), but it's likely the result will also fall under #2. 4. Unnecessary demarcation between functions. e.g. "// -------" out to ~80 characters wide between functions with no other white-space. Want things to be clearer? Don't use K&R notation and but open & close braces on the same indentation level (e.g. don't put the opening brace at the end of your loop/function/if/else/other statement, but put them alone on the next line). 5. Dead code. Don't commit commented-out code. Delete it. That's what version control is for. Want to know what it used to do? Look at the history, not the chain of commented-out code. Commenting out code is fine for quick testing. But don't commit that. People that follow you will see that and wonder "why is this here? is this significant?" 6. Random BOM (byte-order-marks) for UTF-8 source that is actually entirely ASCII. A lot of linux tools don't expect or handle BOM in UTF-8 sources (I'm looking at you, psql). In this particular project I'm working on at my employer, I don't think I've seen a single useful comment in the source. Sadly, the Jira tasks filed by the now-fired contractors are also nearly universally useless. All headline and mostly zero description on what the problem is, usually no steps to reproduce. /rant Sorry for the rant, when I started writing this, I did not intend it to be so. But, as I wrote, I started remembering more and more things that have been driving me nuts.

deleted 9y ago

[deleted]

Retra 9y ago

But isnan is the least fancy way to check if something is NAN. What you're doing is fancy. I mean, that's exactly why you said "it took me a little while to get my head around it."