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 536844
To read all comments associated with this story, please click here.
RE[4]: Eloquence
by henderson101 on Fri 28th Sep 2012 11:51 UTC in reply to "RE[3]: Eloquence"
Member since:

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