Limits of coding styles

[Dreis2211]

Hey guys,

today we had a rather serious discussion about one particular thing in our project. I would like to read your opinion on that, since we didn't come to a satisfying conclusion.

Background:

PHP introduced with version 5.4 a new short syntax for creating arrays.

<?php

//normal syntax
$array = array(
   'foo' => 'bar',
   'uncle' => 'bob'
);

//new short syntax
$array = [
   'foo' => 'bar',
   'uncle' => 'bob'
];

There are pros and cons to that feature of PHP, but that isn't the point of this discussion. In the end it's just taste.

The problem:

So we made a poll to get an overview about the different tastes on that and wanted to eventually decide if it's going to be a rule or not. Of course, it turned out to be a draw, which led our team-lead to the decision to enforce one of the two solutions. The team responded very bad on this decision, since both groups could live with the other way and doesn't wan't to be enforced. Especially - like in this case - when there is a 50/50 distribution and no common understanding.

The question:

Where does a good coding style end? Does it end when it comes to features of the current language? Isn't it "just" about naming, formatting and so forth? Has a good coding style even room for personal taste? Should a coding style be enforced by a lead or is the team's decision valid to allow both?

Now it's your turn. Thanks already in advance.

Cheers

[daniphp]

I always try to come up with arguments when it comes to choose between two styles. By the end of the discussion most of the team is loving my option.

You should avoid to make a decision just because you are the team leader if you think people will get frustrated. Maybe something like tossing a coin would solve your problem.

[unclebob]

A style guide describes all the things that don't matter; but that the team has to agree on.  Indentation, naming, various features, etc.

The best document for the style guide is the code itself.  The only reason you might need a separate document is when the code doesn't follow the guide.

[Sebastian Gozin]

I don't know about arguments. I have often seen teams just respond to every argument with "so?".

I've found these things are rarely rational never mind about things which matter. In this case I would prefer the short style but would also not care if someone used the old style. I don't want to force someone to use the short style but often people want to force you to use their preferred style. I usually respond poorly when their argumentation is about safety in a sloppy coding style. Nobody thinks we should write sloppy code but we should follow rules intended for sloppy code?

A consistent style is important but when it's about language constructs I just find it dumb and meaningless. Once we're coding in small scopes there really is no down side.

[Dreis2211]

Thanks so far for the answers!

The best document for the style guide is the code itself.

@unclebob: The code already uses both ways. So in a way, you could argue that there is no common style for that explicit case and it's okay to use both ways. The question is, if that's bad or not when it comes to language constructs. And in the end - if those decisions should be enforced by a leading role or decided by the team. Even if this decision means, that there is no rule to that.