5 ms·

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and t

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.

choward 10y ago
Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?
- eternalban 10y ago
  Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.
  - posterboy 10y ago
    We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.
    - eternalban 10y ago
      It's a bit more than that. Function names are precisely encapsulation of the intent of the function. And unlike comments, function names are not subject to rot. Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)
      - computerphage 10y ago
        > function names are not subject to rot I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.
        douche 10y ago
        And thus it's important to also rename things when refactoring, or else you get awful confused when your Foobinator(x) function returns you a Splunkinated value, or your FrobbleTheFribbets() call also woggles the wiggles.
      - posterboy 10y ago
        >Function names are precisely encapsulation of the intent of the function that's a rosy way to say, names entail a message. An Address can also be computed, your argument is invalid.
- the_af 10y ago
  That's an extreme position. Function names are a valuable hint of what the function is supposed to do. But if the name doesn't match the implementation, which one is wrong? We don't know.
  - foota 10y ago
    But you do know something might be off, which is better than not knowing when something is off.
    - derefr 10y ago
      I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not rely blindly on either the implementation or the specification being correct, but instead check them both.
      - foota 10y ago
        In fact, I was reading about the bitcoin redemption vulnerability in stripe, and how often times security bugs are discovered by "huh, that's weird" rather than by eureka, and this ECC (error correcting code, see the pun?) seems like it would help to provoke that, and likely validates the amount of effort that it takes.
    - the_af 10y ago
      Fully agreed. That's why I consider descriptive identifiers a valuable hint.
  - lucb1e 10y ago
    > We don't know. I don't know about you but I certainly know that if a printLine function accidentally does something else, it's definitely the code that's wrong and not the function name.

choward 10y ago

Then why even name anything? Are you saying I should just name my functions and variables a, b, c, d, etc.?

eternalban 10y ago
Of course names are important to us, human programmers, but the compiler doesn't given an 'f'.
- posterboy 10y ago
  We use mnemonics, because we can't remember numbers as well, but to the compiler, addresses are pretty much like names.
  - eternalban 10y ago
    It's a bit more than that. Function names are precisely encapsulation of the intent of the function. And unlike comments, function names are not subject to rot. Also addresses are not like names. As with names in general, a name can refer to more than one object. (Consider modules, for example.)
    - computerphage 10y ago
      > function names are not subject to rot I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.
      - douche 10y ago
        And thus it's important to also rename things when refactoring, or else you get awful confused when your Foobinator(x) function returns you a Splunkinated value, or your FrobbleTheFribbets() call also woggles the wiggles.
    - posterboy 10y ago
      >Function names are precisely encapsulation of the intent of the function that's a rosy way to say, names entail a message. An Address can also be computed, your argument is invalid.
the_af 10y ago
That's an extreme position. Function names are a valuable hint of what the function is supposed to do. But if the name doesn't match the implementation, which one is wrong? We don't know.
- foota 10y ago
  But you do know something might be off, which is better than not knowing when something is off.
  - derefr 10y ago
    I was thinking the same from the root of this argument: "redundant encoding" isn't a way to automatically fix errors, but rather only a way to detect errors. Like a one-bit Error Correcting Code: the fact that the parity bit is wrong tells you something is corrupt, but it doesn't let you know what the right value should be. There's one useful thing you can avoid doing in response to such an error being detected: not rely blindly on either the implementation or the specification being correct, but instead check them both.
    - foota 10y ago
      In fact, I was reading about the bitcoin redemption vulnerability in stripe, and how often times security bugs are discovered by "huh, that's weird" rather than by eureka, and this ECC (error correcting code, see the pun?) seems like it would help to provoke that, and likely validates the amount of effort that it takes.
  - the_af 10y ago
    Fully agreed. That's why I consider descriptive identifiers a valuable hint.
- lucb1e 10y ago
  > We don't know. I don't know about you but I certainly know that if a printLine function accidentally does something else, it's definitely the code that's wrong and not the function name.