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:

I have been contracted to modify an application for a software company and the source code is quite frankly, a mess. It's not commented much and the author is inconsistent with coding conventions. The guy seems experienced , but his style isn't great.

What do you suggest doing to get the project done properly and to make thing easier?

Edit

I didn't mean to say rewrite, I've been hired to modify the the UI in a certain part of an app. I don't think that the client cares so much abut what I do to the source code , so long as it works and so long as it's decent quality code. That said, I've expanded some

if(condition) ? TrueResult : FalseResult;

for readability. While I don't think those particularly make bad code, there is an inconsistency in the style throughout the code and a few "left over" constants that don't seem to be used anywhere. There are also some arbitrary numbers where constants would Have been wise for readability's sake.

It's not as bad as I initially had thought, but I still have some questions for the original developer.

share|improve this question

marked as duplicate by MichaelT, gnat, thorsten müller, Jalayn, World Engineer Apr 17 '13 at 13:29

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.

13  
nuke it from orbit, its the only way to be sure –  Muad'Dib Dec 24 '10 at 0:04
    
What is the motivation behind the rewrite? –  Beth Whitezel Dec 24 '10 at 5:47
2  
Sometimes, what looks like a mess is complicated for good reason. There are plenty of bad coders out there, of course, but it's very easy to mistakenly see code as bad when it's about as good as it can be. The reasons for the apparent bad often aren't as obvious as the bad itself. Commenting level is also difficult to get right. Too much is clutter, and suggests the code itself isn't written to be readable. How much is needed depends a lot on who is doing the reading. Also there's not much point commenting for day 1 newbies - they don't stay that newbie for long. –  Steve314 Dec 24 '10 at 6:44
2  
I don't think this question can do without a reference to Startup suicide: rewriting the code –  Erik Romijn Mar 1 '11 at 20:41
1  
don't you mean condensed, Ternary statements are not cryptic or obfuscated in any way. –  Jarrod Roberson Jul 17 '12 at 4:43

6 Answers 6

up vote 21 down vote accepted

If you are a contractor, you write the new code as the customer wants and do not do anything with code the customer do not want you to touch.

Discuss it carefully with the customer to be certain that you are fully agreed.

It might well be cheaper for the customer to have some more code in the style you disagree with, instead of a major rewrite, and if you do a good job you might be contracted again for working towards what you envision.

share|improve this answer
4  
Also it is a good exercise. It takes a very good actor to play a bad actor. Same thing goes for programmers. –  user1249 Dec 24 '10 at 23:35

If you've really been hired to rewrite it, take what bits you can salvage and start from scratch.

share|improve this answer
1  
+1 - Keyword: Rewrite! –  Walter Dec 24 '10 at 0:34

Depends a lot on just how bad the source is, it also depends on the language, or at least the original developers idiom. (It's possible to make a mess in any language.)

If it's possible to write tests for some (or all) of the existing functions, then get a suite of tests in place and try to refactor from that point.

If you are dealing with giant/multiple responsibility functions, poor access control (ie. global variables) and other similar horrors, try to assess the payoff of either refactoring or taking a top-down approach to the application. Often you will find that there is a tipping point between refactoring existing code, and re-implementing the solution from the top-down.

Even if you do have to start from the top-down, you should make yourself as familiar as possible with the existing code base, as there may be salvageable code, but certainly be as clean as is practical in creating the new version.

share|improve this answer
    
+1 for "depends". Worst case you should use it to understand the problem and requirements. Best case you could get away with refactoring and reusing parts of it. I guess my question would be what is the motivation behind the rewrite? –  Beth Whitezel Dec 24 '10 at 5:47
    
+1 - for the second paragraph, nice advice... will keep this in my mind! –  k25 Dec 24 '10 at 6:30

Rewrite from scratch? There's a little bit too little information in your post about the constraints you are working under. Compare how much work it would be to continue with the current code, compared to rewriting from scratch. Rewriting is easily underestimated though.

When thinking about a rewrite from scratch, also have a look at Joel Spolsky's article, saying "code does not rust". Reusing someone else's code is harder than writing it yourself, making it easy to complain about someone else's code and say it must be rewritten.

That said, there are many cases where the existing code is just a crime against humanity and should be replaced.

I would also suggest that, if possible, the original author joins or is at least involved in the rewrite effort. Providing that they are willing to learn. The original author knows why things were done in certain ways and what walls you may run into. Involving them may help the result become better and help them to learn to write better code.

Picking specifically on a lack of comments: that is not always a bad sign. I believe code should be completely self-explanatory in an ideal world, therefore not need comments. So every time I write a comment in some code, I ask myself: is there any reasonable way to change this code, so that the comment is obsolete?

share|improve this answer
    
+1: Just because that method has grown ugly warts on it doesn't mean you should throw it out. –  snmcdonald Jan 7 '11 at 6:53

I've been doing that same thing but unfortunately i had to mantain the code while i'm rewritting it. So my advise is, try to understand the work flow and find the "use units" (logic units that interact with each other to generate the workflow). Once you undesrtand one of them, replace the code with your own, test if it does the same thing and then go to the next one.

share|improve this answer

Delete old code and just rewrite it.

share|improve this answer
8  
also known as the single worst strategic mistake to do in our industry. –  Matthieu Dec 11 '11 at 20:33

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