Is Programming Style important? How Important? [closed]

Answer 1

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 2

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

Answer 4

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 5

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