On Sa, 2009-03-28 at 11:48 +0100, Christian Costa wrote:
Thanks for working on this part of Wine.
+/**************************************************************************
MCIAVI_drvClose [internal]- */
+static DWORD MCIQTZ_drvClose(DWORD dwDevID) +{
With greetings from copy & paste: There is no need to fix the MCIAVI != MCIQTZ mismatch in a second Patch. Fix it here, when you add the code.
You use TAB in the comments and also in the Code. Don't do that.
There are some discrepancies in the indentation and I don't mind removing tabs but what's wrong with them, they are commonly use in wine depending on one's taste.
Christian
Detlef Riekenberg a écrit :
On Sa, 2009-03-28 at 11:48 +0100, Christian Costa wrote:
Thanks for working on this part of Wine.
+/**************************************************************************
MCIAVI_drvClose [internal]- */
+static DWORD MCIQTZ_drvClose(DWORD dwDevID) +{
With greetings from copy & paste: There is no need to fix the MCIAVI != MCIQTZ mismatch in a second Patch. Fix it here, when you add the code.
You use TAB in the comments and also in the Code. Don't do that.
On So, 2009-03-29 at 12:50 +0200, Christian Costa wrote:
There are some discrepancies in the indentation and I don't mind removing tabs but what's wrong with them, they are commonly use in wine depending on one's taste.
Wine use 4 SPACE for indention. There is old code that use 2 or 3 SPACE, some old locations use TAB (width 8) and also some locations with TAB and SPACE mixed can be found.
The rule is to stay with the same style as used in the file before (2, 3 or 4 SPACE), but never mix SPACE and TAB in touched lines.
For new files, there is no old style to cover with, so 4 SPACE indention is expected.
I din't know wine has a indentation style. This is good news. That said, I don't understand then why we don't just convert wine's code (in several steps off course) and avoid troubles particularity switch from one style to another depending on the dll we are working on. I recently implemented d3dxof using a 2 spaces indentation style. I don't even know what led me to use this style because I prefer 4 spaces. Maybe there was few lines using it and I sticked to this style. I don't remember. I don't know either how this code could have gone into git. :-| So next time I will convert d3dxof to 4 spaces and see what happens to the patch. ;-)
Bye, Christian
Detlef Riekenberg a écrit :
On So, 2009-03-29 at 12:50 +0200, Christian Costa wrote:
There are some discrepancies in the indentation and I don't mind removing tabs but what's wrong with them, they are commonly use in wine depending on one's taste.
Wine use 4 SPACE for indention. There is old code that use 2 or 3 SPACE, some old locations use TAB (width 8) and also some locations with TAB and SPACE mixed can be found.
The rule is to stay with the same style as used in the file before (2, 3 or 4 SPACE), but never mix SPACE and TAB in touched lines.
For new files, there is no old style to cover with, so 4 SPACE indention is expected.
On So, 2009-03-29 at 18:12 +0200, Christian Costa wrote:
That said, I don't understand then why we don't just convert wine's code (in several steps off course) and avoid troubles particularity switch from one style to another depending on the dll we are working on.
Changing only the indention is not desired, as the history is falsified (Original Author and date/time of the the last code-change). Expect patches with unrelated indention changes to be rejected.
I recently implemented d3dxof using a 2 spaces indentation style. I don't know either how this code could have gone into git. :-|
Parts of the old code use 4 SPACE, other parts use 2 SPACE, but the Styple was not enforced tha hard in the old days.
So next time I will convert d3dxof to 4 spaces and see what happens to the patch. ;-)
I suggest to ask Julliard before you start with that. He might exceptional accept that style changes only Patch, as you did the major part of the code in that dll.
You're right. Not good for git blame. I will ask to Alexandre. Thanks.
By, Christian
Detlef Riekenberg a écrit :
On So, 2009-03-29 at 18:12 +0200, Christian Costa wrote:
That said, I don't understand then why we don't just convert wine's code (in several steps off course) and avoid troubles particularity switch from one style to another depending on the dll we are working on.
Changing only the indention is not desired, as the history is falsified (Original Author and date/time of the the last code-change). Expect patches with unrelated indention changes to be rejected.
I recently implemented d3dxof using a 2 spaces indentation style. I don't know either how this code could have gone into git. :-|
Parts of the old code use 4 SPACE, other parts use 2 SPACE, but the Styple was not enforced tha hard in the old days.
So next time I will convert d3dxof to 4 spaces and see what happens to the patch. ;-)
I suggest to ask Julliard before you start with that. He might exceptional accept that style changes only Patch, as you did the major part of the code in that dll.
-
Christian Costa -
Detlef Riekenberg