Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

This is a question I've been asking myself for a long time. Thought of throwing out it to you.

From my experience of working on several Java based projects, I've seen tons of codes which we call 'dirty'. The unconventional class/method/field naming, wrong way of handling of exceptions, unnecessarily heavy loops and recursion etc. But the code gives the intended results.

Though I hate to see dirty code, it's time taking to clean them up and eventually comes the question of "is it worth? it's giving the desired results so what's the point of cleaning?"

In team projects, should there be someone specifically to refactor and check for clean code? Or are there situations where the 'dirty' codes fail to give intended results or make the customers unhappy?

Do feel free to comment and reply. And tell me if I'm missing something here.

EDIT: I like to emphasize - What I meant by WHY is not the technical reasons, I'm asking about the motive. We all are familiar with why we should write clean code in technical point of view. But, imagine in college if I write bad code, I get bad marks (see @TofuBeer 's comment). So in your industrial environment what motivates you and your team to write clean code? And what de-motivates you and team from writing bad code.

It's so easy to write a method in a class to get the information you need without looking around and checking if there's a similar method!! result-a 5000 + lines of code with few methods doing almost similar tasks. :-(

Do feel free to add comments if you have seen or worked with same code.

share|improve this question
Is it worth the time to clean up the room when your stuff is all over the place? –  BoltClock Feb 22 '11 at 8:34
@BoltClock - That one has been troubling me also for the past 30 years ;) –  Rook Feb 22 '11 at 9:28
cos dijkstra's ghost is looking over your shoulder ;) –  jk. Feb 22 '11 at 18:39
add comment

migrated from stackoverflow.com Feb 22 '11 at 8:37

This question came from our site for professional and enthusiast programmers.

marked as duplicate by gnat, MichaelT, Bart van Ingen Schenau, Dynamic, Kilian Foth yesterday

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

18 Answers

up vote 14 down vote accepted

It's worth it, and it should be done by the whole team. "When it stinks, change it" works for babies & code (thanks, Kent Beck).

Some have said that for a little, short-term project, it's not worth doing. I don't agree. In the first place, we rarely know just how short-term a project is going to be, but in the second place - when it stinks, change it. If it stinks, it's either because you wrote it stinky in the first place - and your team should work on its general coding skills, and refactoring is good training for that - or (more frequently) it has been sloppily patched and repurposed over time. In that case - obviously it's not a very short-term project. If you had the time to stink it up, take the time to change it.

Refactoring - keeping your code from stinking - isn't the responsibility of one designated person on your team, and it isn't the responsibility of the person who made it stink. It's your responsibility and the responsibility of everyone on your team. When it stinks, change it.

share|improve this answer
Thanks, @Shamal, but it's not my concept - it comes from Kent Beck's grandma, as quoted in Martin Fowler's Refactoring. Sorry if I left a contrary impression. –  Carl Manaster Feb 23 '11 at 1:54
You need a definition of "stinks" though. Many programmers will happily spend thousands of hours gold-plating code that would have worked fine and never ended up needing to change, or worse, ended up being deleted because customer requirements changed. Happens a lot. –  MGOwen Jun 21 '13 at 2:03
show 4 more comments

I think that it very depends on your project. If it is a fixed price project done by one person during 1 week write code as you want.

But if the team is larger and the project development takes more time it will definitely require some sort of re-factoring and cooperation between team members during the development. These are the points where you will start to enjoy better design and cleaner code.

share|improve this answer
add comment

I tell my students that this is the order I expect that code be written about (what I care about most to least):

  1. Documentation - if I don't know what it is supposed to do how will I know if it is doing it properly or not?
  2. Formatting and conventions - if I cannot read it how will I know what it is attempting to do? How will I be able to modify it if I need to and it is a mess?
  3. Correct - no point in having a program that produces the wrong result
  4. Fast (a distant fourth) - not much to say here

Simply put, code is written far less than it is read. Not following conventions (style) and writing quick and dirty code makes it much harder to read. SInce reading is the primary activity it saves significant time overall if the code is clear.

share|improve this answer
You don't teach your students to write tests? –  Htbaa Feb 22 '11 at 9:06
Code has to primarily be correct - everything else is secondary. Perfectly documented and formatted code is perfectly useless if it doesn't do what its meant to. –  Ben Hughes Feb 22 '11 at 12:12
@Ben Hughes: Yes that's the ideal, but as we live in the real world I would choose code to be maintainable rather than correct (assuming I can't have both). Correct - but write only code - is no good to me if I've to fix or otherwise change it. I'll just end up writing the damn thing again. –  Binary Worrier Feb 22 '11 at 15:33
@Ben: Say 10% of my coding time is brand new, green fields stuff. The rest is new functionality in existing code, tweaking existing functionality, or bug fixing. As such I spend 90% of my working with old code. One of our products is 10 years old. Lets imagine for the 7 years before I got here devs just jammed in any old crap to get it working, then I arrive and jam in more crap for 3 years. The code is ugly and unmaintainable. Developer moral goes through the floor, new functionality takes longer and costs more. How does that help the people who use the product and who pay me? (cont) –  Binary Worrier Feb 23 '11 at 7:57
... less than a year later the company folded under the weight of multiple lawsuits, their "success" was an illusion. They did not have one satisfied customer. The bottom line is, code no one can work with (or only one person can work with) is of no use to anyone. You seem to think I advocate "shipping broken code", I'm not (because that's just dumb). However, if I have to hire one of 2 devs, one of who churns out working code, that only they can work on, and one that turns out well structured "pretty" code that nearly works, I'll take the second one, the first guy isn't welcome here. –  Binary Worrier Feb 23 '11 at 8:09
show 6 more comments

The question is similar to why we should eat clean food. Simple points you can grep the net on:

  1. Maintainability
  2. Readability
  3. Easy to extend later on.
  4. Shows the character of the developer :)

But the "is it worth" question is little tricky. While deciding on this, you should consider:

  1. How long in future this project might run
  2. How mmore new features are expected to be added in long run.
  3. Risk factor; If its in prod, how risky is it to change (scary)
  4. Do you have enough resources to "waste"(?) on it.
share|improve this answer
That forth point is really important, since a small team can't venture into rewriting code, unless there is nothing else to do (and most probably there is) –  Coyote21 Feb 22 '11 at 14:43
I actually thing it comes down to the pain when talking about the 4th is it worth it. If your entire team is unwilling to work on a section of code or only one person is "qualified" to work on it. It's time to rewrite it. Life will be better if you get the cleaned up. –  Erin Feb 22 '11 at 14:51
I don't think the question is similar to eat clean food. If I eat dirty food, I get diarrhea (I get the pain). But If I write dirty code, someday later someone else will get the pain. :-) –  Shamal Karunarathne Feb 23 '11 at 1:22
show 2 more comments

You start out on a project with initial set of requirements.As the project moves on the requirement keeps changing and there is a need to extend your code.

When we start to write the code we try to make it work to the requirements we have currently and the ones we guess which might show up.

If you dont refactor your code there is a high risk that it will not be easy to extend it or be readable by others.

More over refactoring the code shows how clear you are on what you did and gives you opportunity to correct potential bugs.

share|improve this answer
add comment

My opinion:

It depends! - If the code is meant as a one time development in the style of fire once and forget... then I'd say... no, it isn't worth to refactor it. - If the code is meant to be long living and be reused, then I'd say: write unit tests and refactor step by step, as soon as you have to modify/enhance code in or that uses those dirty part of codes.

You have to find the right balance between risk of breaking working code and benefits in term of maintenance and performance costs caused by the clean-up.

share|improve this answer
show 1 more comment

Your code will be used by other developers. Even more, you will be using your code in future. Thus, if you will invest some time in writing clean code in the beginning, others (and you) will save much more time in future during debugging or modifying your code.

share|improve this answer
Also "used" will probably include "read" and "modified". Modifying ugly code is not fun and it becomes outright painful when it's ugly code written by someone else (or by yourself several months/years ago, which is essentially the same). –  Joachim Sauer Feb 22 '11 at 8:53
show 1 more comment

You're actually asking several different questions here.

Why write clean, refactored code?

One should do this because it makes maintenance and verification of your results easier. If no one but you can understand how your code works without a massive time sink, then they can only take your word for it that it's actually doing what it should. If you're unavailable when a critical problem is found, then it's as likely to be made worse as fixed.

Aiming for maintainability has been one of the commandments of software engineering since the dawn of time.

it's giving the desired results so what's the point of cleaning?

Depending on the expected timeframe of your project, it may not be. If your project is only going to last six months on a very definite timeframe, you can probably get away with leaving things as a mess. Customers generally don't care what's going on under the hood, they just want it to beep and tweet at the right times.

However, if your on something longer term, then maintainability is going to become a large factor. On average, you can expect and should plan to lose key staff if you're on a timeframe of more than six months.

In team projects, should there be someone specifically to refactor and check for clean code?

No, I would say not. The person "refactoring" the code should be the person who originally wrote it, or there's going to be misunderstandings. Much like the rules of database normalisation, if you spend a little time thinking and refactor as you go (opportunities for doing so should be obvious as you work on the code), then there shouldn't be a lot of untidy code lying around for you.

Certainly, don't leave it until after the code is feature complete, as then from the developers perspective their job is done, the feature has been made and they can close the ticket.

share|improve this answer
show 2 more comments

I would put the good points raised by other answers in a slightly different way.

it's giving the desired results so what's the point of cleaning?

In other words "if it ain't broke, don't fix it". Which sounds correct, however it fails to take into account that code can be broken in several different ways - it can be:

  • functionally broken (the most obvious): it does not do what it is supposed to do,
  • incomprehensible: it is hard to read and understand, so it is not even clear what it is supposed to do,
  • untestable: it is hard or impossible to unit test it,
  • unmaintainable: it is hard to maintain and extend it - this is usually a close consequence of it being hard to read and/or unit test.

Any of these can hinder or even kill a project in the long term.

share|improve this answer
add comment

Reducing internal quality slows you down.

If you reduce internal quality, producing desired results in the future will take longer and longer, with increasing risk.

If you carefully choose the right thing first - getting the most value first - then in my opinion, it's almost always worth it to make the thing right.

Also, take a look at Martin Fowler's excellent article: http://martinfowler.com/bliki/TradableQualityHypothesis.html

(Paraphrased quote: As soon as internal quality is framed as tradable, the developers, management and their customers have already lost.)

share|improve this answer
show 1 more comment

Dirty code hurts when you have to work with it. Working with it means fixing a bug that relates to the code or adding a feature around the dirty code. I don't think there is much value in going in and refactoring code arbitrarily; code should be refactored when you are touching it to fix a bug or add a feature. In general, I love the Clean Code book idea of relating to what the scouts say: Leave the camp cleaner than how you found it!

If this is followed your overall cleanliness (and quality) will improve overtime, while the risks of (for no reason other than cleanliness) changing code that is currently working will be minimized.

I don't think that after-the-fact reviews to make sure code is clean will work, and having a person that exclusively refactors won't work either. As a developer I think we should all eat our own food. So we should be in charge to make good food.

If someone keeps bringing rotten apples to the potluck, the rest are bound to make him/her change or make him/her go...nobody wants to eat rotten apples. We should all be bringing awesome food to the pot luck.

share|improve this answer
add comment

Rewriting code to make it "clean" or "neat" shouldn't be undertaken lightly. Unless you have time to really get to know the code first you're liable to make mistakes that can be very hard to catch yet make parts of a system that have worked reliably for years fail in mysterious ways.

I'm working on such a task myself, where things had got too far out of hand (God class anti-pattern, anyone, massive copy-paste programming, etc.). There I had the time, and still I only did a small part of what I'd really have liked to do because I'm not confident to do everything, the changes needed to really make it quality code would be too great and would effectively mean a rewrite which is way out of scope of this project (what I've done is mainly make the code a little easier to read so I could find places I needed to make changes intended for the project, and centralise those changes rather than sprinkle them all over the place). And even such a limited change (limited, as in reducing the existing 9500 line class to 8100 lines, a real refactoring would split it up into several dozen other classes and probably introduce a complete database access framework like iBatis) has risks attached to them in that it requires a complete retest of the entire application which might yield problems introduced by the change. I've only done it because a complete retest was already called for because of the impact of the very minor changes I ended up making to the functionality (rather than the technical implementation) of the system.

share|improve this answer
add comment

From business point of view I don't have big objections for one-off dirty code if it works. There is a lot of crappy software making money for business.

But good habits and programming skills are not coming from nowhere, they have to be developed. Writing good code is a great exercise for writing good code. More good code developer writes, the easier it becomes to do. It is quite natural to write good code, it is not harder or slower than writing dirty code, this is just an experience + good habits and this experience and habits can't be obtained by writing dirty code or just by reading books. So don't write dirty code and don't let your team do it and you'll be a better developer with better team in some time. Business tasks and deadlines go, skills stay.

share|improve this answer
show 2 more comments

Everyone's already answered the question well. But the decision point for me on whether it's worth it or not largely depends on whether the app is going to change more over time. As everyone else has said, if it works and doesn't need to change, move on to higher priority things. But if you're going to have to keep changing it, then not refactoring for cleanliness and efficiency will cause problems down the road.

I worked on a really rotten app once that when originally written was small and fairly easy to deal with. As years of additional features and hacks and sloppy fixes kept adding up, the analyst on the team commented once, "What I find most difficult about the app now is how long it takes to change it." Even doing impact analysis for a new change could be costly.

However, the answer to your question, particularly when considering the motivation part, will be different depending on who you ask. For an internal IT app, where the cost is paid for by free overtime hours, developers would want to improve the internals while few managers would be interested in changing them. For a shop where velocity of evolution is important in time to market, quality could provide a strategic advantage, if you had management that believed the speed of changing a well-built app exceeded the speed of hacking a new feature in. And sadly, even in some true software shops, I get the sense that a lot of managers decide that hacks are faster. Maybe they are, but again, the ongoing pain is usually felt by the developers and not others in the organization.

share|improve this answer
add comment

I see two main motives:


Because the person who will have to maintain the code may be a psychopath who knows where you live. Or worse, you may be the one maintaining it and by then, you will have forgotten everything about how it is structured internally.

Easier to debug

It helps having solid foundations to build upon when you need to add more features, that way it's faster to identify where bugs come from.

share|improve this answer
add comment

It is essentially a question of money.

The better the code, the easier (and cheaper) it is to maintain. Both for others but also for those who originally wrote it.

Unfortunately, this experience cannot be properly communicated without actually trying it, which means that there can be a very large codebase which needs a lot of work to get into a reasonable state, which means that it is no longer the cheapest to do it right because you may have to rebuild too much. That's the dead-end many experience.

If you need to explain this to non-technical people then compare it with a house. If the basic blue-prints are not sound, then you will need to do a lot of extra work and you still have an inferior house.

share|improve this answer
add comment

Consider the implications of the FizzBuzz examples in this article. The two versions, and their modifications, give the same respective outputs, but which would you want to maintain, especially in an environment with constantly changing requirements?

My advice: When under tight scheduling constraints, if the code ain't broke don't fix it. When schedules become looser and deadlines are no longer looming, take the time to fix the most problematic or least modular code, but always within the guidelines of the overall system architecture.

share|improve this answer
add comment

To me in practice this question translates to 'Why write smaller code?', because in practice smaller, more unit-able blocks of code invite the possibility of nicer and cleaner design. Manipulating theses smaller blocks becomes much easier than the large ones, and they are more inviting to be refactored as needed.

Now, my answer:

after mulling over some significantly decent legacy code base refactoring, it has been my experience, that large blocks of code (classes, functions, etc), invite more code. More code applied indiscriminately breaks up the things like responsibility principle, and other best practices.

So my answer as to why write smaller code?

  • it forces you to think about your code structure and layout more, while preventing mentality (and sometimes necessity) of "let's stuff more stuff into this code block". I say necessity, because when coming across a huge block, it may be necessary to make things work now, rather than take time to refactor, due to time pressures.

  • It is easier to do refactoring work on a set of smaller self-contained code pieces even if they are ugly than to work on breaking up huge entangled ugly methods.

  • it helps future programmers who will be working on your code base to figure out what you were doing. While not always true, smaller units of code that have their purpose and that are reasonably self-contained, will help you build a mental model faster than long ambiguous everything code spans.

  • it prevents future programmers from moments of what the [heck] was this code supposed to be doing? and why does this or that code piece doing these things in this particular and peculiar way?, as large code blocks tend to hide bad practices and various bugs and logic errors.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.