13

The Problem: Two developers => three opinions on indention, braces on new line or not etc.

We usually work with three or four people on our projects and each of those has it's own code style. I know, the common solution is to agree on a code style, everybody has to use, but I don't want to force creative programmers in a suit that does not fit them.

So the question is: Is there a way to let each programmer live his/her own style, but having a common code base inside the repository? I think of some git/svn/whatever plugin, which changes between personal and common style on checkout and commit. It appears to me, that the tricky part in this approach is to support correct diffs between the versions of a file

|improve this question
  • 1
    There are automatic code formatters available for most languages, but for some (e.g. C++) they are extremely difficult to make fully reliable because of the complexities of parsing the language. – Joris Timmermans Mar 6 '13 at 10:12
  • 4
    Really a bad idea. Ask your team to come up with a consensual standard, then make them apply it. If some wine, tell them to grow up a little. – Clement Herreman Mar 6 '13 at 10:30
  • 8
    Maybe the other extremely common remark needs to be made here: is there an actual problem with the differences in code styles? Don't fix something that isn't broken! – Joris Timmermans Mar 6 '13 at 10:34
  • 5
    "but I don't want to force creative programmers in a suit that does not fit them" - if your programmers can't adapt to simple things like indentation or brace style changes, you need to hire better developers. Once you use a new style for a week or two you forget about it. – Mike Weller Mar 6 '13 at 12:35
  • 4
    @MikeWeller Couldn't the opposite be argued? Naming conventions are the only thing I've ever considered important since it makes it easier to identify a thing's purpose outside of its definition context. As long as somebody is semi-consistently styling for clarity of where blocks nest, begin and end, I've never understood why it should be such a big deal. – Erik Reppen Mar 6 '13 at 14:43
20

No, you will need to make a standard. If you have team member B change (either with an automated IDE tool, or manually) a whole heap of code team member A wrote, that will be committed and show as a change.

This is something almost every team faces and standards are "forced" for this very reason. I would suggest you follow the language authorities standards as a baseline and adopt them to suit your team.

Having a consistent coding style will also help in the maintainability of the project and reduce the barrier to entry for new people working on the code.

|improve this answer
11

No, you will need to define a coding standard (preferrably one which already exists) and have your developers adhere to it. Being a professional programmer means that you are able to adapt to whatever coding standard is used in the project you're working on.

|improve this answer
  • 2
    +1. Let them choose one, but make them apply it. – Clement Herreman Mar 6 '13 at 10:30
  • I wished formatting was part of the standard of a programming language, such that programs are not just "valid" or "not valid", but have a third state as well, "valid and well-formatted". – JesperE Mar 6 '13 at 12:37
  • 4
    it's (more or less) the case in python, where indentation is a language semantic. – Clement Herreman Mar 6 '13 at 13:17
  • 2
    Go isn't strictly enforcing such, but comes with a built-in source code formater, go fmt. See golangtutorials.blogspot.fr/2011/06/… – Clement Herreman Mar 6 '13 at 14:21
  • 1
    @JesperE That is implemented in Python with PEP8 and the corresponding tool, inventively named pep8. – phihag Mar 6 '13 at 17:38
8

YES, it can work as long as the styles are all sensible and people don't go around changing other peoples' code to match their preferences and/or mix styles in a single code file.
It's not ideal, but it's no different from inheriting old code created to a different "standard" from your own and having to integrate it with your codebase.
So if you have to do it, some guidelines:

  • no changing differently styled code to match your preferences, it costs time and introduces bugs
  • remain consistent within any single file. So if style A was used to initially write it, everyone will use style A when modifying it
  • do create a common standard for your public interface, so for everything that is exposed to the outside (and yes, other subcomponents of a system are the outside).
|improve this answer
  • 2
    I'd add that professional developers often tend to merge each other's styles anyway. They will have short informal discussions on some points and come to an agreement. – Joris Timmermans Mar 6 '13 at 10:10
  • The works great, with the caveat that the use of automatic code reformatting needs to be kept to a minimum (if not outright banned). – grahamparks Mar 6 '13 at 10:30
  • 2
    "no changing differently styled code to match your preferences, it costs time and introduces bugs" - quite the opposite - matching a non automated standard by hand is very wasteful of time, running a code formatter, commiting the change as 'formatted with options -whatever " then making functional changes is much faster. – Pete Kirkham Mar 6 '13 at 10:31
  • I think this answer actually may have missed the "automatic formatting" part of the question? – Joris Timmermans Mar 6 '13 at 10:41
  • A variety of styles between files is much harder to deal with than just having a consistent style. – Andy Apr 5 '15 at 20:57
4

The short answer is No.

While opinions are to be valued in work especially in a knowledge based job such as Software Development, developers have to realise that an opinion is just that an opinion and that they are there to write software not argue over which line indentation standard is best.

The goal of a standards document should be to enforce/suggest a set of common coding standards/conventions that addresses

  1. Layout Items such as tabbing, indentation, use of {,( ,
  2. Variable, Object and Function name i.e. CamelCase, Hungarian notation
  3. Exception Handling how/when/where is it to be performed
  4. Code comments. Do you always reference a design doc, a bug number etc

The standards documents helps to ensure that the code is easy to read, maintain and consistent in its conventions.

This is invaluable when reviewing the code before checkins, debuging someone elses code or modifying the code several years after the original developer has left the company.

Normally when creating a Coding Standards document I review the industry standards for the language I am using (C, C#, SQL), use the most appropriate standards, circulate to the most senior/influential developers for comment, incorporate the comments where appropriate and then release the document.

|improve this answer
  • 1
    In actual practice, many shops have one developer who is usually the Old Hand or the PrimaDonna who seems to delight in creating Formatting Holy Wars for the rest of the people to deal with. Professional == Whatever I say. Whatever you guys say == Non professional. And then it devolves. I've seen coding standards mandating gross things like "Use lots of global variables, never create new classes, avoid object oriented programming at all costs, and don't change anything, ever". Sadly there is no limit to what people try to cram into the scope of something called "Coding standards". – Warren P Mar 6 '13 at 16:01
4

Automatically reformatting code before it is committed to your version control system is possible in theory.

However, there is one big problem: automatic code formatting tools are not 100% reliable. Thus, you could actually introduce problems in your code with this system. In my mind, that kills the idea. It is always more important to have functional code than properly styled code!

If the project is compartmentalized, and most parts of the code tend to be "owned" by individual programmers, then it may be ok to let them use their own styles (within reason). However, if several people are frequently working on the same piece of code, it is probably necessary to enforce a style.

Here is a similar discussion on Stack Overflow.

|improve this answer
  • 2
    Note the accepted answer on the linked discussion too! – Joris Timmermans Mar 6 '13 at 10:40
1

One-way automatically reformatting code may be a workable solution if you :

  1. Find an autoformatter that actually works for the convention you want to implement and your programming language.
  2. Can do it pre-commit so the reformatting doesn't show up in the change logs mixed with and indistinguishable from the actual functional changes.
  3. Manage to get your team to agree on which convention should be applied (because generally speaking there is no "way back" on check-out to a developer's personal preference, at least not that I know of).

None of those are actually easy to do in many cases, so consider picking your battles here! I've seen teams do this successfully for a C#/.NET project where the reformatting happened already on the developer's PC, so it is possible in some circumstances.

|improve this answer
1

absolutely you can. Its all about not sweating the small stuff.

The only standard that matters is "keep your changes the same style as the existing code". As long as you can fit yourself to a coding style that isn't your preferred one, then you can work with any coding style.

So what's the big deal about working in 3 different styles within the same company. Your developers need to understand this, that writing code in the way they like is find for their code but once they make changes to a different file that uses a different style, they have to maintain that style (or it'll really look bad). No reformatting is allowed (or they'll just reformat continually and the scm diffs will be useless)(and if you do this, then a auto formatted should be employed).

Chances are, once they get going with this, they'll come to some consensus about which style to use or they style will drift together for the most part. If they're going to be childish about it and will reformat each others code all the time, then it'll be time to download a standard from the internet and demand they use it. You might want to do this anyway, just to wave it in their faces as an "play nice or else" card.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.