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.

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.^[1].

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?

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. 😉