Inheriting applications at a new job...

Question

When inheriting applications at a new job do you tend to stick to the original developers coding practices or do you start applying your own?

I work in a small shop with no guidelines and always wondered what the rule was here. Some applications are written very well but do not follow the standards I use (variable names etc...) and I do not want to "dirty" them up. I find my self taking a little extra time being consistent.

Others are written very poorly and it looks like the developer was changing his mind every keystroke...

ADDITIONAL THOUGHT

What about when I start my own projects? So now I have introduced a new coding standard to the mix:

1. The good code - but not my style
2. The bad code with bad practices and lack of standards
3. My own standards

Answer 1

If there are standards evident in the code, you should stick to them. If there aren't, start introducing your own.

Answer 2

If it's just you, go for it. If it's a team, especially if any of the original developers are still around (or likely to be called in for consulting), keep with the existing style and practices as much as you can. Don't follow them down a rat hole - if you think they're doing something stupid, change it, but if it's just a stylistic thing, keep to their style as much as you can.

On several jobs I've been on, we had no rule on coding style other than "if you're making changes to an existing file/class, use the existing style, even for new code."

Answer 3

If I inherit code that has obviously never been refactored, I would take that as an opportunity to impose some of my own structure.

If people expect me to make time and cost estimates for adding functionality to the code, I'll need to be intimately familiar it, and make sure it lives up to my standards.

If the code is already well-written, that would be a blessing that I would not mess with. But in my experience, this hasn't happened very often.

Answer 4

Publish a style guide that follows best practices, and build consensus around following it. Refactor old code as you need to maintain it.

Answer 5

I think it depends on what you mean by "coding practices". If you mean things like code formatting and naming conventions and things that I would personally consider "cosmetic", then stick with whats already there. If you mean things like coding best prcatices and writing code correctly in the first place, then go back and fix the problems if possible, but at the very least make your new code follow best practices.

Answer 6

I'm in the same boat as you. Lone developer who inherited some apps from the last guy. I

I've been sticking to what appear to be his standards for existing projects for consistency, and using my own preferences for new stuff.

Answer 7

Given that most of the applications I've inherited have been hacked together by "cowboy coders" who didn't apply even the most basic of coding practices, my opinion is a little biased.

I say introduce coding standards if there are none or the ones that exist are blatantly wrong and/or stupid (e.g. "All variables must be no more than 4 characters in length", "Every database column is varchar(255) null", etc.). Obviously if you have a team then you'll need to come to an agreement as to what practices to implement, but if you're a solo dev then you have free reign and IMO you should introduce order to the chaos.

Answer 8

• If the code works, and seems to have had a clean format. Don't waste time changing the style.
• If the code is badly written. By all means change it when you have some down time, or the next time you work on the project.
• For new projects do them your way, since there is no standard. As with the other well written programs yours should be easy enough to maintain.

Answer 9

I follow company standards if there are any.

If there aren't any and the changes are small, I adopt to the used style of coding.

If there are larger changes to be made and I don't like the coder's style, I will use my own. And if the existing code is bad I will change that too.

Answer 10

Will you ever have a better opportunity to update existing code with a standard style? Probably not. When you are new to the code you are going to have the best chance of taking some extra time to make non-new-feature and non-bug-fix changes. The lack of standards may be discouraging but you are unlikely to have a better chance to standardize than when you first inherit the code.

Answer 11

It sounds like we're talking about a situation with no official style guides / best practices. In that case, as Sean said, I'd take the lead on establishing some. But... if at all possible, pick an existing, widely-used standard. It's more likely to be accepted, all the arguments are done with, and the odds of out-of-the-box tool support (editors, code review tools, etc.) greatly increase.

Getting others to adopt it will often work best from the bottom up -- write new code to the new standards, mention to others that you've done so, ask for feedback. Much easier than trying to get approval and buy-in in advance.

Within the existing, ugly project, avoid wholesale changes to existing modules. For one thing, diffs and version control will get quite confusing if a file is suddenly reindented.

If the chunk you're working on is so bad as to be unreadable, I'd do an initial checkin just to reformat it; follow that up with actual code changes.

Answer 12

I would apply the same refactoring standards to the code as I would if it DID match my style standards. That is, I'd ignore the style and just go on about my business.

If it's not terribly difficult to follow the style that is in the code - with regards to naming conventions, I'd go ahead and use those for new code.

However, I wouldn't bother trying to follow stuff like 'tabs should not be used', 'every line should be indented 2 spaces', etc. There are plenty of editors out there where you can 'pretty' the code whenever you need it these days.

G-Man

Answer 13

I think it depends highly on the specific case.

• If you are a consultant on a project for a short time you should stick to the way thing are.
• If you are on for a long time. Try to refactor bad code into your own scheme.
• If you are on for a short time but you are working on an isolated module, then use your own scheme.

Answer 14

If there are multiple developers who work on the same module, don't change the style.

If you will hand it off to another developer in the near future (this role is temporary), don't change the style.

If you are taking complete, exclusive, permanent ownership of the module, change it, but follow these rules:

One change at a time.

Fix all indentation to your liking at once, and commit that change.

Fix all brace placement to your liking at once, and commit that change.

Fix all other formatting to your liking at once, and commit that change.

Fix all naming to your liking at once, and commit that change.

Don't spend a lot of time on it.

If it takes more than an hour or two, then cut back.

Make the commit description clear.

So you can quickly ignore these changes when analyzing change history.

Use automated tools

to make sure the result is consistent and complete, so you don't have to mess with it again.

Run your tests

Just because your changes shouldn't affect behavior doesn't mean they won't. (Triple negative, ouch!)

Make sure everyone knows what you're doing

Someone might have a change hanging around that they want to commit now, and it'll be painful to merge with your changes. Also, you don't want anyone to get surprised and go tell your boss before you do.

Don't do it again

This is a one-time thing.

Answer 15

I've noticed that most people think whoever came before them had no idea how to write code. Then whoever comes after them thinks the same thing. Some things are common sense, but most things are just personal preference.

For major problems, i.e. using comments v.s. not using comments, updating the code will probably make it easier to work with, and easier for anyone else to work with. Even then, your time is probably best-spent updating the code as you come across it, instead of embarking on a huge project to refactor everything (introducing new problems in the process).

For things like indentation, line spacing, variable names, one-line ifs v.s. multi-line ifs, the reality is that your coding style is likely just as bad as you think theirs is.

Answer 16

Short answer is, "It depends." Here are a few factors that I'd consider important in determining whether to keep the old style or not:

1) Scope of changes. If it is close to a total re-write of the application, then it may make more sense to put in a new standard if you have one that you feel works well for you.

2) Likelihood of future changes. Will this be changed over and over again? If so, then taking some time early on may well be worth it in the end. This does require a bit of judgement and predicting the future, but it may be easy in some cases to see that there will be changes over and over again for some systems that are fairly complex.

3) How much of the code is a customization on a 3rd party codebase, e.g. a company's specific customizations of Oracle products for their business processes, compared to a completely home grown application. The impact here is that when new versions are relased and an upgrade is requested, how much pain may there be on what breaks since it was customized so much.

When starting your own projects, put in the best standard that you know.

Answer 17

composition is often preferred over inheritance

:-P