[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnash-dev] Recent commit in devtools

From: ann
Subject: Re: [Gnash-dev] Recent commit in devtools
Date: Thu, 22 Feb 2007 12:21:03 +0100 (CET)

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]