How many lines of PHP code is too many for one file?

Question

I'm creating a PHP file that does 2 mysql database calls and the rest of the script is if statements for things like file_exists and other simple variables. I have about 2000 lines of code in this file so far.

Is it better practice to include a separate file if a statement is true; or simply type the code directly in the if statement itself?

Is their a maximum number of lines of code for a single file that should be adhered to with PHP?

Answer 1

Do you need to focus on the number of lines? No, not necessarily. Just make sure your code is organized, efficient, and not unnecessarily verbose.

Answer 2

2000 lines of code in a single file is not exactly bad from a computer point of view but in most situations is probably avoidable, take a look into the MVC design pattern, it'll help you to better organize your code.

Also, bear in mind that including (a lot of) files will slow down the execution of your code.

Answer 3

It really doesn't matter, so long as you have documented your code properly, modularised as much as possible, and checked for any inefficiencies. You may well have a 10,000 line file. Although I usually split at around 500-1000 for each section of an application.

Answer 4

You may want to read a book like Clean Code by Bob Martin. Here are a few nuggets from that book:

• A class should have one responsibility
• A function should do one thing and do it well

With PHP, if you aren't using the Class approach; you're going to run into duplication problems. Do yourself a favor and do some reading on the subject; it'll save you a lot more time in extending and maintenance.

Answer 5

I would say there should not be any performance issue related to the number of lines in your php files, it can be as big as you need.

Now, for the patterns and best practices, I would say that you have to judge by yourself, I saw many well organized files of several thousand lines and a lot of actually small and difficult to read files. My advise would be:

• Judge the readability of the source code, always organize it well.
• It's important to have a logical separation to some extent, if your file does both: heavy database access, writing, modification, html rendering, ajax and so on.. You may want to separate things or use object oriented approach.
• Always search the balance between the logical separation and code. It should not be messy nor extra-neat with a lot of 10-line files

Answer 6

Line count is not a good indicator of performance. Make sure that your code is organized efficiently, divided into logical classes or blocks and that you don't combine unrelated code into single modules.

One of the problems with a language like PHP is that, barring some creative caching, every line of every included file must be tokenized, zipped through a parse tree and turned into meaningful instructions every time the hosting page is requested. Compiled platforms like .NET and Java do not suffer from this performance killer.

Also, since one of the other posters mentioned MVC as a way to keep files short: good code organization is a function of experience and common sense and is in no way tied to any particular pattern or architecture. MVC is interesting, but isn't a solution to this problem.

Answer 7

2k lines sound too much to me... Though it depends what code style you are following, e.g. many linebreaks, many little functions or good api-contract comments can increase the size though they are good practice. Also good code formatting can increase lines.

Regarding PHP it would be good to know: Is it 2k lines with just one class or just one big include with non-OOP PHP code? Is it mixed with template statements and programm logic (like I find often in PHP code)?

Usually I don't count these lines, when to split. They just went into habits. If code gets confusing I react and refactor. Still having looked into some code we as a team wrote recently, I can see some patterns:

• extract function/method if size is bigger than 20LOC (without comments) and usage of if/else clauses
• extract to another class if size >200-300LOC
• extract to another package/folder if artifacts >10

Still it depends what the kind of code I have. For instance if loads of logic is involved (if/else/switch/for), the LOC per function decreases. If there is hardly any logic involved (simple stupid one-path code statements) the limits increase. In the end the most-important rule is: Would a human understand the code. Will she/he be able to read it well.

Answer 8

I don't know any useful way to split code that's that simple, particularly if it all belongs together semantically.

It is probably more interesting to think about whether you can eliminate some of the code by refactoring. For example, if you often use a particular combination of checks with slightly different variables, it might help to outsource the combination of checks into a function and call it wherever appropriate.
I remember seeing a project once that was well-written for the most part, but it had a problem of that kind. For example, the code for parsing its configuration file was duplicated like this:

if (file_exists("configfile")) {
  /* tons of code here */
} else if (file_exists("/etc/configfile")) {
  /* almost the same code again */
}

That's an extreme example but you get the idea.