Another 7 deadly sins for PHP

Defines for configuration

Well, in principle this does not sound like such a bad idea. Coming from a C background, it's pretty much the only way to do things, without doing some huge layer.

Unfortunately with PHP once you go beyond a few lines of code, the classic problem arises, "Where was that set", or even worse "Which bit of code changed that"

I've used defines like this (DataObjects uses a define to turn off the overloading for buggy versions of PHP4) - but that is only there because it's something that is needed at compile time, and not at runtime. So there was no clean way to use settings that are specific to that class prior to it being loaded.

All configuration variables in almost every application I write now are set in the index.php file, why? you may ask. Well when you start looking at an application, what's the first file you look at. - yes. index.php, it all starts there..

Other that a few minor things like setting include_path, (yes, you can do that, and it get's rid of alot of stupid reasons for defines) the only thing index.php does is call the 'app runner' with all the config variables. Each nicely grouped by package.

This is a reasonable simple index.php (or bootstraper from FlexySvn) - the concept being that you have to rename the example file to index.php

http://www.akbkhome.com/svn/akpear/FlexySvn/svn.php

if you look through the application code, it uses PEAR::getStaticProperties() to retrieve the config.

In summary it manages to solve a number of issues

• not depending on the class to be loaded to set the config

• not using a global variable (that may be overwritten, or is difficult to find how it came about.

• easy to find out where config variables are being used.. - or incorrectly used..

• easy to detect if some part of the code is accidentally changing variables (& on the same as the getStaticProperties.

• easy to find and read.

• Re-uses an existing bit of code that pretty much has to be loaded anyway.

BTW, I do not recommend using this bootstrap file for documenting all the possible options. - add a note about where to find that information. The standard index.php (or example bootstrapper) should be just enough for the user to get the basic application up and going. - without sifting through 30 pages of possible configuration.)

Directory Layouts

What's the difference between a good directory layout and a bad one?

Basically directory layout's for code have a few purposes

• to make it easier for anyone maintaining the code to find a specific bit of code

• Segmenting code into modules (for different distribution, or preventing overlapping or similar features)

• mmh.. Nothing else!!!

So if your directory structure uses java.endless.name.format, Then half the directory structure is just a pointless empty directory that makes navigationing and locating the code time consuming and annoying.

PEAR's standard was thought through and has proven simple, yet successfull for so long now, that it's just amazing that people even have to think about making up a new standard.

class Aaaa_Bbbb_Cccc goes in Aaaa/Bbbb/Cccc.php

Yeap, that's about it.. Since you dont have a file with a list of Functions, or if there is any data files, it's only used by a package, and hence the file ends up as a subdirectory of that package, Pretty much everything is easy to find, and easy to spot if something is out of place.

Filenaming

Well, what so wrong about .inc, .class.php, .myending,

• .inc, .myending etc. have a number of problems, first of all once you have realized that they are PHP code, and your editor has also picked this up so the highlighting and auto-completion work properly. You then have to worry about you web server picking them up and not serving them up as text - revealing your inner most secrets to anyone at google..

• .class.php, well what's the point! do you have files called func.php, data.php, tpl.php, no, well probably because your classes follow the PEAR standard and your functions do not exist, and your data and templates are in directories called data and template... This get's especially worse if for some reason you can not avoid having a classname ThisReallyLongInterfaceAddonName.class.php - while not recommended on the rare occasion that you could not think of anyway around this, you just added 6 characters to the file name, just because you thought it was cool... - it's not! - and it makes the .php dissapear of the end of the tree if you have a tree browser in your editor..

That's it - php files, end in .php (only), templates are end in .html (so that nvu/dreamwever can pick them up.), images end in .jpg/.gif/.png and javascript ends in .js

Dont fall for the 'Not created here' idea.

Yes, we all love the 'Not created here' idea, I tried that code in PEAR, but I could not get it to work, So I'll start from scratch and see if I can write some code that does the same, but does not have a 6 year history of bug fixes and user contributed features.

Think about it, the core stuff has been done 100 times, and there are a few places that you can look to find them.

• PEAR (well not a supprise here as I've been contributing for so long)

• Zend (not sure about this - do they actually distribute PART's rather than one big 'do it this way ball')

• Very few other places.. (do not mention CakePHP - it's does not solve the problems below)

• PHP classes - if you can stand the noise / authentication / licensing crap ? (haven't used this for a long time so these may be out of date)

Why so few, well, you need to watch out for:

• Do the parts work without the downloading a huge dependency blob of code - can you normally just download and keep updated a single class or group of classes?

• Do they follow standards

• Do they have a bug tracker, a specific maintainer, and a parent group that can help sort out if the maintainers disappeared off the place of the planet (or you want to volunteer to help or take over)

• Can you replace or just keep one part maintained by you? (a prime example is the old XML Tree code in PEAR, that got a BC issue many years ago, rather than re-writing code to meet the new specification, budget wise, for an application that rarely changes and uses this a minor part of it's code, having the ability to override the 'pear' version with a modified copy of the original, without confusing the packaging system. saves alot of time and money...

Don't be afraid to give up on a library after using it for a while. - Smarty for all it's maintainers and hoohar, can be a pig's ear to write for, and maintain. It gives you too much power, which should never really go into a template engine. Keep it simple (where possible) is a good rule for libraries...

If your code is public, you should try not to ridicule yourself.

On the rare occasion we interview people, one thing we like to see is examples of code they have written, (open source code is usually a great way to evaluate them). Taking a certain amount of pride in their work makes the difference between a candidate who get's offered a better package, that a candidate who just get's the basic one. Other than the things listed here there are a few other telltale signs that someone can solve problems cleaner and tighter than others. A great one is when you see a huge blob of code that basically does

$a = $something_a

$b = $something_b

$c = $something_c

.....

$z = $something_z

This kind of either assignment or function call repeated in a similar context over and over again, smacks of code that should have been typed about halfway through, and the engineer thought.. mmh... this is a bit dumb, let's see if I can tidy it up a bit... - So it would probably never have seen the repo, or even the save button..

Part of this is also making you code readable. Not just for others, but for yourself, Some of us older guys still have to look after code we wrote 6 or more years ago. The good stuff has some comments and some structure to it. The bad stuff is usually the one where you wish you had time to recode it because it's a pain to work on and you dread every bug report for it. So making code readable (comments in sensible places, helping you understand the point of a block of code ) come in really handy later.

Other little things like using Capital letters for your variables tends to be a good warning sign, PHP uses case sensitive variable names, and all the super globals are called $_BIGLETTERS - so it's quite easy to read some code and see what data is coming from outside. When you start adding your own variables to this mixture, you dilute that advantages that that readability gives you...

Functional Crap (or Procedural code)

PHP has functions, and Classes, Classes for some are a black magic or just too difficult to understand.... Or as some old wives have said 'OOP code in PHP is slow' ... well, I think that one died a death years ago.

The reality is that you can not write a application that is bigger than one or two files without starting to use objects. Why? well, you very quickly come into the problem of 'what does "uses('xxx')" do, and why is it not working correctly.

So every time you find a bug in that code, (which can be every 6 months or so) you end up trying to hunt down a tree of activity in many different files, and spend your time learning the ins and outs of Grep.

Procedural code has it's place, for localized functions in Javascript, and D it's invaluable, you can restrict the scope to within a method, and you are rarely fubling around trying to work out what the code is trying to do. But PHP generally throws functions into the global namespace, and temps you like a bad mistress to come and play with them when ever you are getting bored when coding..

I once said to someone, even if you dont understand objects, just using Static methods, and calling them rather than functions would make life alot easier in the long run. The only downside is that they started writing classes like Util:: ???? and putting every function on earth in there.... - Well some people will never learn.

Mixing PHP and HTML

Well this is so 1999 (well 2000 really as that's when php4 came out), but everyone still inists on doing it. Stop, it just makes your code complete jiberish. You cant see what it was trying to do, let alone what it is really doing.

The fundamental problem with this approach is that outputting anything before you are certian that you can fetch all the required data for the page, results in half rendered pages, and hidden error messages or horrific kludgy workarounds..

If you can determine if there is a problem before you start rendering a page (outputting HTML), you can then decide how to handle it correctly - display the form again, display a problem with the database message etc...

I have a feeling this has probably repeated my 7 deadly sins post from a few years back... but hey, why write once what somebody else has already written before (even if it's yourself)...