Slashdot Mirror
Dr. Dobb's Calls BS On Obsession With Simple Code
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.'"
Everything should be made as simple as possible, but not simpler.
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...
I have often noticed that complexity is added to code when it grows over time. Typically, a project starts off very well. We have requirements and we use the best possible design with limited future expansion capabilities and come up with simple code that works well. However, over time, things change and we come across situations that the original code cannot handle. But instead of writing from scratch, we hack it and that is how complexity and subsequently bugs get added. In my experience, the base infrastructure code for any system always looks simplistic and beautiful. The ugly part is often how it has been used over the years.
"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...
#fuckbeta #iamslashdot #dicemustdie
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.
Last post!