How do you work with a programmer with a radically different coding style? [closed]_问答_开发者

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 9 years ago.

Has anyone worked with开发者_高级运维 a programmer with a radically different coding style? How do you jive together without wanting to delete and rewrite each others code?

Pick one and go with it.

If you are finding it hard to agree, take the time to list pros and cons including:

tool support for auto formatting (offhand I know Eclipse and Visual Studio can do this with a settings file)
conformance to general industry standard (Sun have published standard conventions for Java, perhaps there is an equivalent in your language?)
conformance to, or cost of modifying, pre-existing source (if you have a million lines in one style, how hard will it be to update that code to the new style?)
... any other factor which either of you find is important (this can include the cost to become familiar with the new style)

If you find yourself working with someone too stubborn to change and adapt, well, you have a bigger problem than clashing code style, and dealing with that is out of scope for this question.

If you are the person to adapt your style, avoid the statement "Well if we had chose my way...". If you have agreed on a single style, fully commit to it.

Before getting to this point though, you should probably ask yourself: what are the benefits of having consistent code? You may find that the cost of consistent code (annoying the other developer) is not worth the benefit.

We agree on a standard coding style and enforce it in the form of Visual Studio settings files.

That's a human communication issue. Just talk to each other. Not through code, in person.

Communicate with the other developer. Agree on a coding style that combines best of both worlds ?

When you say "coding style" do you mean formatting or a difference in the way you structure your code ?

As for coding style, the team should probably have a style formatter and enforce some kind of format before commit. this way merges will not drive the merger crazy.

For the structural difference in the code I am afraid there is no easy solution. If one is a hard core spaghetti coder, versus a fanatical object coder you will have to sit down at a table and discuss both approaches and how they apply on your particular project. Remeber that there is no absolute answer, it all depends on context. Also try resorting to someone both of you respect to recommand best practices, do code review for code validation, and help determine a common approach (technical leader or tech PM).

using the IDE in combination with style-checking plugins (In the Java case - Checkstyle, PMD) the team leader, or even the project manager (if a technical person) can force code style guidelines upon the whole team.
just ignore his style - I have worked on Java projects where some developers were putting the curly brackets on a new line, and tended to forget spaces where they are generally needed - and I didn't have any problem with it after the fist week.
discuss the code-styles and compromise, then apply the IDE capabilities mentioned in the first point.

I’m going to answer on the “soft skills” required to get along with someone who has vastly different coding style that me. Generally I try to focus on three simple principles; professionalism, trust and ego.

In terms of professionalism its simple unacceptable to simply re-write or delete someone’s code because their style is different than yours. A professional approach would be to first understand why I consider my ideas/style/preferences to be better. Then I would expect to sit down with the other person and discuss my points and, here’s the important part, keep an open mind. Just because I like my idea doesn’t mean that it’s right or correct. A true professional will be able and willing to accept that others ideas are just as valuable and come from a different perspective.

I personally need to trust my fellow developers. The old saying is that trust must be earned not brought and this is true for software development. Trust can be built on from a variety of sources like sharing information, ideas and code. A productive team usually has an implicit level of trust between its developers.

One of the major reasons that people don’t get along is ego. Our egos allow us to feel threatened, superior, embarrassed and a variety of other human emotions. Leaving our egos aside and talking about our issues with the other person is always a good start.

Your coding style is not the norm. His coding style is not the norm. The norm is the coding style chosen by the project or, sometimes, the whole organization (and that should be documented somewhere) and both of you have to comply to it. Tools like Checkstyle (with Java) can be used to ensure conformance. If you use such a tool, distribute its configuration file. Also distribute files for IDEs formatting configuration.

Many open source (or corporate) projects do use these principles (see for example XWiki's Java Code Style, Maven Code Style And Code Conventions or Apache Developers' C Language Style Guide). This works for developers distributed around the world, don't tell me this can't work for developers in a same room.

If your project doesn't have any code standards, then it's maybe time to define some and I just hope you will be able to do it as two adults (actually, this should be a team decision). If necessary, remind why an unified code style is important (for a better readability, for diffs). If, sadly, this doesn't work, then have a boss decide for you.

I have to work with developers everyday that have vastly different coding styles to mine and as a developer, you learn to deal with it.

You have 4 choices, - you either convert them - you get converted - you propose a company standard. - you live with it.

If it's something like prepending the variable with the type, argue the point that a variable should be descriptive enough so that it type can be inferred.

personName vs sPersonName vs strPersonName <-- which one would you choose?

if you mean formatting, ctrl-a, k f <-- formats your code nicely in VS :)

I find it rare that there is only one other developer with whom I have to agree on coding styles, and that different groups or projects have different styles. You have to learn to adapt to different coding styles.

If there are only two of you, then there are only two of you who need to agree on the common coding style you are going to use.

If you cannot agree on a coding style, then you just have to deal with it. Try to work in a way that is productive -- and that means not rewriting the other person's code just to get it to match your style.

There may be some stylistic aspects that are troublesome, and it is best to focus on those. Style can easily turn into a religious discussion, so it's often more effective to focus on quantitative or empirical arguments for changes. Elegancy and physical beauty of your code may not win the argument -- but showing cases where a stylistic change would have headed off unnecessary debugging can be effective.

It depends.

If the other developer isn't particularly easy going, then I tend to just go with their programming style even if I disagree with it rather than force the issue - in this case its really a matter of whats more uncomfortable, their coding style or the grief I'll get by making a fuss?

If the other developer is more open minded then I might discuss things like coding / naming standards (I would hope that things like the overall architecture would be discussed anyway)

You'll have to invent some style suitable for both of you and stick to it. And if communication is a problem, just stick to an idea: "when I write my own, I don't touch the other code"