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 defined2) 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);
many include files vs one large include file
php
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).