You can pick your friends and you can pick your code, but you can’t pick your friends code.
I said that to Michelle as we were walking from WordCamp Minneapolis, kind of as a joke, but then she looked at me and said how appropriate that was.
Sometimes the people we like and rely on code things in ways we think are a little insane. Here are the things that make me sigh a lot when I look at the code. They’re not always bad, but they do make me wonder what people were thinking.
Hidden
Someone wrote a plugin where the options were called via a base64_decode()
from a compressed storage:
#default settings code $options = '1VtPj-smEP8qKz2pt0qJs5vs7ju29_bQS08WtolD1zYp4M3mPfW7F2yDwWAPPK0q9erMj_nDzDAzEPSaHbLX7_x1n73-9HdPxdeK8GuD7nlDazp--cpfd9OP5sPz9EFR5T1r1in3O5v0Ripx2SDe28QXTOqLiKWWUuSXaoP6caYmXR4huV7-jN5JSTuA-mn6wgUp3-4x6z-HEdtanAIgyKohRqBx9ZcO3_Irw2fyEcFBETeowE1O3zFjpMIRG6JAgrT4ihmhMTuIOtTcpS48L-kmB_2l7...';
At the risk of sounding like the US government, there’s no reason to hide your public code. Knock it off. It’s public. Hide the service code if you must. Keep your serviceware code on your own data. But hiding code someone can download and decrypt? No, you’re shady.
Nesting
The plugin basically was one thing: add_filter('show_admin_bar', '__return_false');
But the plugin setup was /hide-admin-bar/hide-admin-bar.php
which included a file /lib/bar-settings.php
which in turn included /lib/false.php
Three files. One line of code. Why? Why!?
Inconsistant
I don’t mean tabs vs spaces. I mean with names. Like having add_menu_myplugin()
and myplugin_settings()
and then sanitize_myplugin_value()
and finally double_check_myplugin()
— Sure they all have ‘myplugin’ in there, but they don’t have any rhyme or reason to the names.
Names should be consistent and descriptive. A good function name should tell you what the function does.
Echo
I see this one a lot. People using ‘echo’ on every line in a function call in order to output their results.
$my_count = $whatever->my_count; echo '<h2>Hello World</h2>'; echo '<p>This is a cool thing!</p>'; echo '<p>This is even more cool. This is '.$my_count.' times cool</p>'; echo '<p>Ain\'t this cool too? But I have to escape my apostrophes.</p>';
Besides the fact that it looks ugly, it’s created more ‘data’ in your code. There are easier ways around this and ones that are more readable.
What Do You Think Is Bad?
And remember, we’re not talking about code that’s outright wrong, we’re talking about the things that work and are right, but make you cry “Why!?!” like Nancy Kerrigan.
Comments
2 responses to “Bad Code”
Well, indeed, this is really a pain when you came across code like these. Those affixes for “myplugin” could have just been copied on a tutorial online and utilize as its plugin functions. I did fixed an issue with one of my clients’ application wherein a commercial plugin has these type of code and conflicts with another plugin that utilizes the same affix “myplugin”. I was deeply shocked for a commercial plugin to have this type of mistake.
Honestly, I did made these type of issue before my early years of coding but I have realized its not sustainable and friendly to other developers as well. Naming the function with its core functionality is the way to go. π
@Defrothew: We ALL made those mistakes π
I don’t mind when a rookie with their first plugin does it. I head-desk when it’s a freaking development company. I mean… That actually scares me!