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
