How do you write good PHP code without the use of a framework?

Question

Other than standard OO concepts, what are some other strategies that allow for producing good, clean PHP code when a framework is not being used?

Answer 1

Stay away from globals as best as possible :-D

Answer 2

make sure to follow standard practices of separation of concerns. What this means is try not to mix you business and data layer with your UI.

Answer 3

Really this question is quite language agnostic, as it applies to most languages where you choose to "roll your own". Two suggestions I would make would be :

Firstly, just because you aren't using a framework doesn't mean you can't adopt the patterns for segregating code. The MVC pattern is the minimum you should consider when arranging you source code - it makes for a much cleaner and easier to maintain collection of source code, even if the application doesn't entirely follow the routing processes associated with frameworks, having code that "does" things separated out from that which "represents" things is very beneficial.

Secondly, just because you've chosen not to use a full framework, doesn't mean you need to reinvent the wheel. Utilise pre-packaged libraries sensibly in order to solve a specific problems. Two good examples would be a logging framework (log4php) and a front-end rendering/templating solution (Smarty).

Answer 4

I'd say pretty much the same as for any other language:

• Don't optimise prematurely
• Keep methods small
• Practise DRY
• Practise data-driven programming
• Use sensible shortcuts (e.g. tertiary operator)
• Format your code well so that it can be understood by others
• Don't use OO blindly
• Always check return codes for errors
• Enable the highest warning level and ensure your code doesn't produce any warnings
• Be very careful when it comes to typing issues (this goes for all weakly-typed languages). The '===' operator is your friend.

Answer 5

Even If you don't use a framework, use a template engine. By using templates, you'll seperate the logic and presentation of your application. Then design, code and format the logic part like what you would do with any other language. Make the "designers" design the user interface :)

Answer 6

OO is not strictly necessary: it was possible to write good code in PHP < 5 too. Good procedural code, well separated into files and directories by 'logical distance' should also keep you safe. Notice, though, how this starts resembling OO from afar.

Best thing would be to be consistent: I've seen a project where Smarty was used in most pages except one -the most complex, go figure-.

Answer 7

If you really do follow OO concepts, like separation of concerns, your code will be pretty good, but here are a few suggestions:

• Framework or not, use MVC.
• I can't stress enough how important it is to never mix your logic with your HTML. In an HTML file, PHP should be used only as a template language and nothing more.
• Use a DBAL.
• Separate your design from your content. A common method for doing this is using CSS heavily and having header and footer files containing the bulk of site layout.
• Have a single file for option constants, like DB credentials, FTP credentials, etc.

Answer 8

I know this is a question, not an answer, but will you provide some details of why you would opt not to use a framework? I mean, in order to produce good code, you're going to be more or less rolling your own custom framework anyway. I'm curious to hear your reasoning.

Answer 9

Take advantage of PHP's in-built extensions - MySQLi for example. As these become more object-oriented the requirement for frameworks becomes less.

For example, I could create a useful TwitterApp by using the following extensions and no actual framework besides a core class to tie instances together.

• MySQLi for database (PDO if you need DAL)
• SimpleXML for RSS/API reading
• Smarty for templating

I might need to make a few helper classes for things like Login but my usual pair of classes (DAL and TPL) are made obsolete by two very well worked extensions.

Answer 10

Remember: MVC, OOP and tiers are design concepts, not language constructs, nor file-structuring.

For me, this means that when not using a framework, and when there's not different teams for programming and designing; there's no value in using another template system on top of PHP (which is a template language). Also, separating code from layout doesn't necessarily mean doing it on different files.

This is how i used to do for one-off, seldom expanded, PHP web apps:

1. write a 'general utilities' file, there i put some formatting/sanitising functions, as well as a few DB access functions:
   1. getquery(): given a SQL, returns a result object
   2. getrecord(): given a SQL, returns a record object (and closes the query)
   3. getdatum(): given a SQL, returns a single field (and closes the query)
2. put all configurations (DB access, some URL prefixes, etc) on a 'config.php' file
3. write a model layer, either one file, or one for each object you store on DB. There, will be all the SQL constants, present a higher-level API, based on your conceptual objects, not on DB records.

that's your 'framework', then you write the 'presentation' layer:

1. one PHP file for each page, starts with some simple code to fetch the objects needed, followed by HTML with interspeced PHP code, just to 'fill in the holes'. with very few exceptions, the most complex code there should be for loops. I make a rule to use only one-liners, the ?> should be in the same line as the opening <?php

2. each data-entry form should point to a small PHP without any HTML, that simply get's the POST data, enters into the DB, and forwards to the calling page.

and that's it. If working alone, it has all the separation of intents you need, without drowning in a lot of files for a single user action. Each page as seen by the user is managed by a single PHP file.

It's even easy to maintain, after a few months without looking at the code, since it's easy to test the app, taking note of the filenames in the URL field of the browser. This guides you directly to the relevant code.

(nowadays, of course, i'm using Django for almost everything...)