many include files vs one large include file

Question

The company I work for is in the process of completely overhauling our current intranet site by moving it onto a Drupal framework. One area I am questioning is the number of include files we have. As it exists right now, every single .php page has a corresponding .inc page. There are .inc pages that provide certain functionality, but aren't tied to a specific page. However, each .php page includes multiple files - at a minimum, it will load the .inc page corresponding to it, and a few general scripts. This makes trying to find a function definition a nightmare when debugging.

My options right now seem to be the following:

1)Keep using this same system, but make it part of our convention to include a commented line stating where the function is defined 2) Consolidate all the include files into one large file. This would include class definitions, function definitions, everything. My concern here is that this file would get monolithic in a real big hurry. However, it would have the advantage of keeping all function definitions in one place.

I don't like either option to be honest. My goal is to reduce dependencies and make our code readable and easy to navigate. What is our best method to handle this problem?

I should also state that this is very much legacy code - it hasn't been refactored since it was created in 2003-2004. Just to give you an idea what I'm working with, there is a lot of php echoing html:

printf("<center>\n");
printf("<table>\n");
printf("<tr>\n");
printf("<td align=left>Select Division:</td>\n");
printf("<td><select name=\"div\">\n");
printf("  <option value=1 \"selected\">Division1\n");
printf("  <option value=2>Division2\n");
printf("</select></td>\n");
printf("</tr>\n");
printf("<tr>\n");
printf("<td align=center colspan=2><input type=\"submit\" value=\"Next->\"></td>\n");
printf("</tr>\n");
printf("</table>\n");
printf("</center>\n");

Answer 1

tl;dr it's not many include files vs one large file, it's the Drupal way.

Since you want to move onto Drupal, I'd suggest you go with it for real. Here is how Drupal works.

First, in Drupal, the only folder you can touch is sites/.

In sites/default, basically you only touch the settings.php file. Most of your time will be spent in sites/all/. In this folder, there are 2: themes and modules. Your theme will be where you guess it, and the modules (contributed, or yours) will be where you guess it too.

I won't write a tutorial about how to write themes. Basically, you have all your templates in your theme, and the modules use these templates. The big advantage is that you can override the templates used by other modules (which you shouldn't touch either) including the core ones.

Drupal separates modules by features. You, for your own website, usually separate your modules by business features.

I'm not going to write a tutorial about how to write modules, but here is how it basically works:

Your module needs a .module file. Let's say your module is foo. So you have in folder in sites/all/modules/foo/. In there, you have a file named foo.info (with basic information), and another file named foo.module. In the foo.module file, you have this kind of stuff:

function foo_menu() {
    $items['bar'] = array(
        'title' => 'Some title',
        'page callback' => 'foo_answer_bar',
    );
    return $items;
}

function foo_answer_bar() {
    return 'Baz';
}

The principle is to have functions starting with your module name, and ending with specific names, such as _menu. These functions are picked up by Drupal and it handles them. In this example, the returned array tells Drupal to handle the /bar URL, and to display what the foo_answer_bar returns, in the layout.

Anyway. I'm not going further in this example, but what I'm saying is that if you go with Drupal, go with the Drupal way. It will be a little hard in the beginning, but a lot less painful in the long way. Try to keep many small modules rather one big module. The same rules as OOP apply there (SOLID, KISS, DRY).

Answer 2

Because you're using Drupal, you cannot do things the PHP Way, which is probably more correct than the Drupal Way.

Drupal has conventions and limitations. It can make life very difficult if you do not follow those conventions, but if you do follow those conventions then it can be an okay system.

My recommendations are as follows:

1. Ditch Drupal if you can. There are far better systems out there, without all the incredible limitations that Drupal has. Drupal is a great system for people who aren't very good programmers, but for people used to writing OOP applications in PHP it will make them tear their hair out.

2. If you can't ditch Drupal, then do things the way Drupal wants you to. In particular, Drupal likes files separated into the directories where it expects to find them - theming, library, database access, and logic files all have a place. In addition, this will make your life much easier when you decide you may want to add namespaces, or if you want to be able to have more discerning includes later in because the include-everything paradigm is making your site slow.

Answer 3

Merging the PHP files into one will only provide a minor performance improvement, if any, especially with APC installed or with PHP 5.5's optimizer. Drupal's primary PHP performance flaw is its global functional layout and the fact that hundreds or thousands of function calls are required for each page. I recall Zend or another organization did a thorough analysis a while back.

If you're using Drupal, do not modify the core by merging PHP files or any other changes. That would make future upgrades and patches incredibly difficult. Instead write your modules as efficiently as possible and focus on other performance improvements, like caching and page rendering.

Answer 4

Perhaps the original structure is the result of someone designing the software like a set of C++ classes?

The problem that you have of finding function definitions sounds like a combination of your IDE missing a "go to definition" feature, and the functions not being grouped together in the places that you'd expect. So a third solution would be to regroup the functions to obey some more predictable placement rule.

Of the two options you've given, the first sounds like it would take a lot of discipline, and the second sounds like tossing away benefits from modularity.

Answer 5

I would convert that to a class-based system and separate the HTML templates and PHP code.