Linked by Thom Holwerda on Wed 26th Sep 2012 23:25 UTC, submitted by MOS6510
Permalink for comment 536655
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
Features
Linked by Thom Holwerda on 06/13/13 14:35 UTC
Linked by Thom Holwerda on 06/11/13 17:07 UTC
Linked by Thom Holwerda on 06/10/13 23:13 UTC
Linked by Thom Holwerda on 06/08/13 14:57 UTC
Linked by Thom Holwerda on 06/07/13 11:40 UTC
Linked by Thom Holwerda on 06/04/13 12:45 UTC
Linked by nfeske on 05/31/13 10:12 UTC
Linked by Thom Holwerda on 05/29/13 16:59 UTC
Linked by Thom Holwerda on 05/24/13 17:26 UTC
Linked by Thom Holwerda on 05/21/13 21:38 UTC
More Features »
Sponsored Links



Member since:
2007-03-26
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