Translate

Tuesday, May 19, 2015

Keep It Simple

This post is based on my experiences with a few functions that I wrote that started off working well, and handling the problem of repetitive code with dignity and grace. As time went on, and "features" were added to it, it became more trouble than it was worth. 

This is the lens through which I am going to write this post, however, it can apply to just about anything within software development where someone has a bright idea to make things easier, and takes it a bit too far. I am not attempting to demote innovation. I am simply giving advice for those who are looking to innovate, so that things don't get over-complicated. 

Without further ado, please enjoy. And don't forget to leave comments or share this with someone you know who may have found themselves in a similar situation.


How many times have you realized that you are rewriting similar database queries, or pasting similar code over and over, and come up with a brilliant idea:


"I'm going to write a function to do this for me! I will pass a few parameters, and it will make my life easier!" 

So you do just that! It works fine for a while, then you run into a query that requires a WHERE statement. So you pop in a few lines of logic and an optional parameter so that you can pass in WHERE options if need be. That works perfectly for a while, although it proves to be a little bit confusing, because you keep forgetting the order of parameters, and the optional one has to be last. But you get used to it.

Then you have a query that requires multiple checks. You need an 'AND' in your query.

That is all fine and good. You add another parameter to the function after the "where" parameter which allows you to add even more checks. Then you get the genius idea to make the "where" parameter an array instead of a string and loop through it, using "WHERE" for the first loop, and "AND" for each subsequent loop. It gets a little bit complex, and you fiddle with it for way longer than you planned to, until finally you get it working.

Now, you have to adjust to this new usage. It takes a little bit, and now when something goes wrong, instead of telling you where the error is, it now just says "line 98 in config.php" for any error relating to the entire function. That's not very useful. That is simply your call to the function. So it is a problem with the way the function was written, or is it a problem with your query?

So you end up using echo($query);die; in way more of your code than you would like. This goes on for a while, until you finally get used to it, and decide you can deal with the misinformed errors. After all, the error would lie in the execution of the query either way. Right? Either way, you shrug it off and move on. You work like this for a while, then get the genius idea to add the option to use prepared statements, because you have some user input to accept and want to be safe. Good for you! Being safe is a good plan!

So you find yourself jamming just one more feature into your messy, incomprehensible function, when it hits you...

Writing out the query, preparation, and execution of each database access would be SIMPLER than this rigmarole. 

So where does this leave you? Well, if you want to look at it negatively, you wasted your time.

However, you have now learned why you were the only one writing this kind of weird function. You have learned why people use open-source libraries to handle this kind of stuff in a "simpler" manner. You have learned that sometimes the shortcut isn't always going to get you there faster.

It's important to remember that libraries are supposed to make your life easier.  If you find yourself stumbling over your own feet, it might be time to re-think things a bit.

In this case Keep It Simple, Stupid is better advice than Don't Repeat Yourself.

Tuesday, May 12, 2015

Why You Should Avoid Dynamic Array Keys

Be extremely careful when assigning array keys dynamically, as you can get data overwrites if two items happen to have the same dynamically assigned value.

While this should probably go without saying, I found myself in this situation recently. I spent a good half hour scratching my head, trying to figure out why the value was correct, but the name was completely wrong. Finally, I realized that two items shared the same value, so the first was being overwritten. I felt I should document the problem on here so that other developers may hopefully keep it in mind when developing dynamic arrays.


Take for example the following array in PHP:

$list = array(
  $item1 => 'Breakfast',
  $item2 => 'Lunch',
  $item3 => 'Dinner'
);


All is good assuming you eat different things for each meal. For example, if you have the following variables:

$item1 = "Cereal";
$item2 = "Salad";
$item3 = "Steak";

Your array will look as such:


array (size=3)
  'Cereal' => string 'Breakfast' (length=9)
  'Salad' => string 'Lunch' (length=5)
  'Steak' => string 'Dinner' (length=6)


But what happens if you are on a budget that month, and have cereal for dinner, too?

$item1 = "Cereal";
$item2 = "Salad";
$item3 = "Cereal";


You end up with:


array (size=2)
  'Cereal' => string 'Dinner' (length=6)
  'Salad' => string 'Lunch' (length=5)


Uh oh. That's no good. 


It's really best to not use dynamic keys, as much as possible. This array can easily be changed to the following without causing any significant changes in the way your code would need to access it.

$list = array(
  'Breakfast' => $item1,
  'Lunch' => $item2,
  'Dinner' => $item3
);