On Tue, Jul 28, 2009 at 1:05 PM, Jan Nieuwenhuizen<janneke-l...@xs4all.nl> 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 - han...@xs4all.nl - http://www.xs4all.nl/~hanwen _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel