Web lists-archives.com

Re: [PHP] Many Small Files or Larger Utility Files




On 06/20/2016 02:49 PM, Stephen wrote:
I have made a number of web sites using PHP and mySQL. These included a control panel for adding and maintaining content.

I am stepping up and creating a site that will require sessions, private areas and user registration functions.

I have looked at samples and note that they all use many small files. I see that as being difficult to manage.

But I have also looked at the code for a PHP bulletin board. Many, many small files, so I see that it is a common practise. But I see it as complicated and difficult to manage.

For my control panel code I have all the routines, about 10, to process POSTS in one file. It works fine.

Now activity is low, but that will also be the case with my new site.

So my question: Is small, single function, files the best practise, or I am just fine in combing many functions into larger "library" files.

Thank you for your thoughts.

If you're using a mostly procedural code base, then clustering functions into manageable chunks makes sense. One function per file is ridiculous and unmanageable.

If you're using a mostly OOP code base, you want to be relying on an autoloader; the standard autoloader for PHP is one built on PSR-4, and most people/projects are using Composer which takes care of all of that for you. PSR-4 mandates one class per file, with a specific naming convention, to keep the autoloader logic as simple as possible. If you have an OOP code base, that is the only way I would recommend building your system.

That can result in lots of disk hits, that's true. If you're not using an Opcode cache, that can be a problem. If you are, then it's only a small problem. (And if you're not, it means you're using PHP < 5.5, which means an unsupported version with known security holes. UPGRADE NOW!) You can also set your opcode cache to not check the disk for file changes once it's parsed a file once, which can eliminate most (although not 100%) of the remaining overhead; certainly it will bring it into an acceptable cost, where you'd be better served worrying about your SQL queries than the autoloader.

The downside is that you will need to flush your opcode cache (usually by restarting the web server process) when you change code. For that reason, you'll probably do that only on production, where if you're updating code bouncing the web server is something you can/should do anyway. (Or even better, have a container-based deployment where you simply switch requests to a newly built container.)

Generally speaking, "class per file and don't sweat it" is the conventional approach, and what I'd recommend in most cases.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php