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 536639
To read all comments associated with this story, please click here.
That depends
by franzrogar on Thu 27th Sep 2012 08:54 UTC
franzrogar
Member since:
2012-05-17

For me, better code means any other person can understand the workflow and the purpose of that code without needing 1,000 pages long manual/information.

That means, in most scenarios, that the code will be suboptimal (when compiling and running it).

So, the real question would be "code faster or code readable"?

Reply Score: 2

RE: That depends
by Laurence on Fri 28th Sep 2012 06:19 in reply to "That depends"
Laurence Member since:
2007-03-26

For me, better code means any other person can understand the workflow and the purpose of that code without needing 1,000 pages long manual/information.

That means, in most scenarios, that the code will be suboptimal (when compiling and running it).

So, the real question would be "code faster or code readable"?

Sub-optimal code would be useless for kernels or real time systems.

Plus the reason for code comments is to make code readable. So there's little point, in my opinion at least, of writing deliberately crippled code just to make it readable.

That said, I don't agree with needlessly obfuscating code just for the sake of gaining a few clock cycles either.

So we're back to the earlier points at the top of this discussion: that there's a time and place for every methodology.

Reply Parent Score: 3