loading...
markdown guide
 

Not "clever code" but "clever design".

I'm at present working with an API that returns times (not datetimes, just the hours part) in this format:

{"open": "08:20:00", "close": "300"}

I asked about the meaning of "300" to the developers that wrote the API and the answer they gave me is: well, we compute the closing hour with this PHP algorithm:

date('H:i', strtotime('08:20:00') + (300*60))
# result is "13:20"

So, instead of writing the actual closing time, they decided to do this, in a REST API.

I wanted to scream :-D

Now I have to figure out how to implement the same thing in Python -_-

 
 

I feel your pain.

Literally, I shuddered after reading that.

 
 

This is the problem with "clever code":

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan

 

Code golf can be fun, but I don't think it belongs on real projects.

These days it's rather rare for tricky code to be really necessary. Even for fairly high performance projects, compilers have become good at making optimizations. Also, often the hardest thing to achieve is to find the simplification that takes a problem which appears hard and makes it easy.

I imagine that there are still places where tricky code is needed for performance, but it must be a vanishingly small segment of the total software ecosystem...

 

A general problem with "clever code" is that it's infrequently "optimal". And, by "optimal", I don't limit the evaluation scope to traditional measures like speed of execution, resource-consumption, etc. versus other methods. I mean, because it's "clever", it is frequently hard to maintain — especially from the standpoint of handing stuff down.

Sadly, I'm a frequent flyer on the "so terse/compact/dense no one else can maintain it" side of "clever code". On the plus side, it affords the opportunity to teach others new methods ...but the time lost to having a second person having to track the originator down to teach them how to interpret, replicate and/or improve on the code renders it no longer optimal when measured in (expensive) man-hours consumed.

 
Classic DEV Post from Jul 30 '19

When Stack Overflow Goes Offline...

Bertil Muth profile image
Agile coach and developer