How important is a good coding style for the decision to hire a programmer?

Question

Even as a student I am asked to review the code of programmers who have (not) passed a test (create a list of Fibonacci numbers on android).

While I am very strict on coding style I just read about the "block" style someone used (read the comments!).

In my position I would recommend to not hire a guy using this kind of style. The code is completely the opposite of the coding style used in my firm.

While searching for coding style and how to deal with a lack of it I am curious about one thing: Should I hire a guy that will have serious trouble adapting the coding style used in the firm?

Please: This should not be a discussion about coding style in general and which is better. Its about the importance of coding style for the decision to hire someone!

More information:

I am not the guy that makes the decision, I just give my opinion based on code. The guy has to pass an interview where our head of whatever checks the soft skills. If he passed this, he has to pass our little skill test and that is where sometimes I am asked to review the written code. I am not in the position to say yes or no. I just want to know how important coding style should be for my review...

Answer 1

How do you know that (s)he will have trouble adapting? Just because they use a different coding style? That's pretty presumptuous. I have been a contractor for a long time, and no matter what coding style is used, you adapt. It may take some time, but the habits form pretty quickly.

I do hope that by coding style you do not just mean indentation and layout of the code. That is easily dealt with using a code formatter and integrating that into your version control system.

Taking coding style to mean things like naming, general ordering, unit separation, and everything else that deals with readability and maintainability, the most important thing about coding style is that you have one. Not which one. Not having a coding style is a definite red flag.

The second most important thing about whatever coding style someone uses, is that they use it consistently. When someone seems to use a coding style, but frequently "sins" against it, that is another definite red flag.

Answer 2

Having been programming at hundreds of different projects for almost a hundred different customers, let me emphasize one point.

Coding style (and quibbling over coding style) is a complete waste of time.

Get over it.

I've read a lot of code from a lot of different programmers. (Assume a median team size of 5 and 100 different teams. That's 500 co-workers.) Style doesn't matter.

I've seen pretty but pathologically wrong code.

[There is a limit. Intentional obfuscation is grounds for termination. Short of that, style is a waste of time.]

Coding style is the "final frontier"

If you have solved all of the problems of software development; if you can produce error-free code more-or-less instantly; if your level of quality is so high you no longer have a bug-fix queue; if your usability is so fabulous you no longer have a help desk; if you are able to ruthlessly optimize to the point where you don't have a server farm, but run the enterprise from an iPad...

When there's nothing left to fix, you can finally focus on coding style.

Until then, there are numerous issues that are larger and more valuable than style.

Answer 3

It's ridiculous to have the code format be a factor when deciding to hire someone.

1. There are many more important factors to consider.
2. Most developers can adapt their style.
3. If format is that important use a code reformatter and a lint checker.

Not hiring a good developer because he doesn't add a space after a comma is silly.

Answer 4

Judging programmers based on coding style is 50% snobbery and 50% insecurity.

I like my code to look neat and clean, and it sounds like the guy the OP ragged on in the link does too. Our code does not look the same, but we both use a style that helps us to understand the code when we come back to it. I had absolutely no trouble at all understanding his code and I doubt the OP did either. Coding style "advice" is nothing but an easy cheap shot where you can convey your immense wisdom about why curly braces should be on the next line. It does not matter at all. What makes code difficult to read is:

• insane naming conventions (or lack thereof) that do not describe what they represent.
• insane program flow that makes it difficult to tell what is happening (goto, try/catch with business logic, etc.).
• insanely long functions that do more things than the brain can keep track of.

I have trouble imagining any code that did not do any of the things listed above, but was still difficult to read, especially with a tool like Style Cop.

Answer 5

Use StyleCop

If you're using Visual Studio, you can always force StyleCop rules with your compilation which will make it sure that your code as at least readable.

I reject unreadable code arguably non-standard styled, because it will become very hard to maintain in the future - even by the authors themselves. This has been proved many times in the past.

CVS integrated code formatting = optimal solution

It would really be great if any of the CVS would support auto code formatting on check-ins. You'd just set your style priorities, code would get formatted before saved. That would make developer specific style obsolete in terms of code formatting. I can see the problem if some developers are using different indentation characters. It's not so problematic for me to look at different code (and I can easily and fast reformat it) but DIFF becomes harder to handle. Lots of false positives in the DIFF tool.

Answer 6

Far below the following much more important details:

• Team Fit
• Problem Solving Abilities
• Communication

Coding styles can be learned by most people who have the last two listed above.

However, I generally see a code-sample before the final interview, and if the coding style is a long way from what we use, I will focus on questions that expose their ability to adapt.

Answer 7

As long as the style is consistent and that person is able to adapt (change) to another style, I don't see any problems.

If the current style is different from what you use it doesn't mean is bad. For the candidate, it might make complete sense.

Just like others said, having trouble adapting might be the only problem.

Answer 8

I suppose you have an official formatting style in the company.

Then make it extremely easy to reformat any source to the official style, and preferably make it happen automatically every time the source file is saved.

Any programmer worth his salt will grow to love this because it ensures higher quality by minimizing the diffs for commits.

Answer 9

I wouldn't say that this is a definite no hire, but it's a strong argument against this person.

I would not actually worry about the coding style, but about this inability to adapt being a symptom of a general problem. I would be afraid that the candidate might find it difficult to adapt to other aspects of the team culture, as well.

If you can not wrap your mind around using pascal style instead of camel style casing, then you may very well have trouble remembering to start a new batch of coffee if you were to take the last cup. That sort of thing can be really harmful to the team.

(And yes, I am a caffeine addict.)

Answer 10

In my opinion, a good code style is essential for a programmer to work with.

Having a good code style is a question of personal development. It is an indicator which level this programmer already reached.

The question is if your company want "high professionals" or "high potentials". If you need "high professionals" and there's no room for learning and evolving - code style is a knock out criteria.

If there is room for evolvement and the development of programmers you'd better take care about his or her ability to learn fast or think creative.