I believe all programmers found themselves caught in this situation at least once… the dreadful “spaghetti mess” where you’ve lost track of logical flow in your code and you’re doubtful that your final output will be accurate, you’re also getting increasingly frustrated with working on the code because A is no longer A, but looks like B.
As with anything else in life, if you fail to plan, you plan to fail.
Relax, you have a few weapons in your arsenal:
- System Architecture
- Configuration
- Conventions & less magic
- OO programming is your friend
- Globals are your enemy
System Architecture:
I would almost always suggest MVC and a popular MVC framework like Zend Framework, CakePHP, Yii etc. cause these already solves the architectural problem.
If you really don’t want to use any framework then I would suggest the following:
Read up on Systems architecture and specifically Design patterns
Configuration:
Configuration values must load at system startup, it doesn’t matter if your configuration values are in a file or database… most importantly, values contained in the configuration storage must be unique to avoid the duplication problem.
Conventions & less magic:
Name your classes, variables, etc. based on the module that it’s directly related to as well as it’s functions i.e. Class Orders, Method Orders::Invoice().
A function or method should never work on global values, but should only be responsible for doing 1 task and return a value, or void()…. If you call $Orders->createInvoice(); then you would expect it to do only that, NOT to also email the invoice in the background (which you won’t be aware of).
If you want to email the invoice you should have to call it explicitly, $Orders->createInvoice()->sendInvoice();
If you are extending the Orders class into something else, then be sure to name it appropriately, i.e. class Orders_YellowBranch extends Orders, this way you’ll know that on line 5023 of your code this class works only on the YellowBranch orders – no confusion.
Why less magic? Let your code be obvious, as soon as classes etc. gets too magical it become a nightmare to trace and debug, again the function or method must do what its name suggest…$Orders->createAndSendMailAndDeleteRecord(), and that’s all it should be doing!
OO (Object Orientated) programming is your friend:
Its quite amazing that there are still advocates for non-OO programming today, people who believe they can build rock solid systems using only procedural practices and static functions.
If you are writing a simple 1 page script then perhaps yes, but this is hardly ever the real-world scenario.
When using objects (classes) correctly they give us an automatic namespace which helps with the code logic and human readability as well, they can also be extended where the child class can inherit all members from the parent class and define additional members/methods i.e. Car class inherits from Vehicle class and can define additional methods like, sunroof, colour, or override engine to v8.
Globals are your enemy:
I guess most programmers today will already be familiar with the Globals problem.
For example, your application includes about 6 scripts in order to render the final “Orders total” page, each of these included scripts in turn also defines some global variables and also works on previously defined global variables.
Now in your main script you are calculating the Product total plus (+) Shipping amount and cannot get the right Total amount… perhaps script 2 is altering this variable, or is it script 5 unsetting this variable?
It becomes a nightmare trying to trace the flow of events and where exactly things are going wrong.
In PHP there is also a global array called $_REQUEST, this array will contain $_POST, $_GET & $_COOKIE.
Imagine the following scenario:
if($auth->isValid( $_REQUEST[‘user_id’]) {
or
if($auth->isValid( $_POST[‘user_id’]) {
When using the global $_REQUEST how would you know for a fact that you are getting the correct user_id?, as you might already have user_id in $_COOKIE or $_GET, but it’s different to the one you are explicitly expecting in $_POST.
