Dr. Dobb's Calls BS On Obsession With Simple Code 381
theodp writes "Over at Dr. Dobb's, Editor-in-Chief Andrew Binstock has a nice rant on The Misplaced Obsession with Simplicity. 'Any idiot can write complex code,' goes the old maxim, 'the true art is writing simple code.' Right, Andrew? Wrong (mostly). Binstock explains, 'It's not true that any idiot can write complex code. Complex code is difficult, often very difficult, to write. It's entirely true that it's more difficult to maintain, too. But that's the nature of complexity. Some things are intensely difficult to express in code and they require complexity, simply because they're not inherently simple.' After citing the complex-but-necessarily-so code of Al Aho and sometimes-misguided reverence for cyclomatic complexity limits to help make his point, Binstock concludes, 'My view of simplicity is unemotional and free of idolatry because I define it with respect to complexity, rather than the other way around: Simplicity is the quality of code that is no more complex than required to express the underlying complexity. In this way, simple code can be intensely complex. There is no inherent good/bad dichotomy.'"
To quote Einstein (Score:5, Insightful)
Re: (Score:2)
Re:To quote Einstein (Score:5, Insightful)
Arguing against stupid "complexity metrics" is fair. A programmers job is to game the system. Give him a metric other than making the customer happy, and it will not end well.
But I've seen far too much code that was simply far more complex than it needed to be. Stop tripling the size of your code for use-cases that no one has asked for, people!
If you can make assumptions that significantly simplify your code, and those assumptions fit within the actual, stated requirements of the work (ignoring requirements that exist only in your head), for goodness sake make those assumptions.
Re:To quote Einstein (Score:5, Insightful)
Re:To quote Einstein (Score:5, Insightful)
Yes, but this should be done prior to code writing.
Far too often I've seen extremely complicated code designed to handle "what-if" scenarios that never happen.
i.e.
Developer: "I wrote that configuration module in case they ever need to change the parameters of X"
Me: "Did you ask if X would ever need to be reconfigured?"
Developer: "Of course! And the client said that sure, if I could make it configurable, go ahead and do so"
Me: "And did you ask how likely it would be that X would need reconfiguration? Or under what circumstances X would need to be reconfigured? Or what types of 'reconfigurations' they think they would need? We're looking at 2 man-months of code, plus testing, plus implementation time here....was any kind of cost-benefit analysis done to see whether it was worth it to write this?"
Developer: [blank stare]
Re: (Score:3)
Very well put. So much needless code comes from trying to support actions that the customer will never actually care about.
Re: (Score:3)
Re:To quote Einstein (Score:5, Insightful)
I think you're confusing feature-creep with a comment that was meant to be about edge-scenarios. Allowing someone to configure parameters that were never spec'ed to be configured is feature-creep (gold plating, extra coding, call it what you will), and I agree should be avoided and adds unnecessary (or not obviously necessary) "complexity".
Handling an edge criteria that was implied but not explicit in a specification is what is typically meant of "corner case", and is not the same thing you described. Recognizing that the customer asked for something logically impossible (they want two data sets to reconcile, but they are at unexpectedly incompatible cardinalities), or something that, upon investigation while building an app, wasn't precise enough (they asked for this to be their standard green, but their standard list only includes red and blue).
It's nearly impossible to specify all of those prior to coding, which is why the typical "waterfall" development techniques have fallen out of vogue. You're always going to learn things while coding, and this is one of the main contributors towards apparently unnecessary complexity. If I design version 1 of a program perfectly, and customers have new requirements for version 2, it's unlikely that the "simplest" implementation of version 1 will be the one that is most conducive to an upgrade. You end up with a choice between refactoring completely or sacrificing some efficiency and simplicity to graft the new features onto an otherwise good version 1.
I think Dr. Dobbs is nitpicking, though. There are definitely many ways to address, measure, or understand simplicity, and I agree that it should not be THE goal in and of itself. But the idea of making code easy to read, easy to understand both in the micro and macro sense, and just generally "simpler", has many merits.
Re: (Score:3, Funny)
I've seen extremely complicated code designed to handle "what-if" scenarios that never happen.
As is usually the case, XKCD covered this [xkcd.com] well. The image title is particularly good:
I find that when someone's taking time to do something right in the present, they're a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they're a master artisan of great foresight.
Re: (Score:3)
Re: (Score:3, Interesting)
Stop tripling the size of your code for use-cases that no one has asked for, people!
Yeah, just let it throw a bugcheck when something happens outside of the design parameters and let the user sort it out with your support department. /sarcasm
Security risks. Data corruption. Performance edge cases. Productivity loss. Unexpected bluescreens. Actual damage to physical hardware controlled by the software. You know all that bad stuff could have been easily prevented if the programmer anticipated those situations, and the people hiring that programmer probably expected the software to be well-ma
Re:To quote Einstein (Score:5, Interesting)
Those things aren't part of the formal requirements in your world?
Re:To quote Einstein (Score:5, Interesting)
I've never seen formal requirements which detail every edge case I need to account for.
There's an assumption we'll be writing robust code, and as it gets created we build in as much error checking and handling as we can think of, and over time you usually end up adding more.
If coders had to be told in writing every error condition to check for, there wouldn't be any -- because the client wouldn't know (especially true when you have to create a library to do some of the work), and the developers would just say "not in the spec".
Come to think of it, I've never seen formal requirements for much more than the really high-level systems stuff. From my perspective, a system which has been fully designed and spec'd out before anybody writes code is a myth.
need to spec appropriate level of robustness (Score:3)
I work on highly-available systems (telecom equipment, core network stuff). Even there, some parts of the system can be less robust and some parts need to be as robust as possible.
The design for a given component needs to take into account how robust that component needs to be. Do you check EVERY POSSIBLE error condition and figure out intelligent ways to handle them (can be quite difficult and very time-consuming) or can you just panic the system if you detect something has gone wrong and you don't know
Re:To quote Einstein (Score:4, Insightful)
So, we should stop doing any bounds and input checking if the client didn't ask for it explicitly?
Is this part of Agile Programming or something? Write the most incomplete code you can get away with because it isn't in the spec?
I once had a co-worker bitch and complain I was checking the result of every single function, including strprintf() -- he said it was unnecessary. Not long thereafter, we spent some time tracking down a problem which turned out to be in his code, because he wasn't checking anything (again, because it was 'unnecessary').
If you write shitty, incomplete code up front, it's much harder to make it less shitty and incomplete later. If I know from experience there's a bunch of things that can go wrong, I'm going to try to account for as many of those things as possible when I write it.
Those use-cases nobody asked for can sometimes be the difference between code which collapses at the first unusual inputs, and stuff which can at least tell you WTF went wrong. Because sometimes, even the simplest of things can fail.
Re: (Score:3)
Is this part of Agile Programming or something? Write the most incomplete code you can get away with because it isn't in the spec?
Yes. It's part of TDD, where the coder is supposed to write the absolutely smallest set of code that passes said test.
Re: (Score:3)
Re:To quote Einstein (Score:5, Funny)
That quote is attributed to Einstein, but you should know by now a great many quotes are attributed to him, but very few can be proven to have been from him. -_-
"There's no such thing as a correct quote citation on the internet." -- Abraham Lincoln
Re:To quote Einstein (Score:4, Funny)
In the words of Albert Einstein: "I never said most of the things I said."
Re: (Score:2)
"There's no such thing as a correct quote citation on the internet." -- Abraham Lincoln
pure gold
Re: (Score:2)
Re: (Score:2)
Indeed. Simplicity is but an ingredient to the main dish that is perfection...it is not the sole ingredient; too much, and the flavor is ruined; too little, and the inner ideal is never glimpsed.
Re: (Score:2)
Re:To quote Einstein (Score:5, Informative)
It's paraphrase of Einstein who said something like that at various times in his life, but not those exact words.
Here's an exact quote from Einstein:
"It can scarcely be denied that the supreme goal of all theory is to make the irreducible basic elements as simple and as few as possible without having to surrender the adequate representation of a single datum of experience." - From "On the Method of Theoretical Physics", Oxford, June 10, 1933.
Re:To quote Einstein (Score:5, Funny)
Clearly, not taking his own advice here...
Re: (Score:3, Insightful)
Clearly, not taking his own advice here...
Dude, the man ushered in a revolution in physics. His idea of simple would melt most people's brains.
Re:To quote Einstein (Score:4, Insightful)
The efficiency of a system can not simply be measured by CPU cycles. It all depends on where your costs are. Efficiency has to be measured by money.
If your highest costs are in runtime efficiency, then yes, you need efficient code. But if your highest costs are in end-user time spent entering data, usability beats efficiency. If your highest costs are driven by software engineering practices, such as testability, reliability, supportability, frequent deployments, etc., then readability becomes far more important than efficiency.
The usability argument works like this: if I have to pay a barrista $10 an hour to touch 20 buttons just to place an order for coffee, and the user time per button press is 3 seconds while the system time per button is 8 milliseconds or less, the efficiency of the code is almost irrelevant. My development investment is best spent in reducing the number of button presses. If a fancy GUI and a magical "do what I want" button reduces the 20 button touches to 10, I can save 30 seconds of labor per cup of coffee. If adding that fancy GUI increases the system time from 8 milliseconds to 30 milliseconds per button press, I haven't actually incurred any additional labor costs because the system is still faster than an average human's response time (maybe not in a highly caffeinated coffee shop, but it's still far less important than saving even a single button press.)
I've found that in most business applications user time is the largest expense, by a very wide margin.
If libraries of tested proven code are cheaper than hand written assembler, I don't want to pay a developer to replicate that work, even if it would be theoretically more efficient - unless the program that they're working on has efficiency as the most important goal. If I was developing an algorithm for slinging polygons at a graphics card, you better believe I'd squeeze every cycle out of the GPU. But if I'm figuring tax on a cup of coffee, or the total of a chart on a web site, efficiency isn't nearly as important as provable correctness.
Lest you think I'm trying to defend the stupid walled gardens of iOS and their ilk's practices of constraining UIs and simpleton features, I'm not. I do think that there needs to be a mix, however. To use your iPhone rant, first remember that the iPhone is sold to completely average people, therefore, a simple UI is the primary requirement. (In other words the "dumbwagon" must be the default.) Furthermore, it should be restricted so that Joe Average can't accidentally screw it up to the point where it's impossible for him to recover to the dumbwagon state. Beyond that, however, everything else should be possible - there should be advanced configurations, user scripting, compilers, all that stuff that makes a computer do what I want. (And that's why I hate Apple.)
Meh (Score:5, Insightful)
Interesting article, but this seems an issue of a very pedantic interpretation of a common idiom.
When I (or I suspect most) whine about pointlessly complex code, it's just that. Code that is more complex than is reasonable for the problem. No one expects a simple solution for a challanging problem. It's an overly complex solution to a simple problem which we complain about...
Hello World! (Score:2)
The is a good reason I need a separate class defined to output each character in the string "Hello World!"
Re: (Score:2)
Of course you do, how would you localize it if you didn't? Man, some people...
Re: (Score:3)
Re: (Score:2, Insightful)
I think Dr. Dobb's stopped being relevant oh like 10 years ago. Its like a total kids magazine now, nothing like it was years ago. Most articles in it are unreadable.
Re: (Score:2)
Re: (Score:2)
For example, I've never had a manager look at my project and say "It has to be simpler!",
He probably did have a manager (or some coworkers) who did say that, which is why he was motivated enough to write a rant on the topic.
Re: (Score:3)
It wasn't until the mention of Cyclomatic Complexity that I understood what the summary was saying. It boils down to writing individual functions logically with as many if/else/while/for/switch branches as you need. Oftentimes, breaking up code into multiple functions to satisfy some arbitrary Cyclomatic "Complexity" coding standard makes it MORE COMPLEX. On the other hand, Cyclomatic Complexity can be used to find spaghetti code that would make a good project for refactoring. At the end of the day... h
Re: (Score:3)
One of the programmers I work with complains when you use more than 1 function to do a job. Even if it means writing a 20 page function. His code is unmaintainable because you can't change even a tiny part of it without breaking something 3 pages down. He cries that my code is too complex because I break things down into small simple functions and multiple files and build complex behaviors out of them so he has to swap between files.
He used to work on IE at Microsoft, so that might tell you something.
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point.
he'd still be wrong, see machine code (Score:5, Insightful)
Which is easier to understand and work on? The
By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.
Consider these two example programs:
Stand
Turn left
Walk four steps
Turn right
Walk two steps
Turn right
Vs:
heatlunch()
readslashdot()
Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.
Re: (Score:3, Insightful)
Compare .NET code to the compiled machine code.
Which is easier to understand and work on? The .net runtime is nothing but a set of functions in a separate file. using simple functions means main()can be an outline of the program, for example .
By any measure, Linus Torvalds is an incredibly successful programmer. His guideline is 6-8 lines per function or so.
Consider these two example programs:
Stand
Turn left
Walk four steps
Turn right
Walk two steps
Turn right ... 1000 more lines
Vs:
heatlunch()
readslashdot()
Even if the function heatlunch() is used nowhere else, using it makes the program far more understandable than inlining the walking code to get to the microwave.
But you forget you also have to walk back to your desk.. At that point, you have two usages of a pathing algorithm.. Which means you're repeating code, which means that using a function to enable code re-use instead makes sense. I'm hardly an advocate for complex functions (most of my code are 1 or 2 liners), but there are times when you simply cannot express something concisely in a short function, and the answer to that is *not* to artificially reduce it into code that does nothing but resides in a dif
Re:he'd still be wrong, see machine code (Score:5, Insightful)
On the other hand, even if code isn't used in more than one place, that doesn't mean it's not "expressing something concisely".
Additionally:
1) Methods are great ways of naming orthogonal snippets of code, rather than using a comment that may become obsolete.
2) Breaking large methods into smaller ones increases maintainability by enforcing certain constraints such as not reusing variables declared 100 lines up just because they happen to serve similar purposes.
I agree that you don't want to just arbitrarily break your method up for the sake of smaller methods, but I don't think reuse is necessarily the best way to judge whether methods should be refactored.
Re:Meh (Score:5, Insightful)
Do you re-use your functions, or do they only exist to break apart a single operation into smaller blocks? If it's the latter, then he may have a good point
I disagree, strongly. Breaking a large routine into smaller ones abstracts away what those smaller routines are doing. It puts a boundry around their interaction with the rest of the code, and puts their code away somewhere that I don't have to worry about, unless there's some reason I want/need to know the details of how that routine accomplishes what it does.
If you put it all flat into one big routine, I have to read and grok everything in that routine, if only to reassure myself that none of it has interactions with the one area I care about.
We actually have terms for this stuff: Cohesion and Coupling [wikipedia.org]. Cohesion in particular is an important concept here.
I find it amusing that the author's big example is Aho's parsers. Parsers are one of those special cases, as lexical analysis is a problem that is generally best solved by state-machines. I've tried for years, and really there aren't a lot of good ways to code lexer state machines that aren't either way slower than the typcial implementations, or a web of control flow that looks like a huge mess to those of us reared on structured programming. It isn't talked about much, but lexers (and some parsers) unashamedly make use of goto statements as their core braching mechanisim. Using Aho's awk parsing code as an example of why "clean" code isn't always desirable is like using the US Marines as an example of why killing people is often a good option for solving disputes. Perhaps its true in a technical sense, but its really crappy advice to be giving the general public.
Re: (Score:3)
Reuse, and breaking a problem in simpler logical blocks are both valid reasons to use functions, the latter helps in understandability and limits scope since you can more clearly determine what the inputs and outputs , and intent of a function is (as long as you name it right). You can also read the main function easier. ...
int id = findIndex(name,table); ...
reads much easier than:
...
int id = -1;
for (int i = 0; i < table.size; i++) {
if (strcmp(name,table.data[i].name) == 0) {
id = i;
break;
}
}
My guess is you're going to use findIndex more than once in your programming career though, making it a prime candidate for function from code reuse standpoint. I consider this a poor example. It's hard to find a good counter-example, because there have been very, very few times in my career where I've written code that I couldn't reuse. In my experience moving code off to a separate function for no other reason than to clarify the code only helps clarify the code for the initial author, not for those wh
Re: (Score:3)
Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
I miss nested functions - they were very useful for just that sort of thing. It also clarifies that nested function g() exists only to implement something in enclosing function f(), which is often the case when breaking thinks up for clarity rather than trying to write reusable functions. Since a nested function can access the locals of its enclosing function, it also often avoids having to pass very long argument lists.
Nested functions were a standard feature of Algol family languages, but unfortunately di
Re: (Score:3)
Breaking even a single operation into smaller blocks it a good thing, if it spans hundreds of lines.
I miss nested functions - they were very useful for just that sort of thing. It also clarifies that nested function g() exists only to implement something in enclosing function f(), which is often the case when breaking thinks up for clarity rather than trying to write reusable functions. Since a nested function can access the locals of its enclosing function, it also often avoids having to pass very long argument lists.
Nested functions were a standard feature of Algol family languages, but unfortunately died w/ C (though gcc supports nested functions as an extension). These days many people seem unaware that there even is such a thing as nested functions.
Nested functions are quite nice, and are actually supported by most higher level languages in common use these days. It's a much more appropriate way to break up code than putting bits and pieces all over the place just to reduce the size of a single code block.
Re: (Score:3)
Most higher level languages in common use? C, C++, Java don't have them. What other language is in "common use" these days? PHP?
Actually, the latest C++ and Java implementations do support it, as do C#, VB, Lisp variants, Python, and Scala, and most any pure functional language. Anything that supports closures supports this to some degree (the readability of the solution varies, however).
Einstein quote (Score:2)
Re: (Score:2)
Re: (Score:2)
Quote Invesigator (where you likely got your material from) makes a pretty good case [quoteinvestigator.com] that the modern quote actually originated from composer Roger Sessions in 1950, and may have been inspired by something Einstein had to say specifically about theories.
Sort of (Score:2)
In databases things get normalised down to their most basic elements, which is neccessary and good. In coding, everything might individually be simple, but the whole might be horrendously complex. Good documentation makes almost anything simple though, and by that I mean docs written intentionally to explain the overall codebase rather than disconnected sections.
Re: (Score:2)
Okay, most databases and most use cases.
Re: (Score:2)
Have you ever looked at a 5NF database? They can be hugely inefficient and remarkably hard to get right.
So the news is... (Score:2)
Re: (Score:3)
The people who I think need to be berated are the folks who write the obfuscated code or do things like overload operators not because they need to, but because they can.
I think you mean beheaded. And their heads mounted on the wall above the server room :)
Obviously he needs to apply the rule... (Score:2)
Agree, but not completely (Score:5, Insightful)
Re: (Score:2)
Rewrites vs refactoring are all to common and this pattern is surely nothing new. One way is to design for change up front. This can be accomplished in many ways, but can be vastly simplified by cgood coupling/cohesion, as well as avoiding any kind of fixed constants. It may make initial implementation slower, but it'd leave the system in a better state for change in the future. Of course this flexability can itself lead to greater complexity, so buyer beware.
Ultimately, we all code in different ways at vas
Re: (Score:2)
Re: (Score:2)
In finance there's the concept of Future Value in which the cost of the present is weighed more heavily than future costs. This also applies more or less to software: we know the here-and-now needs but the future is too murky in terms of product direction or even its very existence.
One can learn a lot about design choices by studying finance theory because it trains you to better weigh probabilistic options and related costs in your mind. (Game theory has some similarities also.)
I look for "bargain future-p
good developers writes good code, bad ones don't (Score:2)
Writing code Simple or Complex really depends on the Developer and the mindset of the developer at the time.
Sometimes the Simple Code actually makes it too hard to manage. Say you are given specs and you find it fits nicely in a mathematical function. So you create that function and it works fine, until a new change happens then you function is just wrong and you need to redo it. However if you make your code a bit more complicated, that change might be just a simple if statements, and you are all set ag
Carpetbombing Philosophy (Score:2, Insightful)
You know what's bad?
An object with a single 2200 line method that takes 70 parameters
You know what's also bad?
300 tightly coupled classes that have no individual use.
Striking the balance is what is really important and there's no one size fits all metric for that beyond peer review.
I find myself cringing every time someone comes in and makes a grand sweeping statement about simplicity or density or whatever else because it ignores problems by carpet bombing a philosophy.
Cyclomatic complexity doesn't mean mu
Re: (Score:2)
Premise is wrong. (Score:2, Insightful)
Any idiot can write complex code.
Bzzt, wrong. It's:
Any idiot can write complicated code.
"rant" is a nice way of putting it (Score:5, Insightful)
"Simplicity is the ultimate sophistication."
-- Leonardo da Vinci
"Plurality should not be assumed without necessity."
-- William of Ockham, often referred to as Ockham's Razor -- the simplest explanation is usually the right one.
"Everything should be made as simple as possible, but not simpler."
-- Attributed to Einstein
"If you can't explain it to a six year old, you don't understand it yourself."
-- Albert Einstein (attributed)
"Truth is ever to be found in the simplicity, and not in the multiplicity and confusion of things." -- Issac Newton
"Beauty of style and harmony and grace and good rhythm depend on simplicity."
-- Plato
"The greatest ideas are the simplest."
-- William Golding, Lord of the Flies
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage to move in the opposite direction."
-- E.F. Schumacher
"Those guys are all wrong."
-- Andrew Binstock, Editor in Chief, Dr. Dobbs
Choose well, reader...
Re: (Score:3)
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.
Antoine de Saint-Exupery (1900 - 1944)
Re: (Score:2)
"If you can't explain it to a six year old, you don't understand it yourself."
-- Albert Einstein (attributed)
Having recently spent time with a friend and her six-year-old daughter, I can honestly, accurately, say that is not true. The kid is really, really smart - for a six-year-old - but, like *all* six-year-old humans, her brain simply isn't developed enough to grasp many - many - concepts. This also applies, to a lesser extent, to gifted kids (my wife was a Gifted Education teacher). In either case, any parents (or Albert Einsteins) who say otherwise are fooling themselves.
interesting topic, disappointing article (Score:3)
Frankly, I was a little disappointed in this article. His arguments seems a bit - for lack of a better term: simple.
Is there anyone out there who is arguing that simple solutions to inherently complex problems exist and are a good thing?
Re:interesting topic, disappointing article (Score:4, Insightful)
Complex problems are defined as problems with no simple solution. The article is not just simple, it's a tautology.
Re: (Score:3)
Frankly, I was a little disappointed in this article. His arguments seems a bit - for lack of a better term: simple.
Well... Any idiot can make a complex argument. :-)
PEP20 (Score:4, Interesting)
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Re: (Score:2)
If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea.
Those two always bother me though because when it comes to software development it always seems like there is an exception to every rule. Something like Ukkonen's algorithm [wikipedia.org] is both hard to explain and a good idea and that's just the first one to come to mind.
Re: (Score:2)
The concept seems more difficult than the implementation in that case, which I don't think is the point of those lines.
I always looked at those lines as don't do result = d.x(y + l.u(v[i[m + 4*t.base(vvv)]])) when you can instead spread it out over a few more lines and make it more readable, less Perly. Either way, you're still going to need the logic figured out, but one is easy to explain and figure out at a glance, while the other is a bunch of back and forth and what the fucks.
No good examples in article so I can't agree (Score:2)
Re: (Score:2)
This guy sounds like he could benefit from reading Clean Code by Robert C. Martin.
I wouldn't be supprised if "Clean Code" is what prompted the article in the first place.
Good design is simpler than no design (Score:2)
Simplicity is word that gets batted around a lot. When it used to mean "the shortest distance to a solution to the immediate problem", you are often trading immediate simplicity for longer term inflexibility.
I've found the simplest solutions are those which are well designed, which take into account not just the immediate problem at hand, but reasonable future variations of that problem. The up front investment in thought and design and pay off in a big way down the road when new problems can be solved m
Sometimes too much of the complexity is hidden (Score:2)
My code is always simple (Score:2)
I limit it to 1's and 0's
Clever code (Score:3)
Everyone knows that 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?
-Brian Kernighan
Re: (Score:2)
"As clever as possible" means "as complicated as possible" here, not as "elegant, simple and clear as possible".
He just redifined everything. Its a strawman. (Score:5, Interesting)
When you redefine your opposition's argument and then knock it down with your own argument it is called a strawman. That's what he just did there.
No one is saying in regards to simplicity that all programs should be two line bits of nothing.
What people are instead saying is that code should be efficient, tight, and achieve the end goal as simply and directly as possible.
What we are and have always been talking about is efficiency. It goes back to the first computers that had very limited memory. They required VERY efficient code because they simply didn't have the storage or memory to run anything that took up more space. As a result, code for those machines tended to be very very efficient. It was a requirement.
When we complain about complexity, we are not complaining that the task of the program is too complex. Rather, we're complaining that the program is badly coded. We are complaining that it is inefficient and disorganized.
So nice try. Try again.
Lame excuse (Score:2)
I'm afraid software developers will read this article and use it as a lame excuse to write complex code, because it's easier to write complex code than to write simple code, though it's much, much harder to maintain, enhance, and debug complex code.
Complex code hides bugs. Complex code is generally less robust and reliable. Complex code usually has more security holes.
Sure, some things have to be complex. But generally, you should strive for small functions (methods) that do one thing, and do it well, and k
Re: (Score:2)
Indeed. And it applies to architecture and design just as well:
"There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult." --Tony Hoare
Writing complex code where simple code would be adequate and much clearer is the hallmark
of incompetence.
Once again reinventing Fred Brooks (Score:4, Insightful)
Brooks made a big point in "No Silver Bullet" about the difference between what he called accidental complexity (introduced by the developers) and essential complexity (introduced by the reality of the problem). And the key thing is that the accidental complexity needs to be avoided or fixed with tools, but the essential complexity can't be avoided.
Re: (Score:2)
Exactly. And where you face essential complexity, make sure what you do is as clear and well-structured as possible. "Simple" does not mean "simplistic".
Funny thing is no real engineers have any problems with that idea or are unaware of it. It is just people in IT that seems to still struggle with fundamental engineering concepts.
Gone are the days (Score:2)
Dr. Dobb's Journal's motto was once "Running light without overbyte." Looks like this valuable maxim is now beyond their ability.
Sometimes it's a good choice to use more complex code when it provides a substantial speed increase. Sometimes it's good to slap something together just so it will run. But if there's no substantial advantage to code that isn't simple, simple is best.
Man bites dog (Score:2)
Black is White. Freedom is slavery. Simplicity is bad. Complexity is good. Binstock is +1 Funny.
what? (Score:2)
The article is mildly entertaining (especially for the awk bits), but the ending is plain stupid, i.e. flat and inane beyond belief ;-)
I don't think that a sane person would explain the apparent improvement of newish cars reliability by the increasing number of built-in programmable gadgets with their millions of code lines. If anything, there is an optimum beyond which the cars will start failing in new and spectacular ways...
The truth revealed (Score:3)
"I had incorporated some sophisticated regular expression pattern-matching.."
So many simple projects turn the corner of complexity, and never look back, right about at that statement.
Workarounds make code complex (Score:2)
A lot of what makes code ugly and complex is working around bugs and incomplete features in languages, database, etc. Every time I start a new project I try to start with a good clean framework. If never fails that you hit a point where documented features dont work and after waisting many hours of research you find the ugly hack workarounds. These acheive the end result but make you cringe when you maintain the code.
It's about the human, not the computer (Score:2)
"Readability and change-ability by future maintainers" should be the primary goal. Obtaining that goal doesn't necessarily lead to the most simplest (smallest) code.
However, it's often a difficult goal to codify (describe precisely) because human psychology and physiology are still half-science-half-art subjects. And, every individual is different and thinks and sees better under different circumstances compared to other individuals.
It's best to get multiple opinions on different styles to try to find a con
Clarity is what is actually important (Score:2)
KISS is not "make it simple". KISS is "keep it as simple as possible while retaining clarity, but not simpler". It is about not adding complexity _unless_ needed. Anybody competent understands that. This "rant" is entirely redundant and shows a lack of understanding of fundamental engineering principles.
Debugging "simple code" sometimes terrible (Score:2)
unemotional? (Score:2)
My view of simplicity is unemotional and free of idolatry
Calling your opponents 'idolaters' is the opposite of unemotional. It is an emotionally charged indication that you don't actually understand the other viewpoint.
How Long Is A Man's Arm? (Score:3)
I think the same applies to code. It should be just complex enough to get the job done. No more, no less. Sometimes that means you're going to have complex code, but it shouldn't be any more complex than it needs to be.
His only source contradicts him (Score:3)
Even the source he cites admits that complex code is a bitch to maintain.
His main point (Score:2)
This brings me to the point that is truly the heart of the matter: It's not simplicity that matters, but readability. Can the code be understood with the least amount of effort given its inherent complexity? That is the true criterion. How readable, or if you prefer, how maintainable is the code with respect to its complexity?
I disagree (Score:2)
Isn't his example arguing against him? (Score:2)
This quote from TFA seems to argue *against* complexity:
"I had incorporated some sophisticated regular expression pattern-matching technology into AWK Brian Kernighan once took a look at the pattern-matching module that I had written and his only addition was putting a comment, 'Abandon all hope, ye who enter here.' As a consequence, neither Kernighan nor Weinberger would touch that part of the code. I was the one who always had to make the bug fixes to that module" (from Masterminds of Programming, p. 103). Complex problems require complex code.
So he wrote some code that was so complicated that no one besides himself is able maintain it. That sounds like more of an argument *against* complicated code than for it.
Note that it's not Al Aho that said "Complex problems require complex code". Is awk still using the same code today, or has it been rewritten to be more maintainable?
tame complexity with useful abstractions (Score:3)
Even very complex problems can be made to look simple at various levels of abstraction. Hiding complexity inside objects that represent real-world objects is a good way to make the code that uses those objects simpler.
In development, plan to do at least one major refactoring after the project is feature-complete to move complicatons in and out of abstractions, add new abstractions or collapse old old ones as needed to make things "feel good".
Elegant (Score:3)
Its been around since the beginning of programming. Get with the program. This is a non-story.
Re: (Score:2)
"Code monkeys" in India are not able to do simple things in a simple way. They have a tendency to introduce unneeded complexity, because of deficient education and lack of experience. I have seen this several times, at least once with project-killing consequences.
Re: (Score:2)
That will fail once you do more complicated things. The benchmark is whether the code with its documentation can be understood in a reasonable amount of time with respect to the complexity of the problem solved. You should make code as simple as possible, but not simpler. You are trying to make it simpler than possible.