Official Wine coding style rules/guidelines ?

[Indrek Altpere]

Hello

Would it be possible to get more of the guidelines written down on the
http://wiki.winehq.org/Developers-Hints or
http://wiki.winehq.org/SubmittingPatches pages, to get them set in stone,
so-to-speak? And also somehow show which components have different
guidelines and what are they?
Right now, all the information seems to get reiterated to each new
developer, causing a lots of overhead to the reviewers.

After being subscribed to this mailing list for a few months, I have noticed
a pattern with new developers trying to submit patches:
1) first patches tend to receive lots of style related feedback
2) due to the big list of changes requested, the developers tend to miss a
few with their resend and have to re-resend the patches again
         or due to the initial patches being too "out-of-style" the
reviewers missed a few places in the first round and point them out in later
round, causing the re-resend
3) sometimes the cycle goes on for quite a while

And to confuse things more:
1) sometimes different reviewers have different/conflicting opinions about
style rules
2) some rules are component specific, mostly set by the maintainer
3) http://wiki.winehq.org/SubmittingPatches has only general rules
3.1) "Follow the style of surrounding code as much as possible, except when
it is completely impractical to do so" - there have been many cases where
patches get rejected because although it was done in the style of
surrounding code, the component (or wine overall) has adopted new style
rules, which are not evident in the surrounding code at all.
3.2) as a minor issue, the reference to Developer-Hints in the guidelines is
not linked to http://wiki.winehq.org/Developers-Hints


Lots of work has already been done with the Developer-Hints page, but many
issues still come up in the mailinglist that have not been mentioned there.

UINT vs unsigned int, int* foo vs int *foo, -1 vs ~0U, function parameter
naming (Hungarian notation ? Ok for API function definitions based on MSDN
doc or not?).
Officially LONG use is suggested because long differs between 64bit linux
and 64bit windows. Should the developers also BOOL FLOAT etc uppercase
"safe" defines everywhere or not? true/false vs TRUE/FALSE?

It also seems that (at least in D3D related code) LP* usages are not
allowed, LPWSTR => const WCHAR * should be used for parameters.
But for example in kernel32/volume.c the LPWSTR is used in 10 places as
function parameter, const WCHAR * is used in only one place as function
parameter.
Is the LP* rule overall rule, is it D3D specific? If overall, then why is it
so widely used in all the kernel files? If D3D specific, how does the
developer know it beforehand?

Suggestions, comments etc ?

Regards,
Indrek Altpere