4 ms·

I don't like it when people treat #1 as an unbreakable rule. Sometimes it takes more than 25 lines of code for a function to complete it's one task. The book

I don't like it when people treat #1 as an unbreakable rule. Sometimes it takes more than 25 lines of code for a function to complete it's one task. The book "Code Complete" talks about this and has studies to back it up. Here's the quote from the book: From time to time, a complex algorithm will lead to a longer routine, and in those circumstances, the routine should be allowed to grow organically up to 100-200 lines. (A line is a noncomment, nonblank line of source code.) Decades of evidence say that routines of such length are no more error prone than shorter routines. Let issues such as depth of nesting, number of variables, and other complexity-related considerations dictate the length of the routine rather than imposing a length restriction per se. If you want to write routines longer than about 200 lines, be careful. None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you’re bound to run into an upper limit of understandability as you pass 200 lines of code.

DarkShikari 17y ago
And often a single routine is a sequence of--very many--but linear steps, one after another. Splitting the routine into 20 functions, one for each step, doesn't necessarily make it any more understandable: it reminds me of a DailyWTF in which a programmer was told to split a large routine into functions and just did something like this: doPart1() doPart2() doPart3() ... It's just as effective, if not better, to comment what each section of the large routine does. One advantage of keeping it in one routine is if there are dozens of values which are global to the routine and are not changed throughout it: it would create an ugly mess to pass those all around to each of the subroutines.
- eru 17y ago
  Though, when you can, you should split up those long linear routines. Especially when there are some variables global to the routine, but not all. The passing makes the shared variables explicit.
  - Daniel_Newby 17y ago
    That violates the DRY (don't repeat yourself) principle. Repeatedly entering the same parameter declarations is busy-work, wasting labor and valuable screen space. A better way is to use nested functions. Long-lived state goes in the outer function's variables, so you do not have to repeatedly declare them. Ephemeral variables go in the inner functions. Sub-tasks get encapsulated with zero boilerplate. If your language does not have nested functions, use a worker class. The algorithm-wide state goes in member variables, initialized from constructor parameters. The sub-tasks are methods. A benefit is that sub-tasks from different jobs can be batched to better use the instruction cache and branch prediction information: a.do_step_1(); b.do_step_1(); a.do_step_2(); b.do_step_2(); ...
    - eru 17y ago
      Yes, nested functions are probably good for this. (I was about to suggest use of the reader monad in the original comment, but then left out this suggestion for being to arcane (and did not include the nested function suggestion either).) Nested functions are good for this kind of code, even when they are only used once and do not abstract --- because you have less variables in the innermost scope. (And when you are going to mutate variables at all, then strongly prefer to do it to variables in the innermost scope.)

DarkShikari 17y ago

And often a single routine is a sequence of--very many--but linear steps, one after another. Splitting the routine into 20 functions, one for each step, doesn't necessarily make it any more understandable: it reminds me of a DailyWTF in which a programmer was told to split a large routine into functions and just did something like this: doPart1() doPart2() doPart3() ... It's just as effective, if not better, to comment what each section of the large routine does. One advantage of keeping it in one routine is if there are dozens of values which are global to the routine and are not changed throughout it: it would create an ugly mess to pass those all around to each of the subroutines.

eru 17y ago
Though, when you can, you should split up those long linear routines. Especially when there are some variables global to the routine, but not all. The passing makes the shared variables explicit.
- Daniel_Newby 17y ago
  That violates the DRY (don't repeat yourself) principle. Repeatedly entering the same parameter declarations is busy-work, wasting labor and valuable screen space. A better way is to use nested functions. Long-lived state goes in the outer function's variables, so you do not have to repeatedly declare them. Ephemeral variables go in the inner functions. Sub-tasks get encapsulated with zero boilerplate. If your language does not have nested functions, use a worker class. The algorithm-wide state goes in member variables, initialized from constructor parameters. The sub-tasks are methods. A benefit is that sub-tasks from different jobs can be batched to better use the instruction cache and branch prediction information: a.do_step_1(); b.do_step_1(); a.do_step_2(); b.do_step_2(); ...
  - eru 17y ago
    Yes, nested functions are probably good for this. (I was about to suggest use of the reader monad in the original comment, but then left out this suggestion for being to arcane (and did not include the nested function suggestion either).) Nested functions are good for this kind of code, even when they are only used once and do not abstract --- because you have less variables in the innermost scope. (And when you are going to mutate variables at all, then strongly prefer to do it to variables in the innermost scope.)