Fixing up the code style

Stefan Dösinger stefandoesinger at gmail.com
Sat Feb 22 12:50:02 CST 2014


(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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20140222/f174dccb/attachment.html>


More information about the wine-devel mailing list