re: What habit do many senior engineers have that juniors should try to avoid adopting? VIEW POST


Avoiding clever code.

You feel smart writing clever code, and you may even justify it by saying it's less code. However, code should be explicit and thus be understandable by everyone. Even if that means writing slightly more code.


For juniors who might be reading, can you give an example of clever code and a good alternative?


Good idea. Clever code typically comes along with learning intricacies of a language, so in JavaScript it's totally valid to write an if condition like this:

isDataValid && submitData();

This totally works, but with a few more characters, we can make the intention more explicit and clear:

if (isDataValid) submitData();

Here's another example. Let's say we need to set a timeout of 5 seconds. We can use clever code here too:

setTimeout(() => {
 // run this after 5 seconds
}, 5e3);

Woah, what is that 5e3? It's exponential notation, and while it looks cool and is less characters, is totally unnecessary. Just use a regular number:

setTimeout(() => {
 // run this after 5 seconds
}, 5000);

Even better would be to extract to a variable like FIVE_SECONDS so that you don't have to do any conversion between milliseconds to seconds.

The first example is actually OK in my opinion, short-circuit is a handy feature most of the times, for things such as JSX you don't really have another succinct alternative.

Take a look at this one which I found in an old codebase, back in the days:

var Ticket = function(id, name, autoAssign) {
  this.id = id*1;
  this.name = name;

There're a lot of obscure ways to take advantage of JS's type cohesion, but you'll quickly lose track of what this kind of code means. Further, it might even have surprising, unexpected behaviors. There's nothing wrong doing:

this.id = Number(id);

Great point! I would add that "clever code" is often is just saving symbols, while sacrificing readability, expressiveness and distorting meaning.

In the example with "&&" we rely on the fact that in JS code on the right part of logical AND won't be executed. So it is sort of a "hack". And I think that majority of such "clever code" examples are in fact hacks.

It's important to understand that when we write code - we have different sorts of stakeholders. And one of important categories of those are developers themselves!

It is important that code not only performs some useful action, but is also convenient to work with and is understandable.

Maksim nailed it.

Regarding JSX though, it's a totally valid use case for using && and ternary operators since you're conditionally rendering pieces of UI this way. From a declarative perspective, it's fairly clean.

Love the Number(id) example too. Not only does it handle null values, but you can more clearly understand that you're converting to a number.

I disagree that 5e3 is clever. Exponential notation is something that every coder should learn. It appears in a lot of places and is much clearer that expanded numbers.

I did a lot of work with nanoseconds much, and I would have to see 1500000000 in the code versus 1.5e9. With larger numbers the exponential format is preferred.

Of course, I'd also like a language that allows separators (I did in Leaf, like 5_000.

Note though, on the second I think any api that accepts something other than seconds for duration by default is broken. Seconds is the natural time, milliseconds is unusual. Thus a conversion function would be nice to see there.

It's clever in that scenario because seeing the exponential notation for most people will require more brain processing power than simply seeing 5000 milliseconds or 5 seconds.

It also really just depends on what you're building. Web development rarely requires you to use exponential notation, and so declaring it as "something that every coder should learn" is not an absolute that I can get behind.


Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan


This, and your examples, were very helpful. Thank you!


Unfortunately, there are many frameworks today that suffer from this mentality.

An excellent example would be a framework like Laravel. Certain aspects of it are really nice. Eloquent ORM, for instance. But other aspects create levels of abstraction that make the code difficult to understand. Are some of the ideas clever? Yes. But they make maintaining the code confusing.


I agree.

But writing clever code for fun can be pretty fun.

As long as other people aren't ever going to be burdened by reading your code-golfed 5 character insertion sort, I think it's fair game :)


I was going to mention that. When using something like Codewars, it's really easy to see clever solutions by others and then possibly get into the habit of always trying to be clever too.

It is fun to try to be clever on stuff like that, but it's almost never necessary—at least not to that degree.

I've been doing that a lot in CodeWars. Putting the entire code in a single return statement. I'm talking about converting a string to an array, running map and reduce on it, then converting it back to a string in a single return statement.

Yea exactly what I'm talking about :) It's fun right!


I've had to struggle with this myself! I've had the urge to grab an existing, working piece of code and rewrote it to be shorter and sometimes less understandable. It's for sure something I have become more aware of and that I have to think about when refactoring code.


I totally agree. Writing code is an art and, like painting, there are many styles.

When painting something abstract, the artist surely knows not all viewers will understand the painting. When writing code, you should strive to paint photorealism, where the code can't be misinterpreted.

There are times where obscure code can't be avoided, though. If it's convention in a framework you're using, for instance, then it's okay because later coders should understand the convention. Otherwise, it's a perfect opportunity for an explanatory comment. This also helps you not try to be "clever" because writing the comment nullifies any handful of keystrokes saved by being so.


That's a good point. If you must write clever code, then at least provide a comment explaining why that code is there.

Code of Conduct Report abuse