Good limits for code refactoring

Question

What are your preferred limits for,

1. Lines per file
2. Lines per function
3. Nesting

Are there other effective guidelines for limiting / settings (i.e. large font size)? FYI, I code mostly in Python along with some C,Java,Ruby etc.

Edit: The reason I'm not asking about number of char columns is because 80 columns generally is the hard limit and unless it is a special case, is much less debatable than any other limits.

Answer 1

I like to see an entire method on the screen at once, and I like to fit an entire class (file) in my brain at once (meaning I can completely understand everything in it). This leads to fairly small classes.

To meet those restrictions, I am usually very careful about code duplication (virtually none allowed).

As for Nesting, I try to keep loops and ifs shallow enough to be simple, this often means testing for simple cases and returning wherever possible before hitting the meat of my method or extracting a bunch of code into a new method if necessary.

As far as runtime-nesting (how deeply calls are nested), I've never found that problematic.

Many people have line-length limitations but I'd rather have things formatted in a way that shows intention even if it gets a little long.

Oh, yeah, and parameter lists--bare minimum! At 4 I start to feel uncomfortable, any more and I give into the fact that my design is missing an object somewhere (because I find that with that many parameters some are usually related in a very intimate way)

Answer 2

See these questions.

• Is there a recommended number of lines of code per file?
• Best rule for maximum function size?
• if / while nestings… how much is too much?
• How many parameters are too many?

Answer 3

My rule of thumb is that every line should be completely visible without having to scroll sideways and every individual function should be completely visible without having to scroll up and down.

I don't typically "limit" myself to a certain number of lines in a file, because a lot of it could be whitespace or single curly braces (or long lines split up into two). Ever since I started using a framework to write my applications, my files have gotten shorter and shorter (a few hundred lines), so I like to try to keep everything in that range... but going over isn't going to ruin my day.

Answer 4

Hi.

I recommend that you do not worry too much about code metrics such as line numbers in itself, but much more what the lines are doing. And this is obvious.

A nice guideline that I've heard is, when you are nesting three brackets down, such as:

public void method() {
   nest-1
   {
      nest-2
      {
         /* Code that gets not only repeated, but refactored often since
            it's an important part of the system. You are more likely to change
            this section of the code, than the loop header. Therefore, if this
            becomes a function, your concentration could be centered there without
            distractions.
         */
      }
   }
}

then the code in "nest-2" could be refactored to be a function. "Nest" in this context could be anything, such as an anonymous function, a loop or anything that will re-indent you specification code.

Advantage is more-readable code, but watch out when using threads in UI development (talking in .NET and probably some others) where you should know which threads are calling which methods. We all hate nasty cross thread exceptions.

A metric for a method is for it to have a single and unique purpose in the system. This is again, as many others have said on this question, the DRY principle (Don't Repeat Yourself, if you haven't picked up a copy of 'The Pragmatic Programmer', I highly recommend it).

I won't say any numbers, such as limits, as they are matter of preference. 'Don't be a slave to formal methods' is what programmers refer to this issue sometimes. And simply, some programmers will give you different numbers and this will leave you not confused, but disappointed. That is their preference and their choice to which to they agree to stick to. And good, since everyone has got a style that defines their unique code tailoring skills.

Horizontally, I would try keep a limit. I believe that horizontally, decently-short code is the most enjoyable to read: I would like to hear what other people think. What sometimes bothers me is that some variables need a long name to distinguish themselves and name their true purpose, and this lengthens the line of code when a complex expression is required.

I would also avoid things like

var myVar = MyObject.ItsMethodThatReturnsAnObject().ThatSecondObjectsMethod();

That is a different type of nesting, where you can incur into many troubles I'll leave up to you to understand. 'Un-nest' this by giving MyObject an appropriate method that does the extra check.

Regarding the lines per function, I would first look at my spec document. What are the tasks of the software? They could all be a function, but at code time, dozens of mini-functions appear - this is why coding is not just a mechanical process in which a design is implemented, but is further design of your already existing sketch.

When you have a block of code that does A, B and then maybe C. Then to finalize and clean the return value it performs D. Sometimes it doesn't. Sometimes we put big comments on top of a block of code to describe what it's doing. Then another section. They do different things and deal with different variables. - To the thinking programmer this would pop up: "Those variables are visible in that other section, but that section should not just never see them, but never need them.". Separate that code into a function which will only ever see the parameters it needs. This is Shy Code. Best for unit testing. That is your ultimate metric.

Hope this helps.

Leo Bruzzaniti

PS. Those terms I've used are all from 'Pragmatic Programmer', I don't intend to sound at all like they are my invention.

Answer 5

Lines per file: <100 is great, <200 is good. Over 300, I start getting nervous.

Lines per method: As few as possible. More than about 20-30, I start getting nervous.

I try to keep my nesting to one level whenever possible. If I'm doing more than one level, my method is usually doing more than one thing. Beyond two, I start getting nervous.

The reason I try to keep around these limits is not just to follow some arbitrary limit - instead, when I go beyond these limits, it becomes more and more likely that my class or method is trying to do too many things.

Answer 6

Like sentences and skirts, functions and files should be long enough to cover the important parts, but no longer.

This is really a restatement of the Single Responsibility Principle : a function or method should do one thing and ideally at one level of abstraction; and a class or module (i.e. file) handle one cohesive set of functions -- and no more.

Answer 7

I don't have preferred limits. I think about what I am doing, and it just seems natural to hit Enter here, or create new file there, or some other key to move a class to a new file, etc. Without thinking, I tend towards the lower-end.

On nesting, I don't have a set limit either, but the lower the better. Refactoring to methods, breaking/continuing/returning quickly, or using LINQ helps alleviate "Arrow Code".