3 ms·

I agree that good code is usually quite easy to read and shouldn't requires big efforts of the reviewer. When I need to read some functions 2-3 times to underst

by d0m 16y ago

I agree that good code is usually quite easy to read and shouldn't requires big efforts of the reviewer. When I need to read some functions 2-3 times to understand it.. or when I need to switch from a "calm/boring" attitude to a "crap, I really need to think hard" attitude, it's usually a sign that it wasn't well written. It's not necessarily "bad code" but more of a sign that the programmer didn't reread himself to make sure it was clear. Anyway, for me, the biggest hint for a bad code is big functions. It's somewhat really counterintuitive and I can't understand why people still continue to write like this. And worst, they sparse comments to separate the different sections of the function.. gasp

btilly 16y ago
For decades the received wisdom among good programmers has been that long functions are inherently non-maintainable. However the actual result of companies that track maintenance information is that if the function is below 200 lines, the length of functions is not significantly correlated with maintenance cost. (However a high density of logic within the function is associated with maintenance cost.) Read Code Complete if you don't believe me.
- dasil003 16y ago
  In general I find myself writing short functions because modern programming languages and libraries are powerful and there is not a lot of busy work. That said, if there is a lot to do and little opportunity for re-use, I have no problem with long functions. The primary criteria for creating functions should be clear interfaces that minimize abstraction leakage.
- thomasz 16y ago
  I don't have that book at hand right now. I wonder if language plays a role here. Judging from my own experience, a 200 line stored procedure is quite manageable, but 200 lines written in a c-like language are a tough nut to crack.
  - btilly 16y ago
    I believe that code bases in C were studied. As long as the number of ifs, loops, etc was small, the length of the function did not hurt maintainability. However in this does result in language differences. In practice the density of ifs, loops, etc tends to be higher in a C-like language than in a stored procedure. So the complexity of functions tends to go up. The research cited is, however, quite old and did not include any OO code. Method dispatch can hide an implicit "if", and I don't know whether that tends to affect the maintainability of code in practice.
    - AgentConundrum 16y ago
      As long as the number of ifs, loops, etc was small, the length of the function did not hurt maintainability. http://en.wikipedia.org/wiki/Cyclomatic_complexity http://en.wikipedia.org/wiki/Cyclomatic_complexity

by d0m 16y ago

btilly 16y ago

For decades the received wisdom among good programmers has been that long functions are inherently non-maintainable. However the actual result of companies that track maintenance information is that if the function is below 200 lines, the length of functions is not significantly correlated with maintenance cost. (However a high density of logic within the function is associated with maintenance cost.) Read Code Complete if you don't believe me.

dasil003 16y ago
In general I find myself writing short functions because modern programming languages and libraries are powerful and there is not a lot of busy work. That said, if there is a lot to do and little opportunity for re-use, I have no problem with long functions. The primary criteria for creating functions should be clear interfaces that minimize abstraction leakage.
thomasz 16y ago
I don't have that book at hand right now. I wonder if language plays a role here. Judging from my own experience, a 200 line stored procedure is quite manageable, but 200 lines written in a c-like language are a tough nut to crack.
- btilly 16y ago
  I believe that code bases in C were studied. As long as the number of ifs, loops, etc was small, the length of the function did not hurt maintainability. However in this does result in language differences. In practice the density of ifs, loops, etc tends to be higher in a C-like language than in a stored procedure. So the complexity of functions tends to go up. The research cited is, however, quite old and did not include any OO code. Method dispatch can hide an implicit "if", and I don't know whether that tends to affect the maintainability of code in practice.
  - AgentConundrum 16y ago
    As long as the number of ifs, loops, etc was small, the length of the function did not hurt maintainability. http://en.wikipedia.org/wiki/Cyclomatic_complexity http://en.wikipedia.org/wiki/Cyclomatic_complexity