Is Programming Style important? How Important? [cl

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

回答3:

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.

回答4:

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

回答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.

回答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.

回答7:

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.

回答8:

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.

回答9:

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.

回答10:

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.

回答11:

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.

回答12:

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

回答13:

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.

回答14:

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.

回答15:

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.

回答16:

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
}

回答17:

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.

回答18:

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.

回答19:

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.

回答20:

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.

回答21:

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.

回答22:

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.

回答23:

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.

回答24:

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.

回答25:

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!

回答26:

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.

回答27:

"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).

回答28:

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

回答29:

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.

回答30:

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.