EA Durbin wrote:
K&R style brack placements
They are an eyesore and make things difficult to read.
Highly subjective.
I think K&R has distinct advantages, namely it unites the scope begin token with the relevant control statement. For me, this makes code easier and faster to read, since I can follow the indentation and arrive immediately at the relevant control statement.
Also I think that K&R is nice in that it saves screen real estate, which again for me makes code easier to read because I can see more of it at once. I personally consider non-K&R style an eyesore because of this.
CMIIW, but the only thing that non-K&R has going for it is that you can visually make out whether you've made the correct number of opening versus closing braces. I don't think that's much of an advantage, especially considering that any modern source code editor will highlight the starting brace or relevant control statement for you.
That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum...
That said, I don't care what people do, I can read both... In my perfect world though, my SCM client would convert source code to my preferred format on checkout, and to whatever universal format the repository uses on checkin. Ho hum...
(Personally I hate K&R because I want to be able to see the braces line up vertically, else I find it hard to read. Of course, that's an aside since, not being a Wine developer, it's a little pointless saying my opinion; I just happen to like doing so anyway :P)
Anyway, the point:
How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style. By specifying a standard used by the repository it means that submitters can reformat their patches at submission time to avoid vast amounts of no-op changes caused by different formatting styles. This could be done automatically via an aliased `cvs diff` command, or whatever.
Alternatively each patch could be considered by a script (which really wouldn't have to be at all complex) which tries applying it, reformats it appropriately, generates a more appropriate patch, then unapplies it. This would make the process transparent to most developers, with the cost of more processing needing to be done at submission time - perhaps that would be unacceptable; I've no idea what kind of resources are available compared to what it would take.
Okay, I don't really expect this suggestion to be taken seriously since it involves modifying every file in the repository once, and potentially every patch, but I seriously think that it's an issue worth considering. Does anybody else think that it would be a feature that might really be used if it were implemented in <SCM of choice>?
On 6/2/06, Aneurin Price wine@shadovald.dyndns.org wrote:
How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style.
Our coding standard is that there shall be no coding standard. As was stated before, whoever creates the file, their style is the style that should be used when anyone makes changes to that file. Concerning the automatic source indenter, I know I would be peeved if i checked my code back out and it was changed to a style I don't like. There are way too many different styles of coding out there, and each developer has a right to like his or her own style, and we shouldn't force one specific style on anyone.
http://www.winehq.org/site/docs/winedev-guide/style-notes
James Hawkins schrieb:
On 6/2/06, Aneurin Price wine@shadovald.dyndns.org wrote:
How about setting a standard that will be used in the repository, and providing the indent commands to set it that way, then indenting *every file* in the repository to that standard. Then every developer can use indent or whatever equivalent they prefer when they checkout, if they don't like the chosen style.
Our coding standard is that there shall be no coding standard. As was stated before, whoever creates the file, their style is the style that should be used when anyone makes changes to that file.
The question is in how far that really works in reality. Even when leaving such (imho) minor things like K&R or not, spaces after if or not,etc aside. Just look at the tabs vs. space issue: I don't really have a problem with both of them but mixing them is imo the worst thing that could happen.
And things like this: (tabs = underscore, space = dots)
...if() { ______int foo; ______if() { ______.....do_something(); ......_____for() ......_____....do_somethingelse(); ______} ....} (and yes you really find things like this)
are just UGLY and if you don't have the exact same tabsize settings like the author you get complete "garbage".
Granted, I probably haven't even seen the majority of the source code and maybe I just found one of the few negative examples, but imho some kind of consensus here would be definitly a good thing.
4-space indention and using spaces instead of tabs already seems to be most used setting, so why not enforce it for everybody?
On 6/3/06, Peter Beutner p.beutner@gmx.net wrote:
The question is in how far that really works in reality. Even when leaving such (imho) minor things like K&R or not, spaces after if or not,etc aside. Just look at the tabs vs. space issue: I don't really have a problem with both of them but mixing them is imo the worst thing that could happen.
And things like this: (tabs = underscore, space = dots)
...if() { ______int foo; ______if() { ______.....do_something(); ......_____for() ......_____....do_somethingelse(); ______} ....} (and yes you really find things like this)
are just UGLY and if you don't have the exact same tabsize settings like the author you get complete "garbage".
Granted, I probably haven't even seen the majority of the source code and maybe I just found one of the few negative examples, but imho some kind of consensus here would be definitly a good thing.
4-space indention and using spaces instead of tabs already seems to be most used setting, so why not enforce it for everybody?
We do have a consensus about tabs vs. spaces. To quote the page I sent you in the last message:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
More and more this is being followed, but we won't force it on anyone. If someone creates a new page with tabs, we're not going to stop that code from getting in.
James Hawkins schrieb:
We do have a consensus about tabs vs. spaces. To quote the page I sent you in the last message:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
More and more this is being followed, but we won't force it on anyone. If someone creates a new page with tabs, we're not going to stop that code from getting in.
That is exactly the point. Unless you don't force it for everyone the consensus is more or less worthless. You have nice parts where people follow it and you have "ugly" parts where they don't follow it. In the end you have a horrible mix of everything. And that won't change. Especially for a project as big as wine I think it helps a lot in terms of readability to have some clearly defined coding styles.
Plus with the current policy in mind I am not sure it is "allowed" at all to send patches to fix some places with totally broken indendation, because maybe the author just liked that style ;)
James Hawkins wrote:
On 6/3/06, Peter Beutner p.beutner@gmx.net wrote:
The question is in how far that really works in reality. Even when leaving such (imho) minor things like K&R or not, spaces after if or not,etc aside. Just look at the tabs vs. space issue: I don't really have a problem with both of them but mixing them is imo the worst thing that could happen.
And things like this: (tabs = underscore, space = dots)
...if() { ______int foo; ______if() { ______.....do_something(); ......_____for() ......_____....do_somethingelse(); ______} ....} (and yes you really find things like this)
are just UGLY and if you don't have the exact same tabsize settings like the author you get complete "garbage".
Granted, I probably haven't even seen the majority of the source code and maybe I just found one of the few negative examples, but imho some kind of consensus here would be definitly a good thing.
4-space indention and using spaces instead of tabs already seems to be most used setting, so why not enforce it for everybody?
We do have a consensus about tabs vs. spaces. To quote the page I sent you in the last message:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
More and more this is being followed, but we won't force it on anyone. If someone creates a new page with tabs, we're not going to stop that code from getting in.
A tab is not defined as 8 spaces - it is defined as go to the next TAB STOP! The tab stop could be every 8 spaces or 4 spaces or 2 spaces or whatever has been defined. The tab comes from the manual typewriter and there were physical stops you placed where you wanted the carriage to stop at.
Cheers, Steve
On 6/3/06, Stephen Clark Stephen.Clark@seclark.us wrote:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
A tab is not defined as 8 spaces - it is defined as go to the next TAB STOP! The tab stop could be every 8 spaces or 4 spaces or 2 spaces or whatever has been defined. The tab comes from the manual typewriter and there were physical stops you placed where you wanted the carriage to stop at.
You misinterpreted the quote. "A tab is defined as 8 characters" means that when you're editing Wine code that has tabs in it, you should set your editor to display tabs as 8 spaces so that we all see the same indention from a tab.
James Hawkins schrieb:
On 6/3/06, Stephen Clark Stephen.Clark@seclark.us wrote:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
A tab is not defined as 8 spaces - it is defined as go to the next TAB STOP! The tab stop could be every 8 spaces or 4 spaces or 2 spaces or whatever has been defined. The tab comes from the manual typewriter and there were physical stops you placed where you wanted the carriage to stop at.
You misinterpreted the quote. "A tab is defined as 8 characters" means that when you're editing Wine code that has tabs in it, you should set your editor to display tabs as 8 spaces so that we all see the same indention from a tab.
hm but isn't it rather insane to require specific editor settings just to be able to *view* the code?
One could just write a perl script to parse the code upon submission that would convert it from K & R style to a uniform standard that it easy to read, and fix things like the amount of spaces in an indent.
From: Peter Beutner p.beutner@gmx.net To: James Hawkins truiken@gmail.com CC: Stephen.Clark@seclark.us, Aneurin Price wine@shadovald.dyndns.org,wine-devel@winehq.org Subject: Re: To K&R or not Date: Sun, 04 Jun 2006 01:49:55 +0200
James Hawkins schrieb:
On 6/3/06, Stephen Clark Stephen.Clark@seclark.us wrote:
"Tabs are not forbidden but discouraged. A tab is defined as 8 characters and the usual amount of indentation is 4 characters."
A tab is not defined as 8 spaces - it is defined as go to the next TAB STOP! The tab stop could be every 8 spaces or 4 spaces or 2 spaces or whatever has been defined. The tab comes from the manual typewriter and there were physical stops you placed where you wanted the carriage to stop at.
You misinterpreted the quote. "A tab is defined as 8 characters" means that when you're editing Wine code that has tabs in it, you should set your editor to display tabs as 8 spaces so that we all see the same indention from a tab.
hm but isn't it rather insane to require specific editor settings just to be able to *view* the code?
EA Durbin wrote:
One could just write a perl script to parse the code upon submission that would convert it from K & R style to a uniform standard that it easy to read, and fix things like the amount of spaces in an indent.
And thus the discussion comes full circle.
On Sun, Jun 04, 2006 at 02:12:15AM -0500, EA Durbin wrote:
One could just write a perl script to parse the code upon submission that would convert it from K & R style to a uniform standard that it easy to read, and fix things like the amount of spaces in an indent.
just use indent(1) - the tool that was made for that purpose. beside that i just write my patches the way i want them and then indent them either within the editor (vim) or using ident automatically. this way the you dont have to deal with insane things like 2-space-indenting (;P) while working with the file. for the patch you can also use ``cvs diff -uwbB'' so no spaces you changed while editing in code by others are recognized and the patch only contains your _real_ changes.
-
Aneurin Price -
Christoph Frick -
EA Durbin -
James Hawkins -
Molle Bestefich -
Peter Beutner -
Stephen Clark