Re: [Gnash-dev] Recent commit in devtools

[ann]

On Thu, 22 Feb 2007, Martin Guy wrote:

> > The coding standards discussion came up when Rob was in the Netherlands
> This is one danger of personal meetings: "decisions" can seem to have
> been taken that affect the whole project with little thought and few
> heads involved when public discussion might achieve more useful
> consensus.
This is why I sent a mail to dev before I made any changes whatsoever
to the source code.

> Some of the layout is awful, particularly where some clever bod has
> set tabstop=2 in their editor and then used a mixture of tabs and
> spaces to indent different lines. The result on any standard terminal
> is gobbledegook. If you can find and fix those files you'd be doing
> the world a big favour!
I think there's general agreement that inconsistent indentation is the
biggest stylistic problem.  I also agree with that; I see the cuddled
elses check as a proof-of-concept test.

> Which send us yet more email pestering about layout?
> Or which reject a commit until the layout conforms to the bot's rules?
> I don't find either of these things desirable.
I don't think that people who have write access to the repository should
have their commits rejected for this reason.  As for notifications, I don't
see any reason why the commit message couldn't be modified to also include
an additional message if any tests failed as a result of the commit.  Of
course this would only be of value if the codebase passed tests by default.

> > Additional tools could be vim and emacs codas,
> I am generally against editor-specific settings in source files unless
> the program  is for one person's personal use onl, and even then it's
> idiosyncratic.
I am also against including editor settings in source files.  For one,
it makes it difficult to maintain if a new rule is added or an old rule
is modified.   However, I see no reason not to make editor settings available
for two of the most common editors.  Developers can then optionally import
the settings, or even make them their default settings if they desire--or
avoid them entirely.

[...]

> I'm not sure that spending hours haggling over layout rules is very
> productive anyway; it reminds me of the wheel-invention committee
> being unable to invent the wheel because they couldn't decide what
> colour it should be.
If we start discussing style rules, it will indeed be a big waste of
time, since everyone will have her/his own opinion.  The easiest thing
to do is to go with the rules which Rob, as the project leader, laid
out in the documentation.

- Ann