tags:

views:

478

answers:

10

When contributing to a very old, and apparently no longer maintained, open-source or public domain project, is it suggested practice to follow the original author's coding style even if it is terrible?

More importantly, are there any reasons why one would want to follow the original author's coding style rather than clean it up significantly?

+6  A: 

If you know that it's unmaintained, and you're making changes to it, then I suspect that you'll become the defacto owner/maintainer going forward.

So, that said, I'd e-mail the original author/maintainer, see what they think about the formatting or style changes, and go forward with guns blazing.

slacy
+2  A: 

If you're not submitting patches, then no. Run it through a code filter and automatically format the code in your preferred style, then hack away.

eduffy
A: 

If it's not even maintained why are you worrying about it?

I'd write using my own preferred style, and clean up any code I had to work with. I do that regularly at work even...

Telos
+40  A: 

Follow the original coding style. It is far, far better to be consistent, even if it's not pretty to you.

If you do decide to clean up the coding style, do it separately from any other changes. Don't clutter up source control diff's with style changes. Make one (or several) checkins where the only thing you're doing is changing code style. Do not mix in real changes with meaningless changes, it makes it impossible to locate relevant changes when reviewing source control commits.

Adam Rosenfield
+1 - The only time I would go against this advice is if the original code style was horrible *because* it was inconsistent.
Bill the Lizard
+1 for separating commits of code changes vs. style changes
crashmstr
Well put. +1 for talking about messing up the diffs: that is a HUGE issue. I've also seen bugs introduced after "code reformatting" when, for example, people dropped in (or removed) {}'s which caused issues.
DarkSquid
A: 

Well, I'd say if you are just making a small modification within say a function, it might be clearer to go along with the bad style.

If you create new methods, classes, properties, etc., use a clear, efficient style. You might add a comment at the start of these sections, so that others can understand what's going on. You might even add a short note at the top explaining when you started on the code, and that you were using a different style, etc.

alchemical
+2  A: 

If checking into source control, you may want to leave it alone as all the style changes will make comparing to previous versions impossible.

If you do want to change the style do it with the baseline code before you make any other changes and then check it in.

Then check it out and make your coding changes. That way it will be easier to track your changes from the point you took it over.

I personally would leave the style alone unless you are making significant changes.

Jeffrey Hines
+1  A: 

Heck no! Whatever you do don't make it worse for heavens sake!

If you're adding your own code do it in your own style. This will at least make part of the codebase easy for you to maintain and understand. If you're making minor updates to existing code then you may want to follow that style.

I'm in the same boat, I have to maintain an ancient, business critical, Access 2 based system which is a complete mishmash of styles.

Simon
A: 

What would your answer be if the question were: Should you maintain the same shoddy workmanship when you are remodeling your home?

If you're fixing a broken wall tile in the bathroom, then it's not worth re-tiling the entire wall because they didn't use the right drywall.

When you're remodeling the kitchen, then you may correct the plumbing for that room or straighten out a bad floor. That's because it makes the rest of the job easier for you. And that's what it's all about, what kind of benefit does it give you verses the cost to you/your client.

You wouldn't rewire a lamp because it needed a new bulb.

Dr. UNIX
A: 

If you're coding to a company-defined standard (or even just a team-defined standard), and the code that you're working on does not match the standard (or is so old that it doesn't match the current standard), then definitely clean up the code if you're going to be making major changes anyway. (As others have mentioned, do that to the baseline code, and check it in. Then check it out again and make the changes that you have to make to fix bugs, add features, etc.)

RobH
+2  A: 

As stated by others, ensure that any style modifications are checked in to your version control system separately from your functional modifications.

However, my suggestion is to be bold and clean up the code as you see fit; "Leave the campsite cleaner than you found it". Cheesy, but true ;)

Just make sure that you are prepared to defend your changes ;)

Rob Cowie