Help wanted naming this code
March 12, 2022Do you have a helpers or utils class or directory in your project? Maybe both? Quit it!
Show of hands.
How many of you have a library, class, or directory in your current project called
Bonus points if you have both!
Actually, bonus points if you have neither.
I don’t like this naming pattern, for a few reasons:
The name tells me nothing. Literally all code exists to help (otherwise it wouldn’t exist). And all code provides utility (otherwise it wouldn’t exist). So from a naming standpoint, we may as well call such a unit of code
whateveror… well, I’m sure you get the idea.
“Catch all” names like this tend to… catch all. That is, they tend to gather all sorts of random, unrelated things over time. This makes it difficult to find what you’re looking for, which leads to the next problem…
These names promote code duplication. When you can’t find a function that does your neat little thing, you create a new one in a local
helpersclass, without realizing that it does, indeed, already exist, in some other helpers class. Now you have the same, or nearly the same, functionality in two (or more) places…
It’s just kinda lazy. The same as naming a variable
xor a function
do(). I’m sure you can do better. What is the variable/function/class doing? Name it accordingly!
Regular Expressions Are the Best! s/Best/Worst/
Regular Expressions. Ya love 'em or ya hate 'em. But it shouldn't be so black-or-white. Here's when they do, and don't make sense.
Many people don't understand refactoring, and this leads to several anti-patterns.
Why "Consider refactoring this" comments are silly
Code is always subject to refactoring when the need arises. Adding a comment to that effect is just noise.