Linked by Thom Holwerda on Wed 26th Sep 2012 23:25 UTC, submitted by MOS6510
General Development "Having read this, one realization is that better code often means less code. I don't think about lines of code exactly, or something similarly stupid, but in terms of meaningful code. However, argument for less code isn't about making code as compact as possible, avoid redundancy, etc. The argument is about not writing code at all whenever reasonable or possible. Should we focus on deciding what should and what should not built instead of polishing our software development craft then? Yes and no. Yeah, I know. Exactly the kind of answer you expected, isn’t it? Anyway, you can't answer this question meaningfully without a context."
Thread beginning with comment 536617
To read all comments associated with this story, please click here.
The Dao
by kwan_e on Thu 27th Sep 2012 05:18 UTC
Member since:

"The Dao that can be spoken is not the Eternal Dao.
The name that can be named is not the Eternal Name."

You can't really define the best code until you've come across it, and it's usually not very general purpose.

Personally, I find the Halstead metric a good heuristic while I'm writing code. I think it's much better than Cyclomatic Complexity because it is more cargo cult programming than scientific. A problem requires as much cyclomatic complexity as needed, not some arbitrary number.

However, the number of unique operands and operators over the total number of operands and operators in use are still a very good sign of whether you've overcomplicated something. It's also somewhat generalizable to design as well replacing operands for classes/servers/clients/subsystems and operators for states.

Keep one or the other as low as possible while coding/designing/documenting.

Reply Score: 2