I consider lazyness a quality for developers. Let me explain.
If I do something twice, there is a good chance I’m going to need to do it a
third time. Therefore, I want to help my future self to not do it a third time,
to be lazy by avoiding future work.
This precept can take different flavors. For example, I can factorize a common
functionality into a function, or into a script. Or maybe this is something that
can be automated: doing a release, deploying, testing.
But if you take a close look, it’s not exactly lazyness, because you need to
engage more work now, to save some work later. It’s a tradeoff. And like with
any tradeoff, you might first want to evaluate:
Let’s make a truth table out of it.
| # |
Time to Factorize/Automate |
Probability of happening again |
Spend the time? |
1 |
Long |
Low |
No |
2 |
Short |
High |
Yes |
3 |
Long |
High |
🤷 |
4 |
Short |
Low |
🤷 |
And today, I’d like to talk about something clearly in the category 2 and yet,
too often, people don’t spend the time.
Let’s take an example to illustrate. Let’s say I’m writing a script. At some
point in the script, there is the following sed command..
sed -niE -l 80 's/Referer/Referrer/g' request.http
What do you think -niE and -l does? You don’t know? Well this is a problem
because you’re not the only one who is going to read that piece of code. Since
there is much more people who are going to read that code, than to write it,
making it readable should be a priority over conciseness.
Now, how about that version?
sed --silent --in-place --regexp-extend --line-length=80 's/Referer/Referrer/g' request.http
It’s much better. Not perfect, but much better. You’re going to spend much less
time (or no time?) in the documentation trying to understand what each of the
option means.
So, dear developers, please, pretty please, in scripts, always choose
the long version for options. It’s going to save a lot of time to the future
readers of the code, including you. 😉