4 ms·

I’ll take a 100 line commented function over one that delegates to a dozen other methods that aren’t used anywhere else. The more functions you add to the mix,

I’ll take a 100 line commented function over one that delegates to a dozen other methods that aren’t used anywhere else. The more functions you add to the mix, the less clear the logic becomes and the easier it gets to break things. Abstractions have their place, but the evolution of my 15 year career has led me to use them as a last resort when I find myself needing to copy code more than twice.

tuatoru 5y ago
To me, that's a procedure, not a function. It's a pity that so few of our programming languages distinguish between these two quite different concepts.
- newaccount74 5y ago
  What is the difference between a function and a procedure to you? I assume it's not just about whether something returns a value or not. The only language I use that differentiates between functions and procedures is PostgreSQL, and to be honest I find the distinction pretty annoying in practice. One can return values, the other can control transactions. So when refactoring code you sometimes need to make a function a procedure or vice versa and it's a pain. (As a consequence, I try to always use functions to make things easier)
  - __vim__ 5y ago
    Fortran distinguishes between the two as well.
notreallyserio 5y ago
I just don't understand how 100 lines comprising 10 or 20 functions in the same file (as in the cited example) is any different than 100 lines of a single function that does the same thing. Is it just that the former has one fewer tab per line? This is the sort of advice that can quickly become a thought terminator because the writer has so much authority.
- ajuc 5y ago
  The difference is that 1 big functions naturally encodes the ordering and dependencies between things that happen inside - because it's linear and has nested braces. 10 or 20 small functions with no nesting inside still has all the complexity, but none of the structure to help programmer understand it. Functions can be called in any order, any number of times, and you have to trace the full call-stack in your mind and keep it there to get the same understanding of what happens that you had just by looking at the linear code.
  - deleted 5y ago
    [deleted]
zemo 5y ago
The thing about "functions should be X lines long" is that an appropriate value for X differs substantially from industry to industry, language to language, and domain to domain. My game code (mostly C#/unity stuff) often has longer functions with more commenting, whereas my server code (Go stuff) has virtually none of this. I definitely write 100-line long functions with lots of commenting in C#. I never ever, ever do that in Go. Maybe I would if I was writing a game in Go, but for Go I'm writing servers, and I never ever wind up with code that looks that way in server code.

tuatoru 5y ago

To me, that's a procedure, not a function. It's a pity that so few of our programming languages distinguish between these two quite different concepts.

newaccount74 5y ago
What is the difference between a function and a procedure to you? I assume it's not just about whether something returns a value or not. The only language I use that differentiates between functions and procedures is PostgreSQL, and to be honest I find the distinction pretty annoying in practice. One can return values, the other can control transactions. So when refactoring code you sometimes need to make a function a procedure or vice versa and it's a pain. (As a consequence, I try to always use functions to make things easier)
- __vim__ 5y ago
  Fortran distinguishes between the two as well.

notreallyserio 5y ago

I just don't understand how 100 lines comprising 10 or 20 functions in the same file (as in the cited example) is any different than 100 lines of a single function that does the same thing. Is it just that the former has one fewer tab per line? This is the sort of advice that can quickly become a thought terminator because the writer has so much authority.

ajuc 5y ago
The difference is that 1 big functions naturally encodes the ordering and dependencies between things that happen inside - because it's linear and has nested braces. 10 or 20 small functions with no nesting inside still has all the complexity, but none of the structure to help programmer understand it. Functions can be called in any order, any number of times, and you have to trace the full call-stack in your mind and keep it there to get the same understanding of what happens that you had just by looking at the linear code.
- deleted 5y ago
  [deleted]

zemo 5y ago

The thing about "functions should be X lines long" is that an appropriate value for X differs substantially from industry to industry, language to language, and domain to domain. My game code (mostly C#/unity stuff) often has longer functions with more commenting, whereas my server code (Go stuff) has virtually none of this. I definitely write 100-line long functions with lots of commenting in C#. I never ever, ever do that in Go. Maybe I would if I was writing a game in Go, but for Go I'm writing servers, and I never ever wind up with code that looks that way in server code.