Is Programming Style important? How Important?

Question

Last year I was troubleshooting a team member's code and it was lacking indents and comments. I was talking to him about it telling him it was not a good idea but he got offended. He was/is smarter than me or certainly more educated.

Since then I found out he applied to Microsoft and when they had him do a doubly linked list implementation, he wrote it without indentation or comments, stating that he did not have time to worry about style. ( It was an email submission for which there were 2 hours to complete )

Microsoft did not call him back..... How do you think they responded, how would you respond?

Anyone from Microsoft on here that can suggest what they would do in this case?

Answer 1

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.

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

Programming without identing and a readable style is like writing a book without paragraphs and pagebreaks. It's just a great bunch of text and I would never take time to understand it.

I fully understand the reaction of Microsoft - I wouldn't call him back too.

Answer 5

Programming style is very important. Comments even more so. Even if you are working by yourself, on your own project, you should comment your code, because a month later you will not remember what you did and why. And if you work in a team, then unclear, unformated, and uncommented code can cause a disaster.

Answer 6

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 7

If you spend more time on indenting code than actually writing it, it could be a problem. But source code styling, conventions and consistency across the solution is important.

That is why I rely on a tool to do that. Resharper allows me to reformat all my code by pressing Ctrl+F, E keys combination.

Answer 8

Code is read by three entities: The computer, the programmer, and ultimately the maintainer.
Style and Formatting is irrelevant to the computer, possibly important to the programmer, but it is certainly important to the maintainer, who has to try and comprehend the program's functionality.
Refusing to accommodate other developers by making code readable is disrespectful.
Creating organized code with meaningful variable names and comments is a form of common courtesy to anyone else who reads it.

Answer 9

When it comes to coding when applying for a job, I think it's a bit harsh to dismiss a candidate for not commenting/indenting the code he wrote, except in a situation where he was explicitly asked to do it.

Answer 10

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 11

If want to throw away your source-code after writing it, it's OK to ignore styles. That applies for fast scripts, that you make for your task, that really runs only once. On the other hand, how often it happens, that the task that was supposed to run only once will be reused later.

Reusing may be OK, but it will later hard to understand what happens. If you want to modify the code later, you are lost without some style.

How important a proper styling is, depends on how long you will use and modify the code and how many will work on it.

If you work in a team, speak about which styles should be applied.

Answer 12

Your friend needs to get his prioritys right, and in my opinion I believe microsoft would care more then you seem to think they would.

Answer 13

Style that emphasis on readability is important. Extremely important.

Many programmers argue over frequency and use of comments, but most argue that they are needed.

Answer 14

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.

Answer 15

I wouldn't expect an interviewee to comment their code (assuming they were writing it on the spot in the interview). If I was interviewing someone experienced though, and they failed to indent the code, then that would certainly count against them. I wouldn't expect the indentation to be perfect, or in a style I liked, or anything else. But it had better be indented. It's part of writing code.

If I'm recruiting someone non-experienced (and I usually am) then it doesn't matter. But I'm not going to ask them to write a doubly linked list either.

Answer 16

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 17

Well, the fact is that the software life cycle phase in which it lives the longest is maintenance. During that time it is mostly read and analyzed by humen trying to fix it, reuse it, enhance it, etc. That is the best reason to keep it easily readable and understendable. Someone stating that he has no time to worry about style, which explicitly influences readibility, shows only his immaturity as software engineer. Or maybe simply no understanding of software life cycle.

Answer 18

I think so much of what we are judged on is looks or style, it would be hard to look at a piece of code without indentation or comments and see the genius in it. Most people would look at it and think ughhh this is way too overcomplicated, lets rewrite it.

I would probably read the Microsoft code style guide before submitting it. Just as you would not walk into an interview with dirty clothes, I would not submit unindented unreadable code

Whats the saying.... Writing new code is like sex, fast and exciting... Maintaining code is taking care of the child that arises from sex, long, difficult, and extremely frustrating at times.... oh rewarding and fun too...

Answer 19

No

Programming style is absolutely not important. What matters is maintainability and readability.

To ensure you'll stay on track, you must enforce your team with an homogeneous and readable code format. Which one doesn't matter : you can't please anybody and there are software to change the code format.

If a language accepts several paradigms, don't try to choose only one. As long as code is well commented and does the job, who cares it the guy used a functional or an imperative style ?

Answer 20

Programming style is very important. Clean code pleases the eye and improves maintainability of the program. Therefore it's directly bound with the quality and the architecture of the program itself.

Even in a language that forces indentation one can really broke everything with bad style. Bad style may not therefore be lack of indentation or comments. Actually, I rarely use comments, I much rather prefer docstrings and overall writing better documentation. I associate comments to small notes you spread around the code if you really see there's something to fix or wonder about in there.

I'd rather see bad style as not letting the programming language do some of your stuff for you. Proper, cleanly written macro in a place or two is really good style rather than bad.

Answer 21

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 22

It's all a matter of who is the intended audience of the source code. The correct answer is "other programmers" (maintainers, etc). Your collegue thought it was not important and I fully understand why MS didn't hire him. I would be surprised if any big company would hire him at all!

I remember an old article titled "Typographic style is more than cosmetic" appeard on "Communications of ACM" that made experiments on the impact of good formatted code on productivity.

They took a group of programmers and gave them a test to rank them. Then they divided the group in two the two group the same assignment: modify a piece of software to add some functionality.

Only that the first group got a nicely formatted source code to work on and the others had a rather messy version of the same code.

They measured their productivty again and the end result was that the WORST programmer of the first group scored better than the BETTER programmer of the second group.

Since then, I always put extra effort in makingmy code clear to read for other humans.

For those interested in the topic I suggest reading about literate programming, intentional programming and other related concepts.

Answer 23

Commenting is something I'd see as a double edged sword since too much comments can certainly lead to less readability. Jeff wrote a excellent article on this

Indenting on the contrary never hurts and increases readability big time. That's one reason why so many people like Python with it's significant whitespace.

Answer 24

Prgramming style does not limit only to code identation and commenting.
Code identation is indeed very important for code lizibility. I never saw un-indented code that was easy to read :).
What's also very important is the code to be self-explanatory, comments should be used only when the implementation becomes for various reasons cryptical or where the code doesn't reflect clearly WHY the author wrote it that way. I saw lots over-commented code, and I can tell you, seeing comments almost on every line is like reading pages of insults.
Anyway, I doubt that Microsoft rejected your colleague just because he didn't comment a double linked list implementation.

Answer 25

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 26

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 27

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 28

I try to use the IDE formatting style. So, we avoid new and boring definitions about how to write code and consequently, unnecessary merges due to differences in indenting and format.

Documentation is mandatory even on the most fool code. It could be nice have a template to generate documentation lines inside your code. Standardization and organization agreement inside a team is the best style.

Answer 29

A developer who doesn't care about style is like an artist, a painter, who doesn't care about color.

Answer 30

Formatting doesn't take any time whatsoever. It's a crappy excuse. Just let your editor format it when you're done for the sake of the violent psychopath.

Answer 31

I wouldn't mind it he didn't put in comments immediately. But the indentation is important. When you write code, it rarely comes out linearly in one fit of typing frenzy.

No, even before testing and possibly debugging the code, there is usually a lot of editing and being able to clearly see the code structure is important.

This reminds me of an incident that occurred early in my career. I was a junior level programmer and another junior programmer asked me for some help on his code. We were using Pascal at the time. His code was a mess. I've seen code with no indentation before, but had never seen code with random indentation. There was no way to follow it.

So, the first thing I did was to fix the indentation. He smugly said. "I don't think that's going to fix it!". I looked back at the code. The error was now easy to spot, so I just pointed to it and walked away.

Answer 32

Coding style is fairly important. Most major development companies have a document that defines required naming conventions, commenting guidelines, and other little things to do with code style and architecture guidelines.

All of which is very good and helps to promote a working environment in which team members can have good expectations of what their colleagues code will look like.

Just make sure it doesn't get down to the level of a manager forcing a developer to make a change in a code review from something like this :

if( someBool() ) doSomething();
else doNothing();

To something like this simply because they "feel" its the "better" style :

if( someBool() )
{
    doSomething();
}
else
{
    doNothing();
}

Just please have reasons better than personal preference for style requirements and we can all be happier.

Answer 33

In my opinion, saying that style isn't important is like saying that spelling isn't important. If your style (or lack of style) is causing readability issues, then it will be difficult for a team to work with the files that this person is writing/editing.

Similarly, if a programmer doesn't take the time to spell words correctly in comment blocks, function names, etc....it will cause issues with other developers trying to decipher code. I always ask myself, "self, if you look at this in 1 week, will you understand it? If you look at it next year, will you still understand it?" (or at least be able to read documentation/comments to jog your memory).

To me, style is not important when you are talking about putting the curly brace on the next line of your if-block versus putting it at the end of the conditional statement...as long as it meets your coding standards, is internally consistent, and the rest of the team uses the same approach; with that being said, I feel that style is extremely important if it impacts the readability of the code.

With MS being such a large company, they probably are looking for someone who can be a problem solver as well as a team player. Someone who states that they "don't have time for styling" would come across as not a team player, to me.

Nice question!

Answer 34

I'd like to know how any decent programmer could write code without indentation, whether it is done in an IDE, vi, Notepad, on a whiteboard, or on a post-it. Indenting the code should come naturally. I wouldn't call him back if what he turned in looked something like this (I'm just copying the implementation off of Wikipedia, focus is on lack of indentation):

struct Node{
data
next
prev
}
struct List{
Node firstNode
Node lastNode
}
function insertAfter(List list, Node node, Node newNode) {
newNode.prev := node
newNode.next := node.next
if node.next = null
list.lastNode := newNode
else
node.next.prev := newNode
node.next := newNode
}
function insertBefore(List list, Node node, Node newNode) {
newNode.prev := node.prev
newNode.next := node
if node.prev is null
list.firstNode := newNode
else
node.prev.next := newNode
node.prev    := newNode
}
function remove(List list, Node node){
if node.prev = null
list.firstNode := node.next
else
node.prev.next := node.next
if node.next = null
list.lastNode := node.prev
else
node.next.prev := node.prev
destroy node
}

Answer 35

I wouldn't even read his code never mind mark it if it wasn't indented. Lack of time is a terrible excuse, it takes seconds to indent a piece of code as you type...not to mention the fact most editors automatically indent. Commenting perhaps he may have run out of time but even so that's still a very poor excuse. It doesn't take long to comment a piece of code you've just written.

Answer 36

IDEs and programming editors and code reformatters are out there. A shop should adopt a style that works for its purposes and use a reformatter as needed.

In short, indentation and placement of delimiters just isn't that big a deal anymore.

Answer 37

Not showing comments in a coding test for an interview is like sitting an exam and not showing any working!

Surely comments should be one of the insights into the programmers strategy and thinking?

Answer 38

I've come to notice that code is like a blueprint. A well planned, beautiful, masterful blueprint for the design of a luxury house is going to be well structured and helpful. Code should be the same.

Answer 39

I would think that indentation comes naturally. I just do it, every time I write something automatically. Not doing it would confuse me.

Answer 40

This is why coding standards are needed. The team should adhere to the standards even if its not how they normally code. He could learn alot for actually maintaining someone else's mess, like what I have. 7000 lines of C++ write in C style split over 7 methods (most methods are 600+ lines), lots of one line macros which contain gotos to labels within the methods. There is also lots one line if statements, and macros added to the end of these and other methods calls which you won't see because you have to scroll to see them. Add to that terrible variable names and inconsistent bracketing style and you get an unmaintainable mess. The positive thing is it works well and we have relied upon it for years.

Answer 41

There are several views on this that have noted above. Basically, style and comments help with maintainability.

Code is written for programmers (including yourself!), not for the compiler. If we never needed to read the code, just punch it in with a hex pad (like a real programmer!) and be done with it! :-)

But that is almost never the case. Over the lifetime of the code, the compiler may spend a total of a few seconds processing it. But days may be spent by programmers. And those days may increase to weeks if it is hard to read or understand. Effort should be expended to make code self-documenting, but don't rely on it. Ever.

Indentation shows control flow. A bunch of lines with no indentation may have control flow but it means you have to read each line to detect it:

if(someSituation) somethingElse++;

vs.

if(someSituation)
    somethingElse++;

The second version jumps out visually. You don't have to read and understand the code to see that a decision was made. Very important when scanning through some code to find something quickly.

Most IDEs and programming editors will allow you to indent a block of code instantly. This is so easy that you should do it just to ensure you don't have a dangling "else" or some other operator-headspace problem. Lack of indentation is very hard to justify.

Comments are also important. If the comments don't match the code, then they are both wrong (I don't remember who first said this, but s/he is dead on!).

I put in a comment block when first laying out the code, then code and debug, and then check the comments again. I may find that I have misunderstood the problem (change the comments) or I may have implemented the wrong thing (change the code). Or I may find that I have reimplemented a library function (temporarily comment it all out in case I need to do something strange after all) and put in the call to the function.

Sometimes you have to use a library function that is badly named. You can say RTFM and move on, or you can put in a summary comment and save the next programmer (perhaps yourself in 6 months) some effort.

// This allocates space for the message queue and initializes
// some OS overhead. All that remains after this is adjusting
// priority and content and then send the message.
prepareMessage(&myMessage);

Further, if you have spent 2 days running down a bug and put in a small change in the code, there is a good chance that the change was not obvious at design time. Else it would have been there in the first place! So a comment is needed to prevent somebody in the future changing it back to the "obvious" implementation.

memset(&myStatus, 0, sizeof(myStatus));

// The size member must be set before getting current values.
// This is used by library function GetCurrentStatus() to infer
// a version of the status structure.
myStatus.length = sizeof(myStatus);

GetCurrentStatus(&myStatus);

Answer 42

"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 43

Well, there's life, and then there's interviews.

Ask your friend - would he show up to the interview in tattered jeans and a grubby t-shirt?

His task in the interview (no matter what the format) is to impress the person conducting the interview. Impress them enough to get offered a job.

So if applying for a programmer job, why in the world would this guy submit "tattered jeans and grubby t-shirt" code?

I really hope this person has some clue about coding style, comments and whitespace. In that case, he made the judgement call that the interviewer was more concerned about "rightness" than about "goodness" (my interpretation).

BUT - given the task (linked list? this should be easy-peasy for a programmer), it would seem the task is about far more than just "rightness" of the code.

I suspect the interviewer was looking for many things, INCLUDING good coding practice (it's 1000x harder to "unlearn" bad programming practice than to get them right at the start). The interviewer was probably also looking for something to indicate initiative, good assumption making, perhaps even creativity or inventiveness.

For example, there are many ways to write a linked list that are "correct", but some (like using recursion) are deemed more "elegant" than others.

I suspect your friend missed the mark on several levels in this interview.

-R

Answer 44

It's said that 80% of the lifetime of a project is spent on maintenance. If your code is unreadable, you're bound to be wasting a lot of time for whoever is maintaining your code, and inevitably, you will make them think evil thoughts about you.

From what I've seen, though, most teams of programmers (or even a whole company, sometimes) have a document or something explaining the code conventions and styles they adhere to. It is therefore quite easy on your first day of working there to input their rules into your IDE and just have it auto-format your code so you won't have to worry about it. Even better, you can probably find someone who is willing to "export" their prefs file so it's just a matter of a few clicks until all the code you'll ever write at that company is formatted perfectly.

That being said, you won't always have access to these team-specific conventions (say, for instance, in an interview). It is always a good idea to follow some basic conventions that make sense. Depending on your language, a good idea would be to Google "yourLanguage code conventions" and read up on the basics. What's important in the interview situation is that you follow some basic guidelines and have a formatting style that you stick to. If you make the bracket after an "else" statement on the same line once and write it on the next line another time, you're probably telling the interviewer that you don't really care enough and/or you don't have enough experience that one way has become a habit for you.

Answer 45

I tend to think coding style is really more a reflection of the kind of software programmers we are.

If we write sloppy code without a care in the world, yes then I would think that we portray an attitude that we do not respect other teams members, but if we take time to write in a style that is understandable and consciously try to make sure our code is legible and correctly structured, then surely we portray that we have an attaitude of respect to our team?

Style is more about who we are and really less about what we know.