Code Base with awful code conventions, follow them?

Question

With no time to refactor, when you are working on legacy code, with the most awful conventions, what is the best practice?

Will trying to follow better coding style would improve readability or actually hurt it?

For example, in java method names are usually camel cased:

myGoodNamedMethod

But in the repository there are code with methods like this (not all, but the majority)

my_c_style_method_that_looks_off_in_java

• James: Stick with what's there. No programmer likes another programmer's coding style

Answer 1

No matter how odd you find the existing conventions, FOLLOW THEM. Having some conventions, even if you don't like them, is FAR FAR better than not having any.

Obviously that's not always true (some conventions are outright hostile to getting work done, like limiting all names to 8 characters for no good reason), but except in the most extreme cases, just follow what's there.

Answer 2

Follow the existing standard.

However, if there's a genuine need to fix it (it's becoming a major problem), take a deep breath, man up and refactor the entire code base to follow a new standard. But only do this if it's truly necessary, have everyone's approval and if you have the time. It probably won't take as long as you might think, but do your research first.

Answer 3

Follow the existing standards. Maybe they're outdated/odd/wrong/unpleasent. (as long as they're not being hostile as @Michael Kohne mentioned).

There could be reasons outside of the language standards to be using the naming style. I have heard of people running 3rd party applications over the code base to pull out names for use later. Eg test names as requirements or auto building api documentation.