9

When it comes to line length, Google's Closure Linter, Prettier, etc recommend not exceeding 80 characters per line.

Can anyone recommend the max number of lines per file?

I think most would consider a file with 100 pages of code, or 1000 lines to be too large

Improve this question
5
  • Your example is incongruent with the question. Your question asks about lines per file and your example is characters per line. Commented Oct 29, 2011 at 21:23
  • 2
    It's the same concept - the square area you have to scroll around, whether that's horizontal or vertical. Commented Oct 29, 2011 at 22:39
  • Other than exceptional circumstances, 1000 lines is excessive. Commented Jan 28 at 14:45
  • Coming back to this, I think "7 pages" is about the max. The reason being, many editors have a minimap (sublime text iirc) or even just a rich scroll bar (vscode), where once you go past a certain point, the minimap is going to be too imprecise to be helpful. We could similarly pick another number, but I personally would vote for 7. Commented Feb 6 at 17:10
  • Nowadays, it's very easy to breakup code and files inside vscode. I often right click -> "Refactor.." -> "Move to a new file.." Commented Feb 6 at 17:10

6 Answers 6

Reset to default
13

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.

Improve this answer
4
  • This is the most helpful guideline, thank you so much! Commented Oct 30, 2011 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. Commented Aug 8, 2012 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) Commented Dec 4, 2014 at 17:28
  • 1
    @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. Commented Apr 19, 2017 at 2:30
10

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.

Improve this answer
3
  • 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 Commented Oct 29, 2011 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. Commented Jan 28, 2012 at 5:36
  • @ergosys I've actually come to love using prettier printWidth at a very low number. I'm using 65 cause I think people could complain if I try to go any lower. I feel it does improve readability and code quality. More indentation in frontend react components generally means you need to break it up into more components, and I feel this also applies to other non-ui code too. Commented Jan 11, 2022 at 23:22
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.

Improve this answer
1
  • I think this is the only fully correct answer here, although Oded more or less states the same thing. You can aim for method and file lengths but the primary considerations need to be stated first. You can't avoid implementing the necessary logic and that is the strongest determinant of the length of methods, and consequently modules. You may not find an avenue or reason to break up a class as it grows due to new requirements. You might see an artificial way to do it that increases the complexity but that would be counter productive, indicating why this is the correct answer. Commented Nov 13, 2023 at 6:44
4

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.

Improve this answer
2
  • 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'). Commented Oct 31, 2011 at 16:05
  • 1
    +1 just for pointing out 80 chars per line is ridiculous. And try to use git in such a way that you hardly ever have to do 3 way merges. Certainly don't set your daily workflow to target them! Commented Nov 13, 2023 at 6:36
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?

Improve this answer
2
  • Code should not require a tiny font big monitor setup, especially for group code reviews. Commented Oct 30, 2011 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? Commented Jun 25, 2017 at 5:51
2

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.

Improve this answer
1
  • 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. Commented Jul 19, 2013 at 17:52

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.