I'd take a long view on this and start to introduce it in the most painless fashion you can without wasting people's time rewriting existing code. For example:

• Start using coding standards on new projects/components.
• Start any new developers using coding standards form the outset.
• Use coding standards when refactoring existing work.
• Prioritise coding standards for all public interfaces between components, but allow the internal code to catch up over time.
• Start with the developers who are closest to the standards you want to promote and/or who are most supportive on moving to standards.

Of course, this assumes that you can define and document a set of agreed standards so that it's clear to everyone what they should and shouldn't do. You need to give some thought to adopting and documenting a set of standards that work for your projects/components, that move you towards common industry practice (to make it easier for new developers to fit in), and that minimise the changes you need to make.

You also need to balance how much push-back you'll get from your developers (I assume some as your question implies that they don't want to move to a standard format) and the cost of moving to standards in terms of slightly slower initial development times as people get used to the standards against the long-term benefits of having a standardised format for code.

Coding standards aren't absolutely necessary, but will likely make your life somewhat easier in the long run.

At the moment your ~10 developers can all understand each other's code quite easily, but there's always the slight amount of time it takes to switch from your own way of coding to a team mate's. If everyone is coding to the same standard, then this slight delay and any possible confusion is removed.

Think of it this way - at the moment, say you have ten people writing your code to their own "standards", 1 speaking english, 1 dutch, 1 german, etc. To read through the codebase I need to know english, german, dutch etc (up to 10 "languages") to be sure I know what's going on with everyone else's code. If you standardise on esperanto, it'll be native to no-one, but I would only need to learn it to understand the whole codebase.

The language analogy is perhaps a tad extreme as everyone is likely using the same coding language, but even within this constraint it can be surprising to see how many different ways people can find to write, name and document similar functions!

Edit - Good point by TheOtherScott ^[1] in a comment below - my example is probably better if you replace foreign languages with different dialects of the same language. You can understand what the other person is saying, but you'll have to concentrate more than you would if it were all the same dialect.

is it absolutely needed to force certain coding standards.

You don't explain the goals of your project, how it's starting, complexity, size, output, distribution (ie, are others going to look at source), etc, etc.

So we can never tell you if it's "absolutely needed" - surprisingly many projects succeed in the face of abject code failure.

Still, properties of good coding standards:

Easier, faster reviews amongst team members. You may think that a slightly different code style won't make a difference to experienced team members when reviewing code, but I've seen many great programmers slow down when they run into

    if(){
       Somestatement;
    };

vs

    if()
    {
       Somestatment;
    }

It's not a huge problem, but it draws the eyes away from the code and either slows them down, or helps them miss things inside the actual if test. Other areas of a code style offers different challenges.

Maintenance is a big issue. Reformatters can help here, but then you get into reformat wars (ie, I edit it and check in my style, someone else edits and checks in their style, etc) or worse - I edit it an use my style for my edits (because it's what I'm used to and I'm faster, and since their style is undocumented I can only guess from the few lines I can see) and a single code file has multiple styles.

Lastly, Style is often used to give hints on datatypes.

Is SOME_VALUE a constant, or a typedef? Enum, or structure? Enum type, or enum member? What is the scope? Is it global to the entire program, just this file, just this class, just this function, or just this block? Who is the producer? When reading code it hurts to have to keep referring to the headers, and scrolling all over creation simply to find out what a particular variable is. Using a standard for this eliminates much of this searching, making reviews, maintenance, and eventually coding faster.

Still... is it absolutely needed to force certain coding standards?

Depends.

-Adam

It can be a problem enforcing coding standards when the developers are very experienced. What I would suggest is to let them sort it out for themselves. Call a meeting about coding standards - let everyone have their say. You will probably find that they agree with the principle of coding standards (most experienced developers do) but have different ideas of what those standards should be. If they agree that coding standards are necessary, let them come up with a decision on what those standards will be. It will be easier to enforce if the developers themselves have come up with the standards.

1. Anyone with that level of experience should be professional enough to adjust their style with little trouble.
2. They are working on your project, not their own.
3. The ultimate result should not be personal to anyone on the team, it should be a collective effort.
4. They will be walking away from it at some time, while the code and the company has to go on.
5. The third-party libraries is a bit of a red herring as you probably don't have to maintain or extend that code.
6. Imagine you were building a hospital together. Would you allow all the different builders to decorate and wire each room or corridor in their own personal style?

Don't let the primadonnas beat you!

There should ALWAYS be a certain level of coding standards implemented. Even if your 10 developers are working on their own separate components today, tomorrow one of them can get hit by a bus and another four will find a better gig, and you'll end up having to hire 5 new ones. You want to minimize the learning curve for those new developers as much as you can, because it does cut into your ROI. And you do that by having them be able to hit the ground running with standard, readable, easily maintainable code.

As for you, the manager, coming up with the actual standards... I would only suggest that for a manager with an up-to-date, technical background (and not an ex-Fortran developer who hasn't touched code in 5-10 years). Experienced, highly-technical, senior-level people should be put in charge of standards development.

If you can agree that coding standards are required, a good way to start making sure they are followed is to implement peer review of code. People will check each other, and you don't get to look like an overbearing ogre.

I think coding standards are a brilliant idea and should definitely be adhered to in almost every case. I do not, however think it should be down to project managers to enforce them. It depends how your company is structured as to what they're roles are - in mine, this should be down to the configuration manager or whoever was doing the code review. I think the way my company approaches it works very well:

1. We have a set of company-wide standards.
2. Each project takes a copy of the standards at inception.
3. Since every project is unique and there are often third-party libraries or real time O/S's etc. that mean we have to break some standards, we allow each project to have it's caveats and exemptions (as long as the have good reason!).
4. At the end of each project, we review the resulting standards. If there are cases where significant deviations occur, we take a look to see whether the company-wide standard should be updated/improved.

The result is that your overall code base as a company gains a much better uniformity which is fantastic when you're moving between projects because nothing looks too alien. I work in a department which is effectively a consultancy within the company so I see a lot of different code bases. Without the cohesion, I would have a much steper learning curve upon entering each project.

I strongly believe though that any standards have to be flexible and have to make sense. Rules without reason are just going to start fights and I for one have always found in-fighting with my team to be particularly counter-productive. For the same reason then (as a few people have pointed out) having some global rules mean that there is much less 'my coding style is better than yours so you should do it my way!' :-)

I agree with Jop - I would set the standard first and make sure everyone follows it. The consistency is going to be a challenge with 10 different people, but should you add or replace team members due to attrition, etc., you'd want semblance of order across the components.

If you unsure as to what standard, pick a senior member to head up the effort and support that person's efforts.

If the project is written in C++, I'd recommend reading C++ Coding Standards: 101 Rules, Guidelines, and Best Practices ^[1] by Herb Sutter and Andrei Alexandrescu. It presents clear rationale behind some best practices and also discusses what not to standardize on.

If you are building shared libraries to use on your team then YES. Programmers shouldn't have to guess if the function is ToExcel() or To_Excel(), etc.

But NO for creating rules determining whether a for loop should use 'i', 'counter', etc, unless you are certain this won't create any morale issues. In practice, I have had very few issues reading other competent developers code, even though their styles differ from mine.

If you allow everyone to use their own personal standard, sometime in the future, there will be arguments (fights) as to which coding standard is better and which standard should be followed. That is not the best time to have that conversation because there would now be code that is written in 10 different coding conventions. If at that time, you've finally chosen to follow something, you would have to go back and change the existing code to follow that standard.

So I would rather have that argument ironed out before any coding starts and that everyone agrees to adheres to that standard.

Coding standards will be very beneficial. The naming convention is not much of a problem (though it's one of the easiest to conform to) but Hungarian should be either everywhere in the codebase or nowhere.

Its always a good idea - you can consult the team and let them set the standard, but there should always be one.

Its about succession and continuity as code is handed from research to development to maintenance. Not all developers, even long experienced developer work with the best of habits - these habits tend to be emualted by junior people (both good and bad) and then you get a mess. your code is all that you have and all that is valuable in the project. it should be neat and oranized and consistent.

You also never know when you might have to show it to someone outside the organization - law suit, take over, or even shared or escrow source for key customers. Do you really want to show this to someone in a hackedup/mangled state ?

Maybe I am making an some assumptions about your organization and your role, but my answer is "no".

This is an engineering issue. The engineer's lead should be enforcing this. If there is no lead, or people are obdurate, then the engineering manager should get involved. I recommend avoiding getting into the day-to-day blocking-and-tackling of engineering. There are many other important issues you need to address, and other groups need to hold up their end.

I think the project manager can emphasize that there are a set of policies/norms that include code standards. You can push for a clear set of rules, like "all new code" or module-by-module rules.

If you can measure how much slower this makes things, you can mention that as well. For example, when people are re-factoring code to conform to standards, they should do this as a separate bug, even if it was inline with a normal fix they made.

At some companies they do, and when the coding standards at those companies are good then the code is generally very readable.

I worked Java jobs in late 1990s and early 2000s where literally each team, or partner, that I worked with picked the opposite choice of the last one for whether a brace should come on the same line as the statement.

For years, I obligingly went back and forth. These days, I have settled on putting the open brace at the end of the line for the statement to which it belongs, and of course the close brace goes under the first character of that statement. That seems to be the predominant convention nowadays.

As for variable naming conventions, one of the best ones is to go with what the inventors of the language use.

perform_action is used in Python performAction is used in Java and C++ PerformAction is used in Visual BASIC

Hungarian notation is a big help only if you are programming in assembly language. In assembly language, your programs do not get checked for semantic error and for the most part your variables are not formally declared.

It is not that uncommon to see a long variable named "iTotal" or something else starting with "i" because it was changed from an int to a long at some point, but nobody was going to go back and rename every reference to it. Hungarian, rather than making programs more readable (even to Hungarians) creates a new kind of error. It actually does not prevent any kind of error at all.

Program modules (methods/functions/procedures and source files) should be small, and the scope of variables should be as narrow as possible. If you want to help your mates know at a glance what precise data type a variable is, then simply write your programs this way.

Variable names should be readable and understandable. Consider these variable names and their Hungarian brethren:

lineLength ill

dictionaryKey idk

patientName szTemp

It is pretty clear which naming convention is written for readability and which one fails. If the size and structure of your code is clear then you just need to pick variable names that are understandable and honest.

The way I've always seen it is that as soon as you start telling your programmers how to hold their pencils and how to form the letter 'a', you're doing it wrong. Enforce standards and good design patterns. But don't start telling me that I have to take out my alphabet stencil and follow the guidelines exactly.

I personally think it's a bad idea. Just because all the developers currently working on the project area very eperienced, who's to say that new developers will not have to maintain the code down the road? it would be pretty dificult to do so without any standards. Writing is one thing. Maintaining is totally different. I think you would be doing everyone a disservice, not to mention shooting yourself in the foot.

Never plan only for what you have, consider what happens if you need to add more people to the project. Are you guaranteed those people will be able to quickly get to grips with 10 people's individual standards?

I'd say you should have a standard. Wether the manager makes it, or the developers make it together, doesn't really matter, but you definitely should have one.

It seems to me that your project(s) isn't so complexed, valuable and important. Also members of your team isn't worried much about what they do, in other case they already would have coding standards policy which is agreed by all of them.

Time = Money

If there is mixup of coding styles code is harder to read for other persons, it takes longer to analyze code and repair bugs. When some of your teammebers find better job or be unavaliable by any other reason then coworkes can in easy and fast way continiue his tasks. If person who continiue task must dig in another style and try to mimic this then he has to fight with his own habbits and it takes much longer to complete the task. What worse the other person can completly ignore the style and do changes in his way. And you even can't imagine how distracting it can be when you come back to your project end there is some 'alien' code. You must take time either to fix it to your way or take little time multipled by times you reading code to process another stlke of codning. If someone arguing about such things it don'tr meat hat he got issues :P. Some people even don't realize that it causes decrase of speed while they work on project

This is example but i can multiply such situations.

And now some of your concerns...

Also we use some third party libraries that will never fit into our coding standards.

So use of most 3rd party libraries will be noticeable when you take a first look on code

I just have the feeling that forcing a coding standard is not as important as people make it. And people probably waste way too much time trying to make the code look like the coding standards perfectly.

Waste litle while coding save much while bug fixing/maintenance/passing project to other persons. In fact a waste isn't a waste, when people get used to new standards it would be so easy and obvious as breathing

Also it is easy to identify certain sections of code based on which coding standards are used when they are different.

This is wrong way to do such things, try something like this http://en.wikipedia.org/wiki/Subversion_(software) or similar solution dedicated to your platform.

So don't waste your time and make a meeting/some kind of brainstorm where you will discuss about it

Good Luck

MTH

There are many reasons already stated to have a good common style. I'm going to take this as a wetware question, rather than a code question.

What you really wanted to ask was "How can I get my programmers to use a consistent style without pissing them off."

I think the best way to deal with the issue is to take some time with all developers and let them negotiate the style.

It's easy to get them to agree that a standard style is important. It's hard to get them to agree to follow a style that's shoved down their throats.

Then, when there is some slack time, have one of them work up a style template for a code beautifier. At the very least, make an IDE configuration script so that most of the changes to style are automatic.

I'd say that it is absolutely needed.
I'd give these reasons:

• Easier to read other people's code.
• Easier to get programmers to work on multiple components.
• Easier to refactor code between components.
• Easier for new members of the team to get started.

YES!

Think what happens when you want to add a new member to the project. Or, even better, when you try to replace someone. Without a standard the existing team needs to waste their time on helping the newbie getting into it. And newbie needs to waste a lot of time thinking if his approach is correct when doing something.

Of course, 'standards' can have different levels of detail. I'm against going into detail too much, as it can be PITA to remember. But, some stuff like, for example, naming convention for code (classes, variables, etc.) and files (extensions, case, directories, etc.) should really be in there.

A coding standard of any kind is only worthwhile if:

• It reduces programming errors by adhering to best-practice prescribed patterns
• It makes existing code easier to maintain
• It makes new code easier to write

Definitely, do not use hungarian notation!

I don't want to suggest now on how to choose and coordinate developers on coding standards when the project is just started. But when you have a code base, and you take new people on board, you must give them time to adopt to your environment. This as well means following the rules that your code is written. Somebody new should not be allowed to just to go around changing or introducing styles. One should follow. In the company where I work projects were started by people with imho good taste for coding styles. We have senior devs who are reviewing code of newcomers, and if inconsistencies are found with what we are doing the commiter is corrected and asked to review his contribution. With time one learns the ways that things are done _within_the_company_.

So yes, coding standards are important. Because when working in a group people must understand each other in the first place. In dev environment there should be a 1) Respect, 2) Cooperation. If you have 10 people not learning from each other, and writing each in their own way then there is something wrong with your organization. In the end, isn't there a hierarchy in your dev. department? I mean, yes, if there is not much of professional and co-operational respect then you should enforce coding standards.