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.

closed as primarily opinion-based by gnat, user22815, user40980, durron597, Ixrec Sep 20 '15 at 18:53

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Your example is incongruent with the question. Your question asks about lines per file and your example is characters per line. – Jason S Oct 29 '11 at 21:23
  • 2
    It's the same concept - the square area you have to scroll around, whether that's horizontal or vertical. – Devin G Rhode Oct 29 '11 at 22:39

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.

  • This is the most helpful guideline, thank you so much! – Devin G Rhode Oct 30 '11 at 13:57
  • Is there a file length that's too short? I have a project with 35 files with an average length of ~200 lines. – Dan Aug 8 '12 at 23:22
  • 1
    @Dan I would venture "no" as the answer. If opening a file is too hard in your setup, it maybe time to improve your setup (ie vim plugins, better IDE, whatever emacs does) – Mike Graf Dec 4 '14 at 17:28
  • @Dan : Too short a file? Possible if you spend more time searching for the correct tiny file for a few LOC instead of finding them in some logically and closely related (but not too long) file. – hotpaw2 Apr 19 '17 at 2:30

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.

  • 5
    +1: It's good to keep lines less than 80 chars wide; easier to read and gives more room for side by side windows – Donal Fellows Oct 29 '11 at 19:49
  • 6
    Personally, I think readability suffers when a line is scrunched up into multiple lines to fit into 80 or less. There's also the time wasted deciding where to make the breaks, or arguing about it for that matter. – ergosys Jan 28 '12 at 5:36

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.


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?

  • Code should not require a tiny font big monitor setup, especially for group code reviews. – hotpaw2 Oct 30 '11 at 5:29
  • "Line length should be such that you do not have to scroll screen to see whole line." - what if your editor wraps? – Dan Dascalescu Jun 25 '17 at 5:51

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.

  • 1
    Absolutely. 80 characters means that you can print out a section of code for brainstorming at a reasonable font size on a portrait A4/Letter sheet. It also means that on a reasonable development computer monitor, you can view three copies of the source code side by side without horizontal scrolling for doing three-way merges (Funny that 80x8x3 is 1920 *8'). – Mark Booth Oct 31 '11 at 16:05

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.

  • I use 22" monitors flipped vertically, which gives me 1080 pixels across on each screen (and vertically, I can have 104 lines of code visible at a time!). Keeping line widths to 90 or less characters is helpful in scenarios like this. – Roy Tinker Jul 19 '13 at 17:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.