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.
Why write clean, refactored code?
language agnostic;coding style;refactoring;clean code
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.