Is Programming Style important? How Important? [cl

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 7 years ago.

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

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

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 4

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

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.