'Recommended' file length and line widths

Question

I was curious if anyone knew of a recommendation from a reputable source for the max number of lines of code for a given file. For example, Google's Closure Linter recommends that each line should not exceed 80 characters.

Answer 1

A file should be short enough that you can find any function or method without scrolling back and forth multiple times hunting for it, or having to remember a search string. The metric I use is the amount of time I spend looking for code within a file versus reading it. If that becomes noticeable, it's time to repartition the file or class.

A good size for a basic code block is short enough, both in width and height, that you can project the guts of it during a group code review, and have it all fit without the font being so small that the guy in the back of the conference room can't read it. This size also helps if you are ever called to explain some code when all you have with you is a mobile device or tablet.

Answer 2

There is no such thing, and if there was, it would be highly dependent on what language you were using (doing the same thing in assembler versus C# or Java for instance).

For the higher level languages, you can see this SO discussion. For Java/C#, 10-20 lines per method is what Bob Martin recommends as a maximum. There is no discussion regarding files, as it is not relevant and depends on what the class is supposed to do.

In regards to the 80 characters per line limit - this is a throwback to the days of punch cards. Having said that, when lines grow too long, readability suffers.

Answer 3

Line length should be such that you do not have to scroll screen to see whole line. That depends on monitor size and resolution.

Methods and functions are best if can fit one screen.

Files shouldn't be too long. The best are short files, where it is easy to understand the class, and the implementation.
Once I worked on a project that had a 10 klines file. It was like reading a very complex book. Do I need to tell how many problems that implementation caused?

Answer 4

I try to keep classes and methods short, but don't worry so much about line length. In these days of wide screens and long identifiers, I think eighty characters is far too few. It takes some work to break statements so they are easily read, and with an eighty character limit, it happens quite frequently. I think about 120 or 130 columns per line is more reasonable.

Answer 5

File and line lengths are measurements of secondary effects of complexity and as such are highly variable. What you should aim for is code without unnecessary complexity, not a certain maximum line count.

Long files tend to indicate that methods, subroutines or classes are overly complex (doing too many things, not sufficiently factored, etc)

Long lines tend to indicate that expressions are overly complex.

They are smells that indicate a potential code issue, not well defined target metrics.

Answer 6

80 characters!

I remember that I used to see source code files for billing programs about 80 pages and more when I did COBOL. Of course, I can't see that this is near common practice but 80 chars is equally ridiculous.

From a class size view, if you try to apply this suggestion on a typical Customer class that has about 80 properties and 20 methods or so, you will have to break the class into several other ones and make the code very messy indeed.