4 ms·

>> No real world code is simple and elegant enough that you don't >> need to think through the complex invariants of the code > Oh, please... sendDataWithTi

>> No real world code is simple and elegant enough that you don't >> need to think through the complex invariants of the code > Oh, please... sendDataWithTimeout(user_t *user, data_t *data, time_t timeout); What happens if delay is 0? Can user be NULL? What happens if it is NULL? How large can 'data' be? Is there a limit? Will the send be chunked into multiple dispatches if 'data' is too large? Is that opaque to the caller? Does it matter to the caller? If none of those questions are answered, the caller must delve into the sendDataWithTimeout() implementation to figure out the answers, and it is impossible to modify sendDataWithTimeout() without possibly breaking assumptions callers make based on what they've assumed from implementation of sendDataWithTimeout(). This applies equally well to blocks of code within a function that accept input and provide output. It helps to be able to reason about them as atomic units, without necessarily paying the code/maintenance cost of hoisting them into independent functions.

mbucc 14y ago
So, if the method was commented, would you: (A) assume the comments are correct and skip reading what the code does? (B) use comments as guidance and read code anyway? The first seems awfully risky to me and poor advice to any programmer trying to write solid code.
- flatline3 14y ago
  > (A) assume the comments are correct and skip reading what the code does? Yes, unless I was working on that particular piece of code. There's often far too much code in a code base to waste time reading it all, and reading the comments can provide quick understanding. > The first seems awfully risky to me and poor advice to any programmer trying to write solid code. Why? Bad code is bad code. Writing bad comments (or no comments) means you're writing bad code. Don't write bad code, and then write documentation to help yourself think through why it's not bad code, and tests to both help you think through it, and verify that it's not bad.
gnaritas 14y ago
> This applies equally well to blocks of code within a function that accept input and provide output. It helps to be able to reason about them as atomic units, without necessarily paying the code/maintenance cost of hoisting them into independent functions. This seems rather... crazy. Functions serve this purpose, avoiding creating function while still trying to think of your code block as a function is just absurd. Extract the function, if it deserves a comment and has parameters, and isn't an anonymous method for use with a higher order function, then make a real function out of instead of polluting the parent function with its implementation details. The overhead of this additional function you're so worried about is nothing compared to the overhead of the mess that results by not extracting it. Your strategy favors long functions, yuk yuk yuk. Listening to you talk, I'm horrified by the thought of what your code must look like; I bet your functions often require use of the scroll bar.
- flatline3 14y ago
  Functions for four lines of code is stupid when a simple one line comment would suffice.
  - gnaritas 14y ago
    No, it isn't; that's is precisely the purpose of a function and precisely the wrong way to comment.
    - flatline3 14y ago
      Given the mental and work effort necessary to hoist out a function versus writing a simple comment, I think your position involves untenable trade-offs. I'd much rather see code commenting the major steps of the function than a file riddled with tiny functions, all of which require breaking my train of thought, switching to a different section of the file to read, and then going back to the original function. That's ludicrous compared to a one-liner "Send our token to the server" comment on a small block of code.
      - 14y ago

mbucc 14y ago

So, if the method was commented, would you: (A) assume the comments are correct and skip reading what the code does? (B) use comments as guidance and read code anyway? The first seems awfully risky to me and poor advice to any programmer trying to write solid code.

flatline3 14y ago
> (A) assume the comments are correct and skip reading what the code does? Yes, unless I was working on that particular piece of code. There's often far too much code in a code base to waste time reading it all, and reading the comments can provide quick understanding. > The first seems awfully risky to me and poor advice to any programmer trying to write solid code. Why? Bad code is bad code. Writing bad comments (or no comments) means you're writing bad code. Don't write bad code, and then write documentation to help yourself think through why it's not bad code, and tests to both help you think through it, and verify that it's not bad.

gnaritas 14y ago

> This applies equally well to blocks of code within a function that accept input and provide output. It helps to be able to reason about them as atomic units, without necessarily paying the code/maintenance cost of hoisting them into independent functions. This seems rather... crazy. Functions serve this purpose, avoiding creating function while still trying to think of your code block as a function is just absurd. Extract the function, if it deserves a comment and has parameters, and isn't an anonymous method for use with a higher order function, then make a real function out of instead of polluting the parent function with its implementation details. The overhead of this additional function you're so worried about is nothing compared to the overhead of the mess that results by not extracting it. Your strategy favors long functions, yuk yuk yuk. Listening to you talk, I'm horrified by the thought of what your code must look like; I bet your functions often require use of the scroll bar.

flatline3 14y ago
Functions for four lines of code is stupid when a simple one line comment would suffice.
- gnaritas 14y ago
  No, it isn't; that's is precisely the purpose of a function and precisely the wrong way to comment.
  - flatline3 14y ago
    Given the mental and work effort necessary to hoist out a function versus writing a simple comment, I think your position involves untenable trade-offs. I'd much rather see code commenting the major steps of the function than a file riddled with tiny functions, all of which require breaking my train of thought, switching to a different section of the file to read, and then going back to the original function. That's ludicrous compared to a one-liner "Send our token to the server" comment on a small block of code.
    - 14y ago