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

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 2

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 3

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 4

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 5

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 6

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.