Is Programming Style important? How Important? [closed]

Answer 1

You can argue that well written code does not need comments, or at least very few comments. But a lack of indenting is not acceptable. The compiler does care (in most cases), but the people maintaining the code do.

Answer 2

In an interview, it is perfectly fine to not indent or comment your code. In fact, I would be surprised if you had time to do that-- we normally don't give that much time.

As a general practice, however, I fully expect you to indent your code and add comments where necessary. In fact, our build machine will fail on minute things like including tabs instead of spaces in your code.

Code readability is important. Just like no one likes reading one big paragraph (instead of small, structured paragraphs), no one likes reading one big lump of code with no formatting.

Answer 3

There is another reason why code style is important. It can act as a proxy for determining a programmer's professionalism. Just as a peacock's tail feathers demonstrate his health and virility (an unhealthy organism wouldn't be able to devote scarce resources into building a plush tail), a program's style can reveal a lot regarding the person who wrote it.

When I see badly formatted code with inconsistent naming conventions and scarce comments, I steer away from it not only because such code is inherently unreadable, but also because the code is quite likely to harbor even worse problems beneath this troublesome surface.

Answer 4

Absolutely, style is important. Especially when it comes to things like indenting and whitespace. Code should be easily readable by a person, since it is a person that has to maintain that code later. The more readable the code is, the easier it is to maintain and the higher the quality of that code will eventually become.

There is a psychological factor that comes in to play with code style. When the code is "ugly" and hard to read/understand you want to take less ownership of that code, so there is less personal incentive to do your best work. As the code becomes more readable/easy to understand, you feel better about the work you've done and want to take more ownership. The more ownership of the code you feel, the more personally important it becomes to write better code.

As far as how Microsoft responded, I would have responded in exactly the same way. I think their response of not calling him back was probably perfectly justified (and there may have been other factors than the lack of code style, although I'm sure that was a contributor).

Answer 5

I've always felt that the one thing you can count on is that the people who look at your code after you are gone will think you are an idiot. The key thing is to maximize the time between when the code is first viewed and when they make that determination.

Good formatting is one way to increase N, helpful comments are another.

Answer 6

I would try flattering him, tell him that because he can do more complex stuff than other programmers he needs to comment it and lay it out nicely so that the rest of us can understand it.

I think if someone demonstrated that kind of attitude to me in an interview I would think very carefully about hiring him. I'm sure that even Microsoft want team players.