PHP Do's And Don't

[Steve M]

This is just a small list I have compiled from my experience of the do's and don't of PHP coding.

Do's:

• Always double check your code (Read More Below)
• Test, test, test, and then test again
• Gather tester's for heavy testing enviroments
• Keep backups of everything no matter how small a change (Read More Below)
• Ask for help if you need it or you are stuck

Don't:

• Assume your code is flawless
• Think your code is safe online or externally (Read More Below)
• Openly post your code to various places (Read More Below)
• Think you will have a bug free script/snippet
• Give up no matter how hard it seems
• Let others do the code for you (Read More Below)
• Reinvent the Wheel (Read More Below)

I am sure a few are asking about certain items above, let me explain them a bit more so everyone understands.

Always double check your code: Over the past 6 years I have been programming in PHP, something I learned a long time ago is to always double check my code. You can make a minor mistake, just a small keystroke such as ; or ' can easily break your code. Many developers find that double checking your code prevents this from happening but double checking your code also makes sure you are directing your queries, variables, etc to the right area.

Keep backups of everything no matter how small a change: When it comes to developing a huge script or even a small one, if you don't make a note of what you changed or make a backup of that file you take the chance of losing a lot of work or worse yet not knowing where you made the change that caused an error. Small changes sometimes can lead to big problems, so keeping a backup of what you change or an unchanged version of the file will prevent you from scratching your head or getting aggravated.

Think your code is safe online or externally: I have recently discovered that trusting an online source or even your own external hard drive can be a misplacement of trust. Online sources can have servers go down or worse yet hard drives go out causing loss of data. In some cases fires break out preventing any backup of data. External hard drives have a tendency to completely delete all data with no warning, as I have recently experienced. With this happening you lose everything unless your smart and create discs to backup everything on that external.

Openly post your code to various places: When posting your code to various places you take the chance of someone else seeing your code and stealing. This other person could easily then change it or do what they want to it then release it as their own. Sometimes they don't even change the code enough to tell the difference but how can you prove it was your code originally? Well something I have learned is you can make a signature in your code that is hidden to those in experienced in it. Signature's in code is new I'm sure to many but to those who know of it will tell you its easy, your basically hiding your signature in wide open space but no one notices it.

Let others do the code for you: Let's say you as a coder ask me to help out, you provide me the files and everything I need. I proceed to make changes and get it working, when you get the files back you have no idea what changes I made because I did not mark what I changed in the file, therefore if it breaks because of an error then you won't know what code is what causing you to delay fixes and in some cases, no fixes for a very long time.

Reinvent the Wheel: (Thank you Christopher) I think one of the biggest mistakes any developer can make (not specific to PHP) is reinventing the wheel. Database abstraction. Internationalization. Templating. Javascript. The list goes on and on.

One of the reasons PHP is such a great platform is because of the abundance of freely available software libraries at your disposal (Doctrine, Zend Framework, Twig, Swiftmailer, or for JS, jQuery, underscore etc). These libraries are almost always guaranteed to be better developed than your own replacements because of the community around them. They will be richer, better documented and better tested.

Focus on your own product and don't waste time reinventing peripherals.

I hope those reading have found this to be knowledgeable and make suggestions to add to the list. I want to provide a means for those new to PHP a way to avoid mistakes that us experience developers have made.

 

[Shawn Gossman]

Good article!

 

[Steve M]

Thanks, I wasn't looking at it as an article but guess it can be an article.

 

[Ryan Ashbrook]

Something I typically do, is I always make sure my objects have at least a constructor and destructor, even if they do nothing. I know it's there and I can just plugin a method or two in it that might need run on startup.

I also make sure all of my object methods have a return value. If a method is designed to just pull something and add it to the global scope, then I throw a return TRUE; at the end.

EDIT: Sorry, having coder relapse. Haven't coded at all today (been rebuilding my computer).

 

[Chroder]

I think one of the biggest mistakes any developer can make (not specific to PHP) is reinventing the wheel. Database abstraction. Internationalization. Templating. Javascript. The list goes on and on.

One of the reasons PHP is such a great platform is because of the abundance of freely available software libraries at your disposal (Doctrine, Zend Framework, Twig, Swiftmailer, or for JS, jQuery, underscore etc). These libraries are almost always guaranteed to be better developed than your own replacements because of the community around them. They will be richer, better documented and better tested.

Focus on your own product and don't waste time reinventing peripherals.

 

[Steve M]

Thanks Christopher, I added it to the article as that seems very important to remember.

 

[marilyn]

thanx you

 

[rafalp]

I think one of the biggest mistakes any developer can make (not specific to PHP) is reinventing the wheel.

I tend to disagree. Frameworks are good tools when you dont have time or will to build your own foundation for application, but they are dont make "only real option" as people tend to represent.

I know people love to go with that "dont reinvent the wheel!" thing. Its true, but ask yourself... is every wheel the same? Can I take wheel from my bicycle and assemble it in my car? Or one of those bullet-trains that go at 350kliks per hour? No. "Reinventing wheel" means trying to find new usage for exsisting, extremly basic principle. Wheel can roll in one direction on more or less flat surface.

Frameworks are nothing else than ready wheels to put in your car. I want a car but I dont want to design my own wheels for it, I take exsisting wheels, like Symfony or Zend. I am building bullet train or martian rover? I design my own wheels to maximalise my project capabilities.

Also... I tried to find a ready wheel for myself and gived up. Some frameworks show me their authors have no idea what MVC is (and simply call their stuff "Model", "View" and "Controller"). Some equal Model to ORM, other produce stuff that does so ridiculous amount of processing on dumb things I have no idea if they writed it cos they want it to be used, or cos they want it to look good on screenies.

ALSO

There is other issue with people avoiding their own coding in favor of frameworks... experience. There is only one way to become good programmer: write lotsa and lotsa and losta code... different code. DB abstractions, Cache engines, Sessions, ACL, files, internationalisation, mails, everything. People who assume "screw it, ima go with framework" take easy way and leave themself with less experience.

They dont understand how something works, they have no idea how to make it better or worse because they gived it little attention themself. They also make most irritating type of coders out there to discuss improvements in your not-frameworked project, right after guys that want to write everything in MVC bout have no idea what MVC really is. They dont understand how stuff like cache or DB Abstraction or sessions or authorisation or autoloading works, so they cannot objectively judge your approach to things. But they know Frameworks are made by gods of php, so they jump on you with yadayada that your cude cannot be good and should be replaced with one from framework.

 

[Ryan Ashbrook]

The other major problem with Frameworks is Bugs.

If you've written your own Framework, and a Bug is found, you can just fix it and be on your merry way. With a Framework, you have to wait for a fix from the developers of the framework, then when they DO fix it, you have to add in the new version and do some crash course testing to fix incompatibilities that are likely to come in when you add the new framework version.

 

[Emi]

I like this. At first I thought it was only the bullets, till I scrolled down. I was like "Thanks for the uninformative post!", but I was wrong

 

[Hostpro-AdEx]

Great thread, thanks for the tips!

 

[meetdilip]

Ya, nice write up.

 

[s.molinari]

Thanks for the write up.

One thing I think is missing and is insanely important is documentation. I am surprised you missed it. It is probably because it is the chore nobody likes to do. Too many think it is a time waster, but overall, it isn't. Let me explain how I see it.

If a developer is involved in a larger project, before the first line of code is programmed, I feel the concepts and specifications must be laid out in written form first. Also, only when the programmer is part of the design team, should he be involved in the creation of concept and specification documentation. If he isn't involved in the design team, he shouldn't start to code until all of the documentation is clear enough for him to do his coding job. And THEN, he should document his code very well and (this is my own take), he should relate back to concept and specification documentation wherever he can within the code. "This class solves the spec paragraph 1.2 of concept document XYZ for the functionality ABC." If he can't relate back to documentation, he is creating something not spec'ed, which needs a spec.

That means, for instance, should there be a hitch in the specifications or concepts found while coding, (which means the spec'ing process needs some more work), then this needs to be corrected in the documentation too! Documentation is a constant process!

Why is all this necessary? Because coders/ programmers tend to speak a programming language very, very well and everyone else who doesn't code simply don't. If a programmer can't relate his work to "normal" language in some way, any way, it will more often than not be misunderstood or not understood at all. And more often than not, that creates an unnecessary and costly void between what was wanted and what is created. Best case, you end up with one or more very big WTF experiences by users. Worst case, you end up with a design that is totally off the wall and can't even be further developed, because it is a total dead end.

Also, the discussion about the concepts and specs before the programmer starts his coding is much, much cheaper than if he coded and while coding, develops concepts and specs. In other words, refactoring a paragraph or two in a document is much, much easier and much cheaper and much faster than refactoring any working code, especially if it is part of a larger project.

Documentation of the code itself is also just normal programming practice. It helps accountability. It helps with clarity. It helps with collaboration. It is a must, if you are going to consider yourself a professional programmer.

Ergo, the documentation of concepts, design concepts and specifications and of the code itself is extremely important for any programming project (not just in PHP). No programming should be done without it!

Scott

 

[Supermighty]

This is just a small list I have compiled from my experience of the do's and don't of PHP coding.
Keep backups of everything no matter how small a change: When it comes to developing a huge script or even a small one, if you don't make a note of what you changed or make a backup of that file you take the chance of losing a lot of work or worse yet not knowing where you made the change that caused an error. Small changes sometimes can lead to big problems, so keeping a backup of what you change or an unchanged version of the file will prevent you from scratching your head or getting aggravated.

Use Git or SVN for source code control. It's like a save-as history of every commited change you make.

Git also has intelligent merging and tools like bisect to specifically narrow down when bugs were introduced. Git also keeps sha1 hashes of commits which allows you to verify the source history and know exactly that the files on LIVE are identical to what was deployed. This is good for security peace of mind.

 

[Digital Doctor]

#1) Don't abandon your work.

 

[rafalp]

I dislike wide statements in engineering.

Its not something unheard of when solution is abandoned by its developers because it became obsolete solution.

...or its another attempt to bash vB, in which case I kindly ask you to keep this crap off meritorical discussion like this one.

 

[Supermighty]

There is time to abandon a project and there is a time to refactor, continuously improve, a project.

Why would you throw away a working forum just because it's build on old unsupported software. Why not setup a DEV server and being to improve the software, refactor, cut out dead code and add newer code. Eventually you'll end up with a completely different piece of software, but only after some time. And you never had to throw it away.

 

[s.molinari]

Not sure why you've specified a forum in your post, but how many forum owners can afford to refactor their software? I'd say not even a fraction of a percent, so refactoring old software hardly ever happens at the forum owner level.

What happens really? Forums migrate to a new software, which forms a much better foundation for their future. It isn't giving up. They simply change the software vendor.

And basically, on the refactoring decision, it is a very hard decision to either refactor a code base or start from scratch. There are many variables involved, but basically and IMHO, the smartest variables and the final decision involve how it impacts the customer/ user. Get it right and your decision to refactor or not is a good bet to be right too.

Scott

 

[Supermighty]

You are right, most people switch to a newer software. My ideas of refactoring come from the opinion of learning and DIY. I think if one wants a successful forum (any Web website really) it should be unique and have lots of custom programming.

 

[meetdilip]

You are right, most people switch to a newer software. My ideas of refactoring come from the opinion of learning and DIY. I think if one wants a successful forum (any Web website really) it should be unique and have lots of custom programming.

I humbly disagree. We can managed well without custom coding on a well established platform. Custom features are of course a bonus for members.