Re: [PHP] Many Small Files or Larger Utility Files
- Date: Tue, 21 Jun 2016 18:52:39 +0200
- From: Christoph Becker <cmbecker69@xxxxxx>
- Subject: Re: [PHP] Many Small Files or Larger Utility Files
On 21.06.2016 at 15:57, Larry Garfield wrote:
> 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.
That depends on the length of the function. I've seen functions
consisting of several hundred lines, and heard about even longer
functions. I don't recommend this coding style, though.
> 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.
Well said. :)
However, if there is no bytecode cache available on the production
system for whatever reason, it's still possible to merge all (or some
reasonable subsets of) classes into a single file (a few files) during
Christoph M. Becker
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php