At first, I loved it – I loved the brevity that the code allowed, and I loved how being able to write slightly less verbose code felt whenever I was working on part of a program. Being able to drop out certain operators made things so much easier.
Or so I thought.
Dynamically Typed Languages
Granted, there’s a lot that could be said about this, and there are far better, longer, and more articulate articles about this very topic than I could hope to share.
I’m not going down that road.
“WordPress Made Me Do It!”
Instead, I’d rather just share a couple of things that I’ve begun doing as it relates to writing more verbose code in the dynamically typed languages that contribute to working on and working with WordPress.
The main point of all my doing this is writing cleaner, more readable, more maintainable code. For whatever reason, there is this idea that if code is too verbose, then there’s something wrong with it.
Sure, I’m all for elegant code, but in six to 12 months from now, when I – along with a team of others – have contributed to a codebase, I want to make sure I know exactly what was meant by any given comparison, conditional, or what have you.
But this isn’t new. Straight from the WordPress Codex:
In general, readability is more important than cleverness or brevity.
And that should be the end of it, but for anyone who’s read (and/or written) enough WordPress-based code, then you know our tendencies are to lean into the direction of cleverness, brevity, or some mixture between the true.
I think it’s a natural tendency of all programmers.
So here are a handful of some of the things I’ve begun doing to help to try to make my code more readable, maintainable, and – honestly – even less clever.
1. Verbose Comparisons
When it comes to comparing the result of what a function returns in order to make a decision, I always compare to to the actual type that it should return.
- This means that boolean results are always compared to `TRUE` or `FALSE` rather than truthy or falsy values (like 0, 1, an empty string, or so on).
- If a function is going to return a number, then I will pass it to `is_numeric` first to make sure I’m not getting the string representation. If there’s still a problem with this comparison, then I’ll take a peek at what’s going on with the function returning the data (assuming I have access to it).
- `trim()` all the strings before performing a `strlen`
These are obviously not all of the things that can be done – just a short list of some of the things I’ve begun to make part of my day-to-day code.
2. Variable Initializing
Whenever I initialize variables, I make sure to initialize then to the empty type that they will eventually assume throughout a function.
I’ll talk a little bit more about this in the next section, but for now:
- Strings are initialized to empty strings
- Numbers are initialized to 0 (or -1 depending on some cases)
- Booleans are initialized to `FALSE`
- Objects are initialized to `NULL` (or an instance of the object upon instantiation)
- …and so on
This ensures that as I’m going back through my code, I’m not assigned something to the variable that wasn’t intended to be assigned.
No, we don’t have the luxury of strict type checking by the compiler, but that’s where variable naming conventions also come into play.
3. Hungarian Notation
I know people hate hungarian notation especially within the context of dynamically typed languages, but I’ve generally been a fan of it.
It allows you to glean a lot of information just by reading the variable name.
- Anything that begins with `$str_` is going to be a string.
- Anything that begins with `$b_` or `$is_` or `$has_` or a similar tense usually denotes something being true or false.
- Anything that begins with `$i_` or `$f_` or `$num_` or `$int_` is going to represent a number or a floating point.
You get the idea.
As you’re reading through code and you’re a few lines into a function, this can help you to discern what should be being set and what should be returned.
On top of that, if you follow this convention when specifying the parameters that a function accepts, it can help clarify exactly what type of variables the function expects to work on such that you minimize latent side effects.
4. Triple Equals
This goes hand-in-hand with strict comparisons, but the short of it that I’ve almost always used `===` and `!==` in JavScript, but I’ve recently begun doing this within PHP, too.
Combining this with turning on PHP notices, warnings, and other debug tools can go a long way into helping to make sure that you’re truly comparing data of the same type rather than letting the interpreter trying to guess.
What Do You Do?
Again, these are just a couple of quick notes as to some of the things I’ve begun doing as I work more regularly with dynamically typed languages.
There’s always more to add, and I’m sure code snippets and gists will begin to show this stuff more in future posts, but I’m always up for what you guys are going, too – so let me know your thoughts (even if you’re not a fan).