It’s not always effective to tell a new programmer what to do. There are so many potential projects they could take on, so many different paths, and different people are interested & adept at different things. But from more than a decade of experience at making mistakes, I think I can help php programmers identify and really understand some mistakes that they will make. If, on some day in the distant future, you know all the mistakes that you will avoid while programming, all that’s left is the open green field of creating the project that you want, the way you want it. Until then, let’s really dig into the mistakes, and get to know them. We’ll be seeing them a lot.
This is not yet a “guide”, but I wanted to touch on a few mistakes that I see all the time, and have done myself at least once, and learned from. First off, here is a very broadly applicable one:
Don’t let your languages touch each-other! Try to keep your html in separate files from your php, keep your sql in a separate section from any pure php, keep your css & js both in separate files, or at a bare minimum in prototype code; in a complete separate section. To separate your php from your html, use templates/a template engine.
PHP & the Database:
Don’t let naked sql strings touch your sql! Write prepared statements using PDO. Everything else is dangerous! Prepared statements allow you to put complex, even dangerous user-generated data, into the database and have it be fully escaped & go in just as it appears. This will help protect against sql injection, the worst problem with newbie php code. Intro to PDO here: http://www.phpro.org/tutorials/Introduction-to-PHP-PDO.html#7.1
- Don’t write your html in your php. Instead, use a template engine, like the “smarty templating engine” or “twig template engine” to keep your html in totally separate files.
- Don’t write unescaped php variables into your html, unless you -know- you need it. Escape everything php in html until you know you have to create some dynamic html in your html, and then make damn sure you know what will be created.
- Don’t write feature code first! Write tests of what you want your code to do before you write the code, so that you can run the tests and see if your code works. And then modify or add more tests, and run again. That’s called Test-Driven-Design.
- Don’t write code that does too much/is too complex. Short functions & short methods are best. Test-Driven-Design will help keep your code simple.
- Code you write today will break a week from now. Write tests so that you know when it breaks and where. Write comments so you know why you did it in the first place.
- Don’t write your own authentication code! Use someone else’s open source library first so that you can get to know how things should be done. Brrr, you don’t want to know what happens if you go down this road yourself.
Code that is just in a flat file is dead code. Add a feature, save the file, and then realize that you broke something important on a live system, and you don’t have the history to to roll back your change.
Don’t keep your code on just one hard-drive. Your hard-drive will fail. Your hard-drive is failing right now. We all die, and hard drives die When that spinning disk finally grinds to a halt, or that solid state …. …material… …cells… …finally stops allowing reads, do you want to have lost a month’s worth of work, or an hour? You don’t get to choose whether your drives will fail [they will], only whether you have a copy elsewhere. This argument applies to cloning yourself as well, I guess.
Your time is precious, precious. And code is like highly concentrated bits of your time. It might take me an hour to write a page of prose. But it could easily take me 3 hours to write 50 lines of code.
More subtle/less impactful mistakes to understand
Don’t rely on browsers to be the same. Different browsers have different default css, it’s a pain. Use normalize.css to give you a solid, cross-browser base.
Don’t use your own css to start. Try twitter bootstrap and then modify it to fit your own needs. You’ll learn some good stuff from it that you can use on your own later.
Don’t use <table>s for layout. You’ll end up writing 3x or 5x the amount of html, and it’ll be much harder to style with css. Use block level elements to replace it where possible. I’m not going to lie, it’s often harder to get the css to do what you want than use a table, but googlebot won’t hate you, and your html pages will be smaller and leaner. <table> should actually be reserved for tabular sets of related data these days (data for a graph, or a grid of prices, or a table of people with their ages, for example).
Don’t use <div> unless you considered the other elements first. It’s easy with complex or dynamic code to fall into letting the code create lots of nested <div>s, especially before the new html5 elements, but browsers will be able to handle issues more gracefully if you start using other elements (<section>, <article>, <nav>, <p>, <aside>, <header>, <footer>, etc) and use <div> or <span> only if nothing else was more appropriate.
Ok, so I’ve written a lot up there, and you and I know that it’s the practical, code-based experiences of these mistakes that will really help. Well, that’s coming, I’m working on code that you can help break, code that will help break you (…in to php programming), on github. I’ll be linking it when I have it in place, so watch for it later.