> salierix <salierix@xxxxxxxxx> wrote: > > While looking for some source code to make conform to the coding > > guidelines, > > I noticed that all of the header files written by > > "Erik Jaesler" use a very strange form of indentation, and are not > > compatible with the coding guidelines. > > Not just those. In fact, even though our coding style is pretty clear > on this, some of us prefer a different header style which you'll find > all over the place. Application.h is one example of that; the only > thing that has been agreed on changing would be the argument spacing > on > the second line in for example ResolveSpecifier() in favor of how > it's > done for _InitData() (both in the original version of Application.h). > So until we actually sit together and find a compromise on this, I'm > afraid updating the header wouldn't make much sense, sorry. But maybe > that's a good time to start this discussion again; it's the first > time > a contributor has to suffer because of it. Count me as one of the proponents of the "alternative" format. We had this discussion a few times now and I think we always came to the conclusion that it is really a matter of taste and being used to. Although I really have a hard time working with the version we have in the style guide. I am just so used to have the headers "in columns" of keyword, type and methodname. In my eyes the "columned" format is just the cleaner looking one and it has no real disadvatages. I've actually adopted this from some of the original BeOS headers which aren't consistent there either. From a quick glance at the headers under R5 it seems to be about the following: app, game, interface, midi, storage and support kit headers are mostly using the "columns" style. media, midi2, net and translation kit headers are mostly using the "flat" style we currently have in our style guide. So it's not really uniform. I personally probably adopted the "columned" format, because it was the first thing I got in real contact with (i.e. app, interface and storage kit headers in my case) and found very nice to work with. Regards Michael P.S.: While we are at discussing matters of taste, we could also again argue about the pros and cons of "char *variable;" and "char* variable;" ;-)