Welcome! Log In Create A New Profile

Advanced

[PHP] Many Small Files or Larger Utility Files

Posted by Stephen 
Stephen
[PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
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.

--
Stephen

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Unknown Business
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
I do the same - for the create, register, and forgot functions it all gets
processed in the same file.

On Mon, Jun 20, 2016 at 9:49 PM, Stephen <stephen-d@rogers.com> 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.
>
> --
> Stephen
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Per Jessen
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
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.

I recently investigated a performance problem for a customer. He was
using a CMS written in PHP, perfectly fine, but requests took much too
long to serve. In the end I determined that each request needed to
read some 200 files which took 600ms on a single-user machine, somewhat
longer in the shared, redundant environment.

I would not call "small, single function, files" the best practice, but
how you manage your project is mostly up to you.


--
Per Jessen, Zürich (15.5°C)
http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Adam Jon Richardson
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
Hi Stephen,

There are a lot of considerations. If you're adopting a more functional
approach, certainly files can contain lots functions, perhaps grouped
within a class as static methods to take advantage of PHP's autoloading
capabilities. I don't worry about the size of file in this case, but I do
work hard to make sure the functions are related. This helps me find and
use things later.

If you're following an OOP paradigm, then you usually try to break the code
up into classes, trying to limit classes so the have a single
responsibility. Again, while you can put more than one class in a file,
making use of autoloading is simplified by limiting to one class per a
file. When I've programmed using Objective C, I've noticed my classes get
pretty big (as this seems to be more common in these libraries), but I tend
to make my Python and PHP classes smaller.

As Per Jessen noted in his reply, I've also seen performance issues with
code bases that are broken up in such a manner that each request requires
including many files. If it's other people's code, I sometimes even analyze
the call stack for includes and then preprocess the files that are used on
most requests into one file (using a bash script, simple parser, etc.)

The one hard rule I try to follow regarding files is that I keep side
effects isolated from function/class/etc. This is probably more due to my
appreciation for Haskell, but I'm thankful it's listed in PHP-FIG, to:
http://www.php-fig.org/psr/psr-1/#2-3-side-effects

Enjoy,

Adam


On Mon, Jun 20, 2016 at 3:49 PM, Stephen <stephen-d@rogers.com> 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.
>
> --
> Stephen
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Larry Garfield
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
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
Christoph Becker
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
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
build time.

--
Christoph M. Becker


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
On 06/21/2016 11:52 AM, Christoph Becker wrote:
> On 21.06.2016 at 15:57, Larry Garfield wrote:
>
>> 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.

As have I, and I run screaming from it, too. :-)

>
>> 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
> build time.

True, but in what situation would you not have an opcode cache available
that is not one of:

1) Your PHP version is so out of date you may as well give up, because
it's already insecure.
2) Your webhost is so terrible that the best thing you can do for your
app is to get a new webhost.

An opcode cache should just be assumed on any modern PHP installation;
if it's not there, there are other, much larger problems to resolve first.

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Christoph Becker
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
On 21.06.2016 at 20:26, Larry Garfield wrote:

> On 06/21/2016 11:52 AM, Christoph Becker wrote:
>
>> 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
>> build time.
>
> True, but in what situation would you not have an opcode cache available
> that is not one of:
>
> 1) Your PHP version is so out of date you may as well give up, because
> it's already insecure.
> 2) Your webhost is so terrible that the best thing you can do for your
> app is to get a new webhost.

Indeed, that's what I would think of, too. However, consider off the
shelf applications. These can either require recent PHP versions
including the availability of certain extensions/features (such as
bytecode caches), or not. If they do, they risk either loosing parts of
their user base ("I don't want to upgrade my cheap webhost contract;
I'll rather switch to another software."), or, even worse, some users
won't update to new versions, and that might fall back on the software
developers/supporters (more "bug" reports, bad reputation if yet another
XYZ site has been hacked).

Of course, in an ideal world there would be no issue, but in practise,
there is. See, for instance, Wordpress, which still runs on PHP
5.2.4+[1]. The recommendation to use PHP 5.6+, is only, well, a
recommendation, which is likely to be ignored by some users at least.
While WordPress could easily enforce PHP 5.6+, the developers don't do
that, quite likely due to the reasons mentioned above.

I dislike to be restricted to old PHP versions, but I also dislike all
those support requests like:

Q: after upgrading to the new version, I'm getting a blank screen
A: please enable debug mode
Q: I get "Parse error: syntax error, unexpected T_FUNCTION …"
A: <del>RTFM</del>
you have to upgrade to PHP 5.3+ as described in the manual

According to w3techs.com there are still ~10% PHP 5.2 installations out
there, and PHP 5.5+ is available only on ~30% of servers.[2] That
matches my personal experience. Sad, but true.

[1] https://wordpress.org/about/requirements/
[2] https://w3techs.com/technologies/details/pl-php/5/all

--
Christoph M. Becker

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Larry Garfield
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
On 06/22/2016 06:38 AM, Christoph Becker wrote:
> On 21.06.2016 at 20:26, Larry Garfield wrote:
>
>> On 06/21/2016 11:52 AM, Christoph Becker wrote:
>>
>>> 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
>>> build time.
>> True, but in what situation would you not have an opcode cache available
>> that is not one of:
>>
>> 1) Your PHP version is so out of date you may as well give up, because
>> it's already insecure.
>> 2) Your webhost is so terrible that the best thing you can do for your
>> app is to get a new webhost.
> Indeed, that's what I would think of, too. However, consider off the
> shelf applications. These can either require recent PHP versions
> including the availability of certain extensions/features (such as
> bytecode caches), or not. If they do, they risk either loosing parts of
> their user base ("I don't want to upgrade my cheap webhost contract;
> I'll rather switch to another software."), or, even worse, some users
> won't update to new versions, and that might fall back on the software
> developers/supporters (more "bug" reports, bad reputation if yet another
> XYZ site has been hacked).
>
> Of course, in an ideal world there would be no issue, but in practise,
> there is. See, for instance, Wordpress, which still runs on PHP
> 5.2.4+[1]. The recommendation to use PHP 5.6+, is only, well, a
> recommendation, which is likely to be ignored by some users at least.
> While WordPress could easily enforce PHP 5.6+, the developers don't do
> that, quite likely due to the reasons mentioned above.
>
> I dislike to be restricted to old PHP versions, but I also dislike all
> those support requests like:
>
> Q: after upgrading to the new version, I'm getting a blank screen
> A: please enable debug mode
> Q: I get "Parse error: syntax error, unexpected T_FUNCTION …"
> A: <del>RTFM</del>
> you have to upgrade to PHP 5.3+ as described in the manual
>
> According to w3techs.com there are still ~10% PHP 5.2 installations out
> there, and PHP 5.5+ is available only on ~30% of servers.[2] That
> matches my personal experience. Sad, but true.
>
> [1] https://wordpress.org/about/requirements/
> [2] https://w3techs.com/technologies/details/pl-php/5/all

Indeed, I am intimately familiar with the chicken-and-egg PHP upgrade
problem; Back in 2007 I ran the GoPHP5 project, which is what finally
broke the logjam and killed off PHP 4.

However, the situation is somewhat different today than it was then.
Container-based hosts that make it easier to opt-in to a newer PHP
version are readily-available. The bumpiness of the ride in upgrading
is FAR less than it has ever been in PHP history. (PHP 7 is slightly
bumpy, but not much, and 5.4->5.6 is nearly unnoticeable.) An
increasing number of PHP projects are doing the right thing and
requiring new versions; Wordpress is, I think, the only project of note
that doesn't require PHP 5.5 in its most recent version (and Wordpress
does run just fine on PHP 7, too). See the recently published stats on
Composer (which measure package requirements, not found-servers):

https://seld.be/notes/php-versions-stats-2016-1-edition

Those look a lot better than the W3Techs stats. (Lies, damned lies, and
statistics.)

In any case, the OP was talking about newly written code that he's
writing, not a legacy application it sounds like. If you're writing
something new, today, there is *no* excuse to not target 5.5 or later;
any reason you can come up with I would argue is an example of "fire
your manager and/or sysadmin for being negligent." Frankly anything
written new today should be PHP 7+.

And someone sweating about the performance impact of having many include
files should upgrade to PHP 7 before they even ask the question; a PHP 7
upgrade is *the* number one thing you can do for the performance of your
PHP app these days. (At least for things affecting PHP itself; sticking
Varnish in front of your app is also a very good idea, etc.)

Disclaimer: I work for one of the aforementioned cloud hosting companies
(Platform.sh); we offer PHP 5.4, 5.5, 5.6, and 7.0, switchable via one
line of YAML, and most of our "starter kits" now default to PHP 7. End
disclaimer/commercial. :-)

--Larry Garfield

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Gener Badenas
Re: [PHP] Many Small Files or Larger Utility Files
December 13, 2016 05:41AM
On Tue, Jun 21, 2016 at 3:49 AM, Stephen <stephen-d@rogers.com> 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.
>

I think multiple files is more manage-able than having large file.
cache/accelerator could help, but it seems your prod server don't have
one. How about just write using multiple files, but have a script
somewhere that merge all of them in a single file before uploading to
server?

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


--
Code http://grails.asia/groovy-list-contains code
http://grails.asia/groovy-create-list
Sorry, only registered users may post in this forum.

Click here to login