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."
Permalink for comment 536655
To read all comments associated with this story, please click here.
RE: Eloquence
by Laurence on Thu 27th Sep 2012 11:04 UTC in reply to "Eloquence"
Member since:

shorter code != faster code.

For instance, if I were writing a video codec, faster and better code would be using hardware frame buffers as opposed to purely software rendering. However using hardware acceleration adds a lot of code as well as complexity.

shorter code != maintainable code.

Modularising code can lead to easier debugging (as classes can be tested in isolation), and better maintainability in many cases too. However modularisation produces more verbose code.

However I think the OP was the most accurate when he stated that "Better code is better because it suits it's task better" - ie there is no definitive rule stating code most comply to x, y and z as the circumstances will vary depending on the project. (case in point, I've written some horrible kludges before because it made the most sense for that particularly project to patch the code in the crudest possible way given the time constraints and the (lack of) significance of the routine that was being patched).

Edited 2012-09-27 11:10 UTC

Reply Parent Score: 5