The simplicity cliche

[Daniel Shawul]

This is what i feel when someone tries to lecture me of how my code can be simpler, and why i have to insert asserts everywhere in my source codes. I feel like these are way over-rated specially in chess forums. Dr Dobb's tells it like it is Discuss!

[Henk]

If I cannot find an error, I have to simplify. Then I have a better chance to find the error. Of course isolating the problem (code) also helps.

Or substitute code into something equivalent.
Sometimes I cannot make one valid statement. So why should I make many. Ok maybe in these situations I should not make any statement at all.

[AlvaroBegue]

I don't particularly like that article. It proposes "readability" as the goal instead of "simplicity", but the example he had just given us of code that was complex because the task at hand was complex was also completely unreadable.

I agree with him about readability being the most important feature code can have, although I prefer the term "clarity". I am tempted to place clarity ahead of correctness, because code that is clear and incorrect can be fixed, but code that is correct and unclear means bugs will be introduced in it forever as people try to adapt the code to new needs.

There are problems that are complex, and it is OK to have complex code to handle them. But then there is a lot of complexity that is added to the code by sloppy programming, and that's what should be trimmed. The article says something similar towards the end.

There are a few conventions we have learned over the years that make code simpler:
* Ordinals start at 0 (so the first thing has index 0, the second thing has index 1, and so on).
* Ranges include the start point but not the end point.
* A 3 percent increase should be represented as a factor of 1.03. You can then compose two increases by computing a*b, instead of ((1+a/100)*(1+b/100)-1)*100.
* Instead of using angles, try to solve the problem with vectors. If you must use angles, express them in radians. But chances are you can avoid using angles and make your code simpler.

It's a modest list, and it's probably incomplete. But I wish someone would have told me these things when I started programming.

[Daniel Shawul]

I don't particularly like that article. It proposes "readability" as the goal instead of "simplicity", but the example he had just given us of code that was complex because the task at hand was complex was also completely unreadable.

I agree with him about readability being the most important feature code can have, although I prefer the term "clarity". I am tempted to place clarity ahead of correctness, because code that is clear and incorrect can be fixed, but code that is correct and unclear means bugs will be introduced in it forever as people try to adapt the code to new needs.

Yes it is ok to have a complex code as long as it is readable. One can choose a complex algorithm for many reasons even though a simpler algorithm exists. An example in chess engine developement that is frowned upon is iterative search. I decided not to use recursion because I set out to implement DTS eventually. Though that goal was never fully achieved I am glad I did use it. The problem with iterative search is it is inherently complex. I tried to make my way up from an iterative perft, then qsearch and search. However there are still gotos in many places. I can try and tone it down a bit with macros but it still will be complex anyway. I guess my search should 'Abandon all hope, ye who enter here' Seriously if you don't want to do more work, then don't go there and use YBW + recursion. If you want to use DTS , you have to freely explore the search stack, there is no other option

There are a few conventions we have learned over the years that make code simpler:
* Ordinals start at 0 (so the first thing has index 0, the second thing has index 1, and so on).
* Ranges include the start point but not the end point.
* A 3 percent increase should be represented as a factor of 1.03. You can then compose two increases by computing a*b, instead of ((1+a/100)*(1+b/100)-1)*100.
* Instead of using angles, try to solve the problem with vectors. If you must use angles, express them in radians. But chances are you can avoid using angles and make your code simpler.

Good list. Those are things I take for granted now but I have made many mistakes with radians while using calculators and lost many marks in exams

[Henk]

If you want to make difficult code, use design patterns.
If you choose the right ones and use them wrongly, you can be sure no one will understand the code.

Simple can be beautiful but also boring.

Simple designs can be quite difficult to create.

It's easier to make it difficult because creating chaos is easy.

Complexity can be measured by the number of unique operands and operators. Avoid redundancy.

[Daniel Shawul]

Well the argument is not everything can be simplified and we should not necessarily strive to achieve the un-achievable. Some algorithms are just complex. Example for chess engine development is iterative search. You can spice it up all you want but you just have to make a decision during design to use it or not.

[bob]

If I cannot find an error, I have to simplify. Then I have a better chance to find the error. Of course isolating the problem (code) also helps.

Or substitute code into something equivalent.
Sometimes I cannot make one valid statement. So why should I make many. Ok maybe in these situations I should not make any statement at all.

My comment would be "if you can write it, you can debug it, regardless of simplicity."

I choose to write things in a direct way, always considering the underlying architecture to try to make it as fast as possible. That's not always the simplest code. simple is not always better. An automobile is anything but simple, compared to a horse and wagon, but it is undeniably better at providing transportation.

[AlvaroBegue]

My comment would be "if you can write it, you can debug it, regardless of simplicity."

“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 Kernighan

No disrespect, but I am with Brian on this one.

[nionita]

But complex things can be combined from simpler ones (composition). When we will have even better optimizing compilers, this will be the way.

[hgm]

“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 Kernighan

That is a fallacy of the same type as that led people to think in pre-Von-Neumann days that self-reproduction had to be an obvious violation of natural law, as a machine always needs to be more complex than what it builds.

In reality it means that debugging just takes twice as long. Time and tenacity can substitute for cleverness, just as quantity and repetition can substitute for complexity.