How complex should code be?

Remember that code should primarily be understood by humans...compilers take care of making the computer understand.

I think it is important to separate the domain complexity from the underlying technical complexity.

Some domain-specific functionality for which you would like to use the computer is intrinsically complex, some is not. For example, accounting problems are full of weird rules, but most of the computations are fairly simple. Valuating financial securities on the other hand, depending on the type, can include hugely complex mathematical formulas and lots and lots of simulations. Most computer systems are really just collecting large amounts of data, but many of them have a few underlying complex algorithms.

Technology on the other hand often imposes its own complexity. Writing a big program in C++ for a PC can be a challenge. Writing a web based application for the Internet can be far worse. Trying to insure fault-tolerance, performance or security often causes a great deal of added complexity. Each different technology helps or hinders the system.

What we really want to do, is express the code in it's simplest possible form that is closest to its inherent domain or technical specification. If you're writing an operating system, then C is an easier language to use. If you're working out complex risk probabilities for insurance than a matrix-oriented language like APL may be more appropriate. If you're just creating massive reports, than something with a simple syntax oriented towards reporting is best choice.

So if your 150 lines of if/else stuff "matches" the way the problem is expressed far better than 20 clever lines, it is a far more maintainable and expendable bit of code. If you take a long-term perspective, writing running code is easy, it's keeping it that way that is the real challenge ....

Paul.

Well, code can get pretty hard to understand and maintain just due to sheer volume if it gets large enough (see most Java code). If all else (performance, etc.) is equal and the difference in length between the simple and complex algorithm is really drastic, I'd always go with the complex but concise and elegant algorithm over the simple but verbose one. Assuming both algorithms are proven to be correct, the one with less if statements and less code overall is less likely to have subtle implementation bugs and therefore less likely to ever require maintenance. If I were a maintainer, I'd much rather spend my time learning a new algorithm than learning how someone implemented some ridiculously long but boring algorithm.

Complex does not necessarily mean more or less lines of code to me.

The perfect system is never built the first time. All you can do is try not to make too many complex decisions that tie you into doing things one way.

For that reason I like to keep complexity low during the initial versions of any project. The reason you built something (new flexibility) is severly impacted. If you make it as complex as possible fewer people will understand it at the beginning. That could be a good or bad thing.

If you make it too simple (and 50 to 70% more code) it may have performance issues.

As a system ages and matures, the complexity seems to come in through re-factoring. By then you can reach a point where some code may never be touched again, and if you ever do, the costs to understand the complexity will be lower due to the lower frequency of touching it.

I like solving complex problems with simple steps. Where it isn't possible, the complexity increases accordingly. There was a point in another question about knowing when its "good enough". Sometimes a bit more code (5-20%) can offset the complexity significantly, which may be more expensive to re-learn or understand by someone.

Needing a better algorithm is usually a good problem because it means your stuff is being used and theres new demands to be dealt with.

This is the same sort of complexity that applies to Database Abstraction for me, you have to know when to make it more flexible, and when to keep it simple, and its best learnt through building it, and scrapping it a lot before you write a single line of anything.