Write the most clever code you possibly can

def is_prime(x):
    if x == 1:
        return True
    return all([x%n != 0 for n in range(2, x)]

This is “clever” because it uses a single list comprehension, as opposed to a “simple” for loop.

This is not very clever because

• 1 is not prime
• There is a missing )
• Using a list comprehension will materialize the whole list of x - 2 booleans, wasting memory and time. It should be a generator expression instead:

return all(x % n != 0 for n in range(2, x))

Or, if you’ll tolerate a little more cleverness:

def is_prime(x):
    if x <= 2:
        return x == 2
    if x % 2 == 0:
        return False
    return all(x % n != 0 for n in range(3, math.isqrt(x), 2))

The Kernighan misquote is cute, and maybe it’s an independent rediscovery, but you might want to give some credit to Linus Akesson for “Kernighan’s Lever”.

Here is how the article defines “clever code,”

Clever code is anything using features or domain concepts we don’t understand.

I would propose the modified definition,

Clever code is any solution we don’t expect.

There are solutions we don’t expect because of unfamiliarity, like with the people @hwayne mention who prefer straight-line code. I think if we find ourselves in that situation, it is reasonable for us to try to broaden what we are familiar with. We’ll slowly incorporate the “clever” solutions that make most sense until they are no longer clever to us. When Java 8 came out, I remember hearing that lambdas were too clever!

Then there are solutions we don’t expect because they are misuse or abuse (be it of familiar or unfamiliar constructs). This is what I think of when I think of clever code that is to be avoided. The kind of code that makes you stop in your tracks and ponder it even if you are familiar with all of its constituents.

Unfortunately it’s hard to draw a line between these two, and what you think is code golfing, I swear I’ve seen used normally (please don’t). It doesn’t help that some tricks we see as clever in one language are standard practice in other languages, (e.g. treating numbers as booleans).

My favorite part of this article is acknowledging the existence of grad students outside cs who write scripts for research. This is a demographic that I work almost exclusively with and nobody in the real programming world seems to be aware of their existence.

These people aren’t typically great programmers but they write a lot of code, enough that they are a relevant demographic when considering the user base of a code tool.

Reminds me of:

from itertools import count


def gen_primes():
    for i in count(1):
        if is_prime(i):
            yield i


def is_prime(i):
    if i < 3:
        return i == 2
    for d in gen_primes():
        if d ** 2 > i:
            return True
        if i % d == 0:
            return False

I like the fact that gen_primes just uses is_prime and is_prime just uses gen_primes, yet it works :)

I’d argue for committing the most clever code you can. But in a powerful language, that means building a DSL such that your actual program amounts to a configuration:

(send-report
    :to client-emails  ; At a certain size, nouns like "destination" can be easier to align with internals
    :covering list-of-equities
    :at 8 :in 'NYC
) ; "bad" paren style is nice for configs

Then you just implement this clever/short API (and e.g. add some webforms with logins which clients can use to add stuff to the equity list and sales can use to add to the clients.) Good, clever code makes empowering non-leaky abstractions! (Yes, I’m just redefining clever.)