Re: tabs vs. spaces in source code

[Jan Nieuwenhuizen]

On ma, 2009-07-27 at 18:50 -0300, Han-Wen Nienhuys wrote:
> On Mon, Jul 27, 2009 at 4:25 PM, Jan
> Nieuwenhuizen<address@hidden> wrote:
> 
> > Maybe we can start a repository at savannah that collects snippets
> > like this for all types of editor and all projects that decide to
> > add a little enhancement over the standard coding settings?  What
> > do you think?  That would make it fairly easy to cater for all kinds
> > of different standards!
> 
> While I appreciate the irony, this actually a stricter version of the
> standard, in that all of our (tab-less) code remains GNU standards
> compliant.   There are various areas where we have our own stricter
> standard, as compared to GNU, and I think we generally had a tendency
> to have ever stricter coding guidelines.  For example, we have
> underscores on class data members.

Yeah, we pretty much always did everything just the way we wanted.

I think we would have done well by stating/verifying our rules/ideas
with GNU.  Don't you think that stepmake as we have it now, was a
mistake?  Had we announced it, couldn't it have evolved  better or 
might we not have been talked into doing autotools after all?

Same for our Class_naming_scheme.  Now every project with classes has
their own naming scheme; while we were one of the first in GNU.  We 
could(should) have made a point of standardizing that (or at least
pressing for a standard) for GNU?  Don't you find the mess we have 
is for a big part our fault, and don't you find that annoying or silly?

Adhering to [already set] standards, first trying to standardise
something instead of running off by yourself, is something you
do for others.  In the short term (NOW), breaking the rules always
feels better :-)  If I could go back and switch to autotools,
I would have had to sacrifice valuable hacking time [at least 20min
per night], but I would possibly gain John's eternal love ;-)

> I don't see why we should not allow ourselves to be stricter wrt to
> tabs as well.

For one, I would rather like to see us being more standard rather
than less.  Second, the first time this started, people were discussing
creating coding standards (the SILLY/Zebra thread), not even
realising we have GNU.  It may make sense to start changing this,
but let's ask on emacs-devel?

Being stricter in this case means: documenting something that until
now was automatic.  I like the ideas: when you feel the need to 
document something that is broken, think hard if you cannot fix it
instead, if writing a script takes about as long as writing
documentation, automate it.

Have you never went in some project, made a patch, realise the
indentation is all wrong, quickly go to figure out what scheme
they *do* use only to find it's a big mess that cannot be
resolved with a global indent-region and you have to carefully
re-cut-and-paste the whole thing?

Are you sure that you are not looking at this from what is most
handy for your at this point in time (ie, Google standards)?
What if you/what about people who program a lot in linux/TAB style
projects, won't a change like this be super-annoying?

Practically: if I make the no-indent-tabs-mode global, I must
be very careful when editing other project's source codes;
otherwise I easily get wrong or big patches.  So for me, that 
does not work.  I *would* need the stupid /vc/lily* exception,
and if every project would do that...

I already have openoffice.org exceptions much like the elisp
code I showed, others use a special emacs instance when
editing ooo code, again others manually set ooo coding style
manually with every file they visit.  I am often too careless
for that and found myself editing code with the wrong settings.

So, how do you manage that?

Hmm, we could just add this to every c++ file

// Local Variables:
// indent-tabs-mode: nil
// End:

that would fix everything, how about that?

Jan.
-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl    | http://lilypond.org