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 536655
To view parent comment, click here.
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"
Laurence
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

Reply Parent Score: 5

RE[2]: Eloquence
by Lennie on Thu 27th Sep 2012 11:07 in reply to "RE: Eloquence"
Lennie Member since:
2007-09-22

My point was: if the programmer sucks at programming you'll probably end up with much more code which ends up doing the same thing just slower and probably more buggy.

Reply Parent Score: 2

RE[3]: Eloquence
by Laurence on Thu 27th Sep 2012 11:27 in reply to "RE[2]: Eloquence"
Laurence Member since:
2007-03-26

My point was: if the programmer sucks at programming you'll probably end up with much more code which ends up doing the same thing just slower and probably more buggy.

Yeah, but that's got nothing to do with this topic what-so-ever as crap developers will write crap code irrespective of best practises.

Reply Parent Score: 2

RE[3]: Eloquence
by lucas_maximus on Thu 27th Sep 2012 17:56 in reply to "RE[2]: Eloquence"
lucas_maximus Member since:
2009-08-18

Generally yes, however I see regularly where people have just put in a try ... catch instead of actually understanding and dealing with the route cause (Checking for the obvious condition, such as null object).

Most bad code comes from one of the following:

* Inexperience.
* Not Invented Here (NIH) syndrome.
* Re-inventing the wheel.
* Not using standard libraries (inability to Google or use API docs).
* Lack of coding standards or code reviews.
* General Management WTFs.
* Policy problems (you are not allowed to change this because of x, y and z, which are all retarded problems)
* Hacks due to laziness, or lack of understanding (happens a lot in Web development with either JavaScript or Internet Explorer).
* People that don't have any professional integrity.

Reply Parent Score: 2

RE[2]: Eloquence
by zhulien on Thu 27th Sep 2012 11:44 in reply to "RE: Eloquence"
zhulien Member since:
2006-12-06

Agreed, shorter code much of the time is slower, it can sometimes be more difficult to understand if the complexity to make it shorter increases (not always). The fastest text output routine for example on the Amstrad CPC is about 2 kilobytes because it has masses of repeated LDIs and sequential arithmatic operations without many loops where-as the simplest is about 25 bytes - but takes ages comparison to render - important when you are trying to synchronize things in a Demo or Game, but less important when writing a business application - but then that 2 kilobytes might be more precious than the speed - ah such trade offs... to achieve 'better' code.

Reply Parent Score: 2

RE[2]: Eloquence
by DeepThought on Thu 27th Sep 2012 18:18 in reply to "RE: Eloquence"
DeepThought Member since:
2010-07-17


shorter code != maintainable code.


Hell, no. Or yes ?! Your point is to general. I'm sure any decent programmer wrote code that proves your point correct and also wrong.

Reply Parent Score: 1

RE[3]: Eloquence
by Alfman on Thu 27th Sep 2012 19:56 in reply to "RE[2]: Eloquence"
Alfman Member since:
2011-01-28

DeepThought,

That's the problem, these are nice abstract ideologies but they're meaningless in practice since everything is relative. Write as much code as you need, but no more! Well, that almost goes without saying, but it doesn't acknowledge the evolutionary processes that software undergoes to get from A to Z. Like others have said, sometimes more code is better than less, there are so many factors that need to be considered (ie modular versus hardcoded, efficient vs simple, quickly hacked together vs long term managability). It would be ignorant to push forward an absolute ideology up front without even taking into account the specific requirements of a project.

Reply Parent Score: 3

RE[3]: Eloquence
by Laurence on Fri 28th Sep 2012 06:10 in reply to "RE[2]: Eloquence"
Laurence Member since:
2007-03-26

"
shorter code != maintainable code.


Hell, no. Or yes ?! Your point is to general. I'm sure any decent programmer wrote code that proves your point correct and also wrong.
"

Which is exactly what I said.

Edited 2012-09-28 06:13 UTC

Reply Parent Score: 2