15

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...

Improve this question
6
  • 9
    Clever. Rather than remove the "serious trouble adapting" (which is unsupported by the facts) put a line through it. As if that actually changes the baseless assertion about someone else's attitude.
    – S.Lott
    Jun 3, 2011 at 11:01
  • 2
    Coding style is the least important thing you should be concerned with. After all, it is just a code.
    – SK-logic
    Jun 3, 2011 at 14:27
  • 7
    I was trying to read your question, but found your formatting to difficult to follow. Could you add a starting indent to your paragraphs. 'K THX BAI
    – dietbuddha
    Jun 3, 2011 at 14:32
  • 2
    Code consistency (or lack of it) is an indicator. For example if someone doesn't have time to organize their code they probably also don't have time to figure out the right place to commit a new project in subversion. They probably don't have time to refactor. The list goes on.
    – Kevin
    Jun 3, 2011 at 14:33
  • 10
    Coding style is ridiculously easy to adjust. This is like asking "This person wears black suits, but at our company we prefer employees to wear dark grey suits. Should I hire them?" Just tell them the style rules you have at your company. Problem solved.
    – juicy lucy
    Jun 3, 2011 at 17:12

10 Answers 10

Reset to default
42

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.

Improve this answer
6
  • 6
    +1 not having one, or not using it consistently are 'red flags', having a different style is not.
    – jv42
    Jun 3, 2011 at 10:04
  • 1
    I totally agree on the "at least use it consistently". Thats the most important thing when I review the code. But you must admit, that the code style/code format is the very first impression you get when you look at a foreign code...
    – WarrenFaith
    Jun 3, 2011 at 10:16
  • 4
    @WarrenFaith: so you judge a book by its cover? :-) Seriously though, yes it does give a first impression, but I would assume that when interviewing you would take care to look beyond that and not pass up a perfectly capable developer just because his current style doesn't match yours.
    – Marjan Venema
    Jun 3, 2011 at 11:06
  • +1 for consistency: the lack of style generally indicates that they haven't written much. When you write, you pick habits.
    – Matthieu M.
    Jun 3, 2011 at 11:38
  • 1
    I hate automatic code formatters but I can accept the need for them. They just seem to pick line breaks at all the wrong places. Yes, I'm talking about eclipse.
    – Kevin
    Jun 3, 2011 at 14:35
27

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.

Improve this answer
14
  • 2
    @WarrenFaith: I can't say this strongly enough. It does not matter. I'll repeat my point. I've read (professionally, for pay, billable hours) code from hundreds and hundreds of programmers. It does not matter. It is not the first impression: correctness and clarity are the first impressions.
    – S.Lott
    Jun 3, 2011 at 10:19
  • 2
    @WarrenFaith: Intentional obscurity is rare. "if you simply can't read the code" is something that may be as much the reader's problem as the writer's. I'll repeat my point. I've read (professionally, for pay, billable hours) code from hundreds and hundreds of programmers. "Simply can't read" has never happened. Style does not matter.
    – S.Lott
    Jun 3, 2011 at 10:55
  • 2
    Coding style (and quibbling over coding style) is a complete waste of time. - I agree 100% on the second point, and about 40% on the first. Coding style does matter - if there is no style in your coding at all. If there is, it doesn't matter that much how it looks.
    – Treb
    Jun 3, 2011 at 11:51
  • 4
    @WarrenFaith: I've looked at the sample, and I don't see anything there that isn't clear. It's not formatted how I might format it, but there isn't anything there that indicates that the code won't work. There's nothing unclear about it. There's nothing to suggest that the person who wrote would be unable or unwilling to conform to a team standard. @S.Lott is right. It doesn't matter.
    – Joel Etherton
    Jun 3, 2011 at 13:58
  • 4
    And using //Important on every line. Ahem. Every line of code is important or it should be deleted.
    – S.Lott
    Jun 3, 2011 at 14:02
7

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.

Improve this answer
7

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.

Improve this answer
4

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.

Improve this answer
2
  • forgot the commit problems... and yes, we have an official formatting style and also auto formatting before saving.
    – WarrenFaith
    Jun 3, 2011 at 10:26
  • @Warren, well, then say so at the interview and ensure that the programmer understands that this is important. Then it is up to him to live up to his promise if he wants to keep the job.
    – user1249
    Jun 3, 2011 at 10:29
4

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.

Improve this answer
4
  • So ... if some company invented their own C# coding standards, would that be a red flag?
    – Job
    Jun 3, 2011 at 14:51
  • 1
    @Job: Not necessarily because StyleCop allows adding additional rules. I know I've written two of them that enforced TABs over SPACEs which wasn't there in the first place. But the idea is that coding style can be forced which will make it much easier to have uniform code.
    – Robert Koritnik
    Jun 3, 2011 at 14:54
  • What if their style went again that of StyleCop, and if they were not utilizing StyleCop at all - would it be then?
    – Job
    Jun 4, 2011 at 1:44
  • @Job. Unless someone doesn't write C# code as if it was old Fortran (80 column fixed layout anyone?) then I still think that coding style can be asked to be obeyed. If someone is a great developer you can remind them of improving their style (or let them justify their style over ours). That's what code reviewing is for. Any code can be fast reformatted but at least naming conventions should be followed. But it is by no means a red flag for hire. Shouldn't be.
    – Robert Koritnik
    Jun 4, 2011 at 8:38
3

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.

Improve this answer
5
  • In my case its often the only thing I see from the guy...
    – WarrenFaith
    Jun 3, 2011 at 10:17
  • @WarrenFaith - Ok, but you're never going to make a single-handed decision to hire someone based on so little information, are you? You're just being asked for an opinion.
    – pdr
    Jun 3, 2011 at 10:21
  • True. I give my opinion from the technical point of view and the soft skills are also important. And we only test guys that at least passed the soft skill "test" in the interview. But I am curious about the impact the coding style should have on my opinion...
    – WarrenFaith
    Jun 3, 2011 at 10:24
  • @WarrenFaith - in your position, I would mention it, but as a sidenote rather than something of massive importance.
    – pdr
    Jun 3, 2011 at 10:32
  • I basically just make a list of pro and contra and I explain and justify it for our CTO. The final decision is up to him...
    – WarrenFaith
    Jun 3, 2011 at 10:34
3

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.

Improve this answer
0

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.)

Improve this answer
3
  • The problem that comes with a "bad coding style" is often the inexperience. When I see the most beginners, they often lack of anything that could be called coding style.
    – WarrenFaith
    Jun 3, 2011 at 10:20
  • ?? "strong argument against this person" ... "not actually worry about the coding style". Which is it? Does it matter or doesn't it? It's hard to tell from the answer what your advice is. Could you clarify, please?
    – S.Lott
    Jun 3, 2011 at 11:02
  • @S.Lott: Which is it? - Well, both of course. Bad coding style is a bad habit, most people can learn to shed it. It's when they can't (or won't) learn that you have a problem.
    – Treb
    Jun 3, 2011 at 11:47
0

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.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.