Is Programming Style important? How Important? [closed]

Answer 1

About "style" (which I'd rather call "formatting"): it is largely a matter of personal taste, but working in team is very important defining some guidelines which EVERYONE must follow, bending his/her personal preferences if needed (in Eclipse we export the formatter configuration and with a keypress we get the file formatted). Very soon everyone will get used to the standard and reading code will be very less fatiguing.

About comments: I prefer a good naming for my methods, but a comment on two on the most obscure parts are mandatory.

Answer 2

No programmer is an island. Someone is going to have to read their code one day. It's been repeated here many times before:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Martin Golding _(maybe)

That said, if their style is adequate, there are other much more important things to evaluate when hiring a programmer. But if they utterly refuse to use comments or attempt to make their code readable to others, it is a deal-breaker.

Answer 3

There's little excuse for not commenting and none for not indenting. Indentation is handled by most of the best editors and commenting should come as second nature for somebody who MS might like to hire.

They're certainly both disciplines that people get into (either naturally or through schooling) so not showing either, perhaps, shows a lack of discipline, or, at least effort to express it.

Edit: 2 hours for a linked list?! I see he meant now... Fitting in all that formatting in the remaining one hour, fifty minutes would have been pretty tough! (I'm only playing around - I assume there was more to the interview than a linked list!)

Answer 4

I find it hard to believe anyone would think no indentation is a good idea. That is just dumb, I wouldn't call him back either if he did that for me on an interview.

Comments are a little greyer, great code is self documenting to a large extent. IF you write great code then comments should only be places sparingly in places where what is going on is truly complex and hard to follow.

Answer 5

"He did not have time to worry about style..." No wonder they didn't call him back. He didn't even get to the face-to-face interview and he's already refusing to do what is asked of him? That's a good way not to pass an interview for any profession.

Style is inherent in everything we do. It's not an overlay. It's not an add-on. It's not a perk. It exists whether we use it or not. Things - programs, products, what have you - are not improved upon by style; they are improved upon by having GOOD style (the opposite of which is simply having bad style).

The problem with people who come from a very technically-oriented point of view is that if it's not balanced out by any aesthetic interest or appreciation, it's assumed that "style" is a tool not used by programmers; "style" means "leave it to the UI or marketing guys." It's simply not true. In striving the best at what you do, you have to improve all aspects of the work. That means not just the execution, but the presentation.

Humans are visually-oriented beings. We choose things based on how they look (Pretty girl! Shiny package!).

In clearly announcing that he did not have time for style, he basically gave the impression that he was not the shiny package that Microsoft was shopping for. And through such an obvious pre-apology, he also made his lack of indents and comments more apparent to the evaluator (though I'm sure they wouldn't have hired him for his lack of comments alone).

Answer 6

I would fire him, but luckily, he would never actually be hired.

I would prefer that he spent 2 hours writing clean, almost functioning code, than for him to slap something together that works.

Programming style is important, especially when working on a team.
It becomes critical when supporting legacy applications, written by several people.

Part of being a professional, and not just some script-kiddie, is caring about the code. It's about realizing someone else will read this code (Maybe even you!) six months from now. Therefore, you should make it as easy as possible to maintain.