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 536656
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Eloquence
by Lennie on Thu 27th Sep 2012 11:07 UTC 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[4]: Eloquence
by henderson101 on Fri 28th Sep 2012 11:51 in reply to "RE[3]: Eloquence"
henderson101 Member since:
2006-05-30

Most bad code comes from one of the following:

* Inexperience.


Oh, gosh, yes. Agree. And this has nothing to do with experience or how long the coder has been programming. I regularly see clangers from people who should know better.


* Not Invented Here (NIH) syndrome.

That's relative. I've written code to do a very specific CRUD/persistence layer, for example, that would have been just as simple to write using another API. Except, given we were using MS.Net 2.0 at the time, Linq was an Alpha when we started the project, and most other suitable persistence frameworks were fighting against the goals of the project. What we really needed was NOSQL, but that wasn't a well known concept then.


* Re-inventing the wheel.


Again, relative. As with above - we did reinvent the wheel. But as noted, we needed something that worked. Reflection and custom crafted SQL worked just as well to produce results.


* Not using standard libraries (inability to Google or use API docs).


Depends on what you are trying to achieve. I'm sorry, this really does contradict the "don't re-invent the wheel" ethos.


* Lack of coding standards or code reviews.


Bane of my life. I hate external contractors with avengence.


* General Management WTFs.


Like farming out all money making projects to a third party and then wondering why you are skint? Yep. Been there.


* Policy problems (you are not allowed to change this because of x, y and z, which are all retarded problems)


Sometimes legacy code is legacy code for a reason. Sometimes keeping the status quo and quietly redeveloping the back-end is a better prospect.


* Hacks due to laziness, or lack of understanding (happens a lot in Web development with either JavaScript or Internet Explorer).


Having supported a number of legacy systems, I feel this pain regularly. But, sometimes hacks are a means to an end. If you are supporting legacy software with minimum development and no budget, you hack and patch. If you are working on a bluechip level product, no, you don't do that. Horses for courses.


* People that don't have any professional integrity.


That depends on the culture. It's hard to care when no one around you cares.

Reply Parent Score: 2