(Soory for the top post, phone...)

I think the idea is to use spaces after keywords but not macro / function names. But I don't know what the exact logic and rationale is.

I'll write a wiki page about the wined3d code style the next time I review a patch with style issues or when I have some spare minutes and the necessary motivazion.

Am 22.02.2014 19:45 schrieb "Chiitoo" <escomk3@hotmail.com>:
Teegrins!


On 13/02/14 15:09, Stefan Dösinger wrote:

Hi,

After recently helping two contributors (the Pipelight guys and Martin
Storsjö) through the maze of the Wine code style I think it's best to
lift the ban against style-only patches and unify the code style once
and for all.

The basic reasoning is that from my point of view the lack of clarity
wrt the code style and lack of automatic enforceability is causing
more issues than the problems style-only patches cause with git blame.
Finding a style-only change with git blame can be handled by running
git blame again. Frustrating contributors on the other hand has no
workaround.

So I propose to agree on a code style for the entire project, fixing
it up preferably with an automated tool and in the future enforcing
the style with checks in the Testbot.

Opinions?

Wrt the code style I propose the style that is used in wineserver. It
is the same one as the new style in the d3d code except for
single-line if conditions.

Cheers,
Stefan

I, for one, like this idea.

Not that my likes mean much (if anything), at least not yet, but I'm hoping one day I am able to contribute actual code to the project.  As such, I have been delving more and more into the code of Wine, and I tend to learn from my surroundings, where inconsistency certainly isn't too helpful.
It might also mean that I would further make it inconsistent by following whatever conventions happen to be around specific code (although that in itself could be considered consistent, in a way, though I am aware of changing code to follow a certain style being a thing while editing particular code for some other reason).

Either way, for what it's worth, I like the proposal.


Also, I have a more or less related (possibly silly) question as well, which is what pushed me to post here for the first time ever just now:

As I understand it, a whitespace is to be used after 'ifs' and such.  Why is this not the case for TRACEs, ERRs, WARNs, and the likes as seen in the example below?


if (cs->state.textures[i] == prev)
{
    TRACE("Texture is also bound to stage %u.\n", i);
    prev->sampler = i;
    break;
}

Perhaps it's wrong for me to group those things together at all, but I guess it would just look better to me if there was a space after TRACE as well.


Just some thoughts!

Kind Regards (and many thanks),
Chiitoo