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