What is "Simple"?

Question

I've been thinking about the definition of "simple" for a while now, spurred by things like "Real Simple" magazine, which is essentially a vehicle for advertisements for more stuff to buy that clutter up your life.

Some people see doodads, like remote controls, as simplifying your life, while others see the remote control as something cluttering, requiring maintenance and another doodad, a locator when it's lost.

In trying to create my own definition for simple, I think of small programming examples like the samples below. While it's a very straightforward case, I've seen developers on both sides claiming one is more "simple" than the other:

A very clear, but verbose, chunk of code:

public bool IsGreaterThanThree(int x)
{
    bool isGreaterThanThree;

    if (x > 3)
    {
        isGreaterThanThree = true;
    }
    else
    {
        isGreaterThanThree = false;
    }

    return isGreaterThanThree;
}

A very terse chunk of code:

public bool IsGreaterThanThree(int x) { return (x > 3); }

My questions to you:

• Which do you find more "simple" and why?
• Is there an objective measure of simplicity, either in terms of development practices or in life? Is it fewer moving parts, or is it clarity?

Some nice nuggets from answers below:

• "Simplicity is achieved when nothing more can be taken away."
• "I define "simple" in terms of required net logical thought. Too much reading requires too much though. Being too terse requires too much different thought."
• "...if you didn't write it, and can understand it in about the time it takes to read it, it's about right..."

Some observations so far

• It's interesting that even here, there is disparity between opinions on these two method implementations; some thought the first was "simple", and some the second. Several of the rewrites are versions of the first, while many people liked the second better, with some reformatting; still others liked a "third way": some combination of the two (is this just in our nature to edit and find the solution no one's mentioned yet?)
• As some of you guessed, this code is trivial; I'm not looking for a better way to figure out if a given integer is greater than 3; it's just for illustration.
• I think this is the same question that Google, Amazon, Microsoft, etc. ask about their user interfaces: Google says "fewer features and clean interface to simplify for new or infrequent users" while Microsoft says "gobs of features to simplify power users' experience". This is similar to the comment below about remote controls being simpler for people who don't lose them, but not simpler for those who do.

Answer 1

Simplicity is achieved when nothing more can be taken away.

In your example I think the 2nd example is simpler. It clearly expresses the intent.

Simplicity is subjective. Consider Perl.

Answer 2

The second is more simple, but thats not an excuse not to break it out into a couple lines.

Answer 3

I define "simple" in terms of required net logical thought.

Too much reading requires too much though.

Being too terse requires too much different thought.

So you have to find the medium between the two.

Personally, I have become a fan of "early exits" from functions, in conjuction with "omit else if they're really not needed"

public bool IsGreaterThanThree(int x)
{
    if (x > 3)
    {
        return true;
    }
    return false;
}

Would be how I would write it.

Simple, concise, and minimum logic overhead.

Try reading out your code snippets and mine against each other and see which are the easiest to convert into a logical phrase.

mine: if x is larger than three, return true. otherwise, return false
yours(verbose): if x is larger than three, set islarger than three to true,
      otherwise, set is larger than three to false. 
      return islarger than three. 
yours(terse):  return is x larger than three.

Both your examples, ( at least to my reading mind ) are difficult to comprehend even when explained, mine on the other hand, I believe a 4 year old could understand.

Answer 4

The second one is definitely simpler. If the expression is terse but does not depend on side effects, it is better. On the other hand, for the caller of IsGreaterThanThree it really doesn't matter, both (seems to) behave similarly.

Answer 5

Most simple would be to choose neither of those two options and simply use > 3. Simply using the operator is completely readable and adding a function adds overhead and impairs readability.

Answer 6

Both pieces of code are equally "simple" in terms of complexity.

I mean, you are doing the same thing. However, I prefer the first code in terms of clarity. It is for example a lot easier to follow in a code review or easier to write test cases for in a unit test.

I think, it's a common misconception that trying to express code in a one-liner makes it simpler.

Answer 7

I vote for:

if (x > 3) {
  ...
}

No need for a function of any kind here.

As for your example, I prefer a middle ground:

public bool IsGreaterThanThree(int x)
{
    return (x > 3);
}

The extra whitespace from the added lines makes it more readable and the function itself can't be reduced.

Answer 8

Your first example adds complexity by setting a boolean value in an else. An if else has a boolean right at the top. So you added complexity for readability's sake. Which is not simple. And the benefit is debatable, especially when you have a nice clearly named method. If the method has a good name and is in the proper place class-wise the readability of its guts is less important.

To me, simple is not "Is this as simple as humanly possible?" it's "Is the complexity beneficial?" A remote is unfortunately necessary these days because most functions of your TV can't be accessed elsewhere. So it didn't make anything simpler, it just moved a bunch of buttons from one place (the TV) to another. But it added a benefit at the same time: no interruption to my eating of many cheetos.

Answer 9

To simplify is to remove the inessentials. Reduce interactions, functions, and moving parts.

And now some quotes:

Everything should be made as simple as possible, but not one bit simpler.
-Albert Einstein

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -Antoine de Saint-Exupéry

My word of choice is elegant.

"Characterized by or exhibiting refined, tasteful beauty of manner, form, or style."

Personally I wouldn't create a function. bool b = x>3 is pretty clear to me. I don't know why everyone wants the complicate it.

Answer 10

Maybe you need to ask a different question. I believe that most people will define simple in similar, compatible ways.

When asking someone whether a remote control simplifies someone's life, you can get varying answers. The problem doesn't lie in the definition of simplicity. Instead, the apparently incompatible answers "simply" need more clarification.

Someone who routinely needs to spend 2 or 3 minutes hunting for a remote control in order to change the channel could easily say that it would be simpler to get up and push the button on the TV. The other guy, who always places the remote in an easy-to-reach and consistent location, finds the remote much easier to reach.

Also, if you think about that last paragraph, you may see that when you asked whether the remote made things "simpler", I subconsciously translated that to "easier". This is likely helping to confuse things.

In relation to code, I think the simplest code is that with the fewest elements or points of potential failure (either during execution or entry).

Answer 11

The second version is simpler.

The first just adds extra contortions to avoid using a comparison expression as something other than a condition. Unfortunately this is all too common.

Answer 12

If you use the first version then I'd make the following change to make it clearer:

public bool IsGreaterThanThree(int x) {

bool isGreaterThanThree;

if (x > 3)
    isGreaterThanThree = true;
else
    isGreaterThanThree = false;

return isGreaterThanThree;

}

I don't see the need for curly braces when there is only a single line statement.

Answer 13

If an experience programmer is reading your code, the second code snippet should be simple to him. If, howerver, a layman has to read it, perhaps the first example is simple.

So it varies with perspective.

Secondly that word is one with multiple meanings. It may connote 'concise' just as well as 'easier to grasp'.

So, well, no absolute answers here. Neither in any more general, scaled-up context where you may want to use that six letter word: simple.

Answer 14

Beware polemics ahead:

Whoever thinks the first solution is simpler, or even clearer, than the second solution has a problem. The first solution might have other virtues (well, it doesn't) but it certainly is not simpler for any conceivable definition of the word.

Other than that, I haven't got much to add, except to disagree with Kent because he implies that C-like syntax has a 1:1 correspondence to English, which is wrong. He claims that the second code would read:

return is x larger than three.

I disagree. Since the expression has an obvious Boolean context (even in a non-strict type system), this should rather read “return whether x is larger than three.” And I hope that he agrees that this is indeed simpler than his professed simplest solution.

Answer 15

I would say simplicity is a subjective measure. Some examples:

"I can understand this better than the other thing, therefor this is more simple than the other one."

"Reading english newspaper is not simple at all for me, i'm not a native english reader."

Someone may find an algorithm simple, another would find it not simple. For your example, i would be surprised if anyone finds the first solution more simple. Note how it contains the same logical expression x > 3 in one of its conditions, then adding a layer of indirection until it returns, which is absolutely unnecessary.

Contrary to that, i think complexity is something you can very well measure objectively. An example is the Kolmogorov Complexity, which states essentially that the complexity of something is the length of the shortest algorithm generating it. So an unnecessary long algorithm might be quite complex (using redundant loops, and all other sort of things), but might be quite simple to understand. Similar, a random sequence of numbers might be quite complex, but easy to understand (because there is nothing to understand at all, in the first place).

Answer 16

For a more practical use of a "is it greater than 3" function, consider the use in a C++ algorithm, something like remove-if(foo.begin(), foo.end(), IsGreaterThanThree); in which case such a simple function is useful. We can't just write > 3here. We can put it together with STL arguments, such as remove-if(foo.begin(), foo.end(), bind2nd(greater<int>(), 3));, but there are people who will claim that isn't really simpler.

I suggest, therefore, that everybody who wants to quibble about whether IsGreaterThanThree is a useful function discuss whether its use as separate function, separate functor (object with operator() member function returning true when its data member is greater than 3), or just using the bind2nd form is simpler.

Otherwise, we can go back to the original argument, and I'm firmly of the belief that return x > 3 is the simplest way. It returns precisely what is wanted, with no parsing required, and very little chance of spelling errors.

Answer 17

Haskell:

isGreaterThanThree x = x > 3

or even:

isGreaterThanThree = (> 3)

Answer 18

I think what you are looking for is something like

public bool IsThisNumberAcceptableAccordingToBusinessRules(int x) {

    if(x <= 3)
        return false;

    return true;

}

Obviously, change the name of the function to something sensible. But the idea is to express what you are trying to do, rather than how it is being done. What = acceptable according to business rules; how = is greater than 3.

Answer 19

First: your example is unfair. Neither option is simple - it should be (x > 3) - that's simple. The fact that C++ won't let you the simple code in all cases is a problem with the language and should not be relevant in the philosophical discussion.

Second: the simplicity is in the eyes of beholder. In you example, again, there is no other way to express ">" - no matter what you do, ">" shows up somewhere in the code. To provide a better example, consider Perl:

$x gt $y ? 1 : ($x eq $y ? 0 : -1)

versus

$x cmp $y

Now simplicity depends on whether I am familiar with "cmp". If yes, then the second option is simpler.

Answer 20

I would say although i find the second one simpler i prefer the first example, because it seems clearer. You would probably then argue with me that something simpler is also clearer but i will disagree. The first example guides the viewer through the code. The second one although simpler you have to decompose it.

Answer 21

Remote controls don't simplify, they automate which is different.

Answer 22

(Simple)Wikipedia defines Simple English as

"Simple English is similar to English, but it only uses basic words."

Using this you could say that Simple programming is similar to programming, but you can only use basic operators.

So, for example, this inline if could be considerd "not simple"

bool isLarger = x > 3 ? true : false;

and the regular if would be "simple" because the regular if is more basic than the inline if

if (x > 3) 
{ 
   return true;
} 
else
{
   return false;
}

Now of course we could debate about which operators are considered "basic" :)