Shorter code is inconsiderate
And it’s a waste of time.
I frequent sites like Exercism to keep my coding skills sharp through working and reviewing various coding challenges. A dangerous trend that I consistently see is that code implementations with the fewest lines of code tend to be up-voted and rewarded as the most elegant, creative, and clever solutions.
This is crap. Brian Kernighan had it right when he said:
“… 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?”
When you reduce your lines of code to the point that it’s cryptic, are you really building maintainable and sustainable code? Will it be easier or harder to spot a bug? More importantly, if the performance is the same, are you really using your time judiciously? Fewer lines of code does not necessarily make for clean code. Once you cross the line of making it abstruse or utilizing obscure, unnecessary modules, you might as well say to your co-workers:
“I wasted time perfecting and complicating a straightforward module so that you could waste your time understanding it. Cool, right?” — ❤ xoxo, Code Ninja
It’s pointless and selfish, and serves only to stroke your own ego. Superfluous and redundant code is bad, but short code isn’t automatically good, either. There’s a huge difference between making code short in order to make it concise, and making code short just to make it short.
Let’s compare two different Python implementations of a simple algorithm for finding the “hamming distance” between two strings. Hamming distance is essentially the counted differences in individual characters:
- Hamming distance between ‘abcde’ and ‘abcde’ = 0
- Hamming distance between ‘abcde’ and ‘edcba’ = 4
- Hamming distance between ‘abc’ and ‘abcde’ = 2
Here’s a “highly-rated” implementation from Exercism:
This is an excellent implementation… if the goal was code obfuscation.
Here’s an implementation that received almost no attention:
It used 15 more lines of code and had a hamming distance of 517, but here’s why it’s so much better than the first:
- It’s well-commented with both pseudocode and docstrings. You can intuitively follow what each section and line does. A beginning programmer from any language could understand it. How many “Pythonists” would understand the shorter one at first glance?
- Each line executes only 1 or 2 methods or operations. Take a peek back at the first one, and see how there’s a sum method, a != comparison, a for loop, and the “magical” map method all on one line. Which is easier to follow? (Read: which would be easier to debug?)
- Variables are named logically, with ‘i’ being the only single-character variable. Try plopping the first implementation into a larger piece of code and searching for ‘x, y, a, or b.’
Above all, it’s clear what the intention of each author is:
- The author of the shorter code wrote it for himself/herself.
- The author of the second code wrote it for others.
I suppose what I’m trying to say is: please, don’t be a prick.
Whether it’s in front-end HTML/CSS or back-end Python and Ruby on Rails, write readable code and write it for others.
Like or hate what I wrote? Let me and my record-breaking 10 followers know at: @allanbreyes