Re: tabs vs. spaces in source code

[Han-Wen Nienhuys]

On Tue, Jul 28, 2009 at 1:05 PM, Jan
Nieuwenhuizen<address@hidden> wrote:

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

I am not sure; we had some other coding conventions that we reverted
(hungarian notation?).  If we had set things in stone then, we'd still
be writing foo_l_ for every pointer.

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

Given the release cycle of emacs, I think the last place for getting
things done is emacs-devel.  It would be much more productive to join
forces with a couple of other GNU C++ projects, who are also feeling
the annoyance of the style inconsistencies.

I am not sure I have the energy for the bikeshedding debates that
coding styles generate (this thread being another example of the
sort.)

On a larger scale, I am somewhat disappointed that a lot of the latest
lilypond efforts seem to be centered around janitorial work.   While
janitorial work is often useful and a good way to introduce yourself
to a code base, it should not become the focus of either development
or discussion about development.

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

When I say that I don't mind this change, I say it on a personal
title, with own vested interests. As a project leader (something that
I can't really call myself anymore), I would say that the discussion
and the reformatting is a waste of time, and people should find better
things to do.

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

I don't do a lot of mixing of styles; the google work happens on a
google machine with google specific settings.  I might need to tweak
things if I go do lilypond work from my work machine, but I feel
uncomfortable with that, given the copyright implications of doing so.

Different coding styles are a fact of life - perhaps you are also
prejudiced in that you mainly work on just OOO and GNU projects? The
linux kernel has its own style, KDE/Qt has, X11 has, etc.

> Hmm, we could just add this to every c++ file
>
> // Local Variables:
> // indent-tabs-mode: nil
> // End:
>
> that would fix everything, how about that?

Let's try to keep generated boilerplate to a minimum.


-- 
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen