PHP Lessons to my 16-year old self.

Over the past five days I’ve turned a sketch for a Basenotes March Madness site into a real, working application, and did it with efficiency, normalization and security in mind. Web design was something I started messing with when I was about 10 or 11 years old, with a little 64-page book that actually gave a good understanding of the basics. Though I don’t need to consult that book I still keep it around, maybe I’ll find some young nerd to pass it along to although quite a bit of it is deprecated code now. It wasn’t until 18 and in college that I learned C and subsequently PHP, and really got a feel for the database design that had always intrigued me. I’ve had several projects of varying scales, and picked up a significant bag of tricks. If I could go back and get my 16 year old self to do all the stuff he wanted to do, I’d have these words of wisdom for him.

• Go pick up a copy of The C Programming Language. Forget about Perl, C will get you where you want to be.
• MySQL is much, much easier to get started with than Oracle, and forget about ColdFusion, it’ll be dead soon.
• JavaScript is sometimes a necessary evil. It can do things that are either way too cumbersome or flat-out impossible any other way. But don’t worry, JavaScript is becoming respectable.
• Keep all your code from old projects. You’ll be amazed how much wheel reinvention you’ll save yourself when the time comes to implement a login system again.
• All those ideas you’ve had in your head? You need to use $_POST[] and $_GET[] to make them work. That’s how you send data from page to page. GET is only useful if you only care about one variable, you’ll find yourself using POST much more often.
• Normalize your databases. If you’re storing the same data in two places, consider the best way to eliminate that redundancy. This is the cornerstone of relational databases and something you’ve got to master. You can and will make tables whose whole existence are to join two tables together via commonly used data. This is desired and much faster performance-wise. Use unique identifiers for each row, even if you think all your data will be unique; then when you need data you only have to carry that one ID with you as data flows.
• Comment your code, even if it’s after the fact. The longer you’re at it, the more you evolve and adapt different styles to do tasks, and when you look at some of your earliest code you can find yourself going, “What the hell was I trying to do here?” On the same note, try and use an identical approach to commonly used functions. For example, you’ll make a lot of MySQL queries, so using the same approach each time will instantly let you know as you scan your code that that block is a query.
  $q_selectfrags = "SELECT * FROM Fragrance WHERE (Gender = ".$gender." OR Gender = 2) AND House = '".$house."' ORDER BY Fragrance ASC";
$selectfrags = mysql_query($q_selectfrags,$conn) or die(mysql_error());
if ($selectfrags) { do $stuff; }
• On a related note, there are several ways to do loops (that is, returning a list of data), and while a do-while loop appears the easiest, and for loops are a bit more elegant, when you’re iterating through data a very efficient way of doing it is send your query, and then use while($row = mysql_fetch_assoc($result)) { blah blah, echo $row[‘Username’]; }. It’ll do it once for every row of data returned. Instant pro.
• Keep related functions and actions in one physical file, set your forms with action=””, and give your submits unique names. Then you have whole functions that only execute if ($_POST[‘submitname’]) { }. Fewer files to keep updated has it’s advantages, but one disadvantage is if your code is sloppy, you break a whole set of functions instead of just one. So don’t be sloppy.
• Use variable names that are descriptive enough that if you return to your code in six months, you can still tell what’s going on. $i, $j and $k are fine when you’re doing math problems for homework, but in a professional environment it just reeks of poor team skills. Others are going to be reading what you code, so go easy on them.
• Tables really aren’t that hard to learn, you pretty much just use the tr tag to specify a new row, and then td tags inside for each column within that row. Use the colspan attribute to stretch across multiple columns. This is also handy way to organize that info you’re spitting out with your while loop.
• Those paper sketches you’re doing are not going anywhere soon. There are design programs like Visio but there’s nothing as useful as sketching it out by hand, and the relationships between tables in your databases. If you can sketch it, you can code it, every single time.
• Be patient, but be creative. If you want to try designing something, go for it. It’s all useful practice for a real-world skill that can make you a lot of money.
• Listen to more Juno Reactor. It helps.