-----Original Message----- From: Vincent Béron [mailto:vberon@mecano.gme.usherb.ca] Sent: Tuesday, May 28, 2002 10:44 PM To: wine-patches@winehq.org Subject: Stripping of whitespaces at the end of lines
This is the first post in a series of posts about the same subject. The plan is to post the rest in the following days (as the total is >2MB uncompressed, I don't want to send it all at once). Each patch will be compressed (diff.gz) for that same reason.
Alexandre, if you don't intend to apply it, please say so (along with why), so I won't post some big patches for nothing.
Changelog
- Strips whitespaces at the end of some C lines.
Vincent
I would have thought it would be safer simply for Alexandre to do the stripping locally rather than posting a whole load of patches.
At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....;
Bill
"Medland," == Medland, Bill Bill.Medland@accpac.com writes:
>> -----Original Message----- From: Vincent Béron Medland,> I would have thought it would be safer simply for Alexandre to Medland,> do the stripping locally rather than posting a whole load of Medland,> patches.
Medland,> At the same time how about agreeing the size of a tab or Medland,> removing them altogether or agreeing always to use tabs for Medland,> progra, indentation or ....;
And having that ident rules documented bt the appropriate emacs/lint settings.
Bye
On May 29, 2002 10:58 am, Medland, Bill wrote:
At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....;
There no need to agree -- tabs are 8 spaces by definition. It's standard. As for the indentation size, I think it's time to agree on a size. It seems to me that most of the code is indented to 4 spaces. My very first contributions were indented to 2 spaces, but I now think that's a very bad idea, and I have since fixed those to 4 spaces.
It really helps to have consisten indentation when reading the code, (it's _much_ easier for the eye to identify patterns this way). Are there any objections to having the code indented to 4 spaces? (BTW, I'm not suggesting on agreeing where to but the curly brackets, I know that one's a stickler! :))
"Dimitrie O. Paun" a écrit :
On May 29, 2002 10:58 am, Medland, Bill wrote:
At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....;
There no need to agree -- tabs are 8 spaces by definition. It's standard. As for the indentation size, I think it's time to agree on a size. It seems to me that most of the code is indented to 4 spaces. My very first contributions were indented to 2 spaces, but I now think that's a very bad idea, and I have since fixed those to 4 spaces.
It really helps to have consisten indentation when reading the code, (it's _much_ easier for the eye to identify patterns this way). Are there any objections to having the code indented to 4 spaces? (BTW, I'm not suggesting on agreeing where to but the curly brackets, I know that one's a stickler! :))
-- Dimi.
Warning: Chaos lies ahead this path.
That's exactly what I didn't want to see. Let the developper choose the indentation style. But force him (or some janitor can do it) to remove unneeded spaces _after_ the end of the code on each line! This should make consensus.
Having said that, here's my take on the subject of indentation: tabs are 8 spaces, and results in smaller files (1 char vs 4). And if 80 chars is not enough, use a bigger window. There's a reason winedbg comes up in a window 132 chars wide.
Vincent
Warning: Chaos lies ahead this path.
Oh c'mon, we haven't had a good flame war in *ages* <g>.
Every good developer knows that tabs are evil, and that four space indentation is the way and the truth and the light...<grin>
Jer
On May 29, 2002 11:28 am, Jeremy White wrote:
Warning: Chaos lies ahead this path.
And why is that so? I see no chaos ahead, we can start with a recomandation of 4 space indentation...
Oh c'mon, we haven't had a good flame war in *ages* <g>.
Indeed!
Every good developer knows that tabs are evil, and that four space indentation is the way and the truth and the light...<grin>
No, no, no!!! Tabs are _not_ evil, tabs "defined" at anything else than 8 spaces *are* evil... The rest are good tabs!
-- Dimi "only the good tabs make it" Paun.
On Wed, May 29, 2002 at 10:28:01AM -0500, Jeremy White wrote:
Warning: Chaos lies ahead this path.
Oh c'mon, we haven't had a good flame war in *ages* <g>.
Every good developer knows that tabs are evil, and that four space indentation is the way and the truth and the light...<grin>
Many, many moons ago someone 'fixed' the copy of vi we were using so that ^D went out a tabstop instead of a shiftwidth! Apparantly he was trying to do 4 char indents by 'set ts=4' and indenting using 'tab' - instead of 'set sw=4' and indenting using ^I :-(
Another company I might have worked for enforces the braindead layout where ALL {} are indented with the code they bracket. Especially annoying because it included those for functions - so [[ and ]] don't work.
(Personally I prefer K&R placement of {} - and have since before I wrote any C.)
David
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
There no need to agree -- tabs are 8 spaces by definition. It's standard.
There's no need to agree because everyone should be using hard tabs (ASCII 9, \t, whatever you want to call it). Every editor on the face of the planet knows how to make these appear as however many spaces the user wants. So I can see the code with indentation size 8, and you can see it with 4, or 2, or 160, or whatever.
After the first non-whitespace character on a line, spaces should be used, since at that point, different numbers of hard tabs would be needed to get text on succeeding lines to be at the same column.
Since I've never contributed to Wine, I'm perfectly happy if everyone ignores my opinion on this, but I felt the need to combat the insanity of using spaces for indentation :-)
On Wed, 29 May 2002 jon@siliconcircus.com wrote:
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
There no need to agree -- tabs are 8 spaces by definition. It's standard.
There's no need to agree because everyone should be using hard tabs (ASCII 9, \t, whatever you want to call it). Every editor on the face of the planet knows how to make these appear as however many spaces the user wants. So I can see the code with indentation size 8, and you can see it with 4, or 2, or 160, or whatever.
After the first non-whitespace character on a line, spaces should be used, since at that point, different numbers of hard tabs would be needed to get text on succeeding lines to be at the same column.
Since I've never contributed to Wine, I'm perfectly happy if everyone ignores my opinion on this, but I felt the need to combat the insanity of using spaces for indentation :-)
Absolutely. If you use \t, then anyone looking at the code can choose the size of indents. I *despise* space-based indenting, almost as much as I despise mixed indenting (eg. 4-space indenting with every pair of 4-space indents being converted into a single tab).
As you point out, a good discipline on the use of tabs does pretty much cater to everyone's tastes. However you can't assume that using spaces after the first non-whitespace character will ensure arbitrary column alignment (eg. for end-of-line comments). At least not between lines that have differing indentation.
Cheers, Geoff
On May 29, 2002 11:59 am, Geoff Thorpe wrote:
Absolutely. If you use \t, then anyone looking at the code can choose the size of indents. I *despise* space-based indenting, almost as much as I despise mixed indenting (eg. 4-space indenting with every pair of 4-space indents being converted into a single tab).
Sorry, this does not work. People _will_ use spaces, and so having the tab at anything other than 8 is simply silly. The tab (\t) _is_ 8 spaces. Period. If we are to have anything decent, we should decide (at least as a recommendation) on an indentation size. From looking at the code, 4 seems to be the norm. Let's pick that.
On Wed, May 29, 2002 at 12:08:33PM -0400, Dimitrie O. Paun wrote:
On May 29, 2002 11:59 am, Geoff Thorpe wrote:
Absolutely. If you use \t, then anyone looking at the code can choose the size of indents. I *despise* space-based indenting, almost as much as I despise mixed indenting (eg. 4-space indenting with every pair of 4-space indents being converted into a single tab).
Sorry, this does not work. People _will_ use spaces, and so having the tab at anything other than 8 is simply silly. The tab (\t) _is_ 8 spaces. Period. If we are to have anything decent, we should decide (at least as a recommendation) on an indentation size. From looking at the code, 4 seems to be the norm. Let's pick that.
Yep, I'm also pro 4 spaces :-) *If* we decide to use 4 spaces, then we might also want to decide whether to abolish tab-based "double 4" or "quattro 4" replacements or not. Or, in other words: whether we want to have all indentations based on spaces, instead of also using \t where it fits into the current indentation level.
Oh, and of course I'm all for *not* making this decision too obligatory. (unless someone comes up with some completely wild indentation, that is ;)
Andreas Mohr andi@rhlx01.fht-esslingen.de writes:
*If* we decide to use 4 spaces, then we might also want to decide whether to abolish tab-based "double 4" or "quattro 4" replacements or not. Or, in other words: whether we want to have all indentations based on spaces, instead of also using \t where it fits into the current indentation level.
Mixing tabs and spaces should be avoided because it makes the diff output unreadable. And of course the one true indentation is 4 spaces, but I'm not going to enforce that.
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
Sorry, this does not work. People _will_ use spaces, and so having the tab
If you think people will use spaces, no matter what you specify, then you might as well give up making any kind of standard at all. If you're both expecting people to ignore your standard and not willing to rigorously enforce it, don't bother going to the effort of making it.
On May 29, 2002 12:45 pm, jon@siliconcircus.com wrote:
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
Sorry, this does not work. People _will_ use spaces, and so having the tab
If you think people will use spaces, no matter what you specify, then you might as well give up making any kind of standard at all. If you're both expecting people to ignore your standard and not willing to rigorously enforce it, don't bother going to the effort of making it.
Enforcing 'no space before the non-blank char on every line' is orders of magniture more difficult than 'indentation is 4 space' (which, BTW, most people use anyhow). On top of it, what do you gain? A dubious benefit of being able to see the code at a different indentation level, which can NOT work anyway. If you've ever tried it, you would realize that it's a silly idea.
Example: if ( blah & blah & ... aaaa & bbbb & ...)
How do you nicely align the "aaaa & bbbb & ..." line below the "blah & blah & ..." using only tabs? Aha, so you have to use spaces!
So the rules are complicated, who do you think will follow them? And for what???
-- Dimi.
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
you gain? A dubious benefit of being able to see the code at a different indentation level, which can NOT work anyway.
Actually, I've worked on several projects (one of which I'd estimate, without counting, as being twice as many LOC as Wine) where tabs have been enforced. Worked fine. (I'm not about to suggest LOC as any great measure of a project, but indentation style is one of the few discussions where it's a useful metric.)
If you've ever tried it, you would realize that it's a silly idea.
See above.
Example: if ( blah & blah & ... aaaa & bbbb & ...)
How do you nicely align the "aaaa & bbbb & ..." line below the "blah & blah & ..." using only tabs? Aha, so you have to use spaces!
Yep. What you end up with is:
<tab>if ( blah && foo && baz && <tab>_____gnerk && blerk)
...where the underscores are indeed spaces. Everyone, no matter their tab size, sees the same.
So the rules are complicated, who do you think will follow them?
Actually, a lot of editors can follow them automatically.
And for what???
Readable diffs, consistent code, everyone being able to use their own indentation level, smaller source files, easier cursoring across indentation levels with a well-configured editor, no reason to argue about whether "a tab is 8 characters". Take your pick.
I'm not going to try and convince you further, especially since Alexandre says he's not going to enforce anything anyway, but tab characters were created for a reason :-)
Hi there,
First, if you reply to this please just send it to the list - I don't need personal copies of every email on this thread - what kind of foolishness is it where everyone hits "reply to all" on list mail??? A little netiquette please ...
On Wed, 29 May 2002, Dimitrie O. Paun wrote:
On May 29, 2002 11:59 am, Geoff Thorpe wrote:
Absolutely. If you use \t, then anyone looking at the code can choose the size of indents. I *despise* space-based indenting, almost as much as I despise mixed indenting (eg. 4-space indenting with every pair of 4-space indents being converted into a single tab).
Sorry, this does not work. People _will_ use spaces, and so having the tab at anything other than 8 is simply silly. The tab (\t) _is_ 8 spaces. Period. If we are to have anything decent, we should decide (at least as a recommendation) on an indentation size. From looking at the code, 4 seems to be the norm. Let's pick that.
Hey, I'm not grappling with your code so this isn't my problem. But this "tab _is_ 8 spaces" stuff is fact by statement. The mere fact that I can change, in any editor I choose, the _default_ representation of tab characters from 8-space alignments to <2|4|whatever>-space alignments shows that your statement is moot. What any standard or spec has to say about it matters not one iota. Moreover, to the person who said it was not possible to use tabs for indentation and let people choose their visual representation of tabs, simply because of things like;
if ( aa == bb && ..... cc == dd && ..)
That assumes that you use expression alignment to guide indentation of broken lines rather than indentation levels. If you use expression alignment, then you are from the same school of thought that bastardisation of HTML is legitimate because GUI-rendering of HTML is the paramount consideration. There are other schools of thought that state that source code, like HTML, exists to logically describe context and mechanics. Logic before aesthetic. Etc. If you want to do ASCII art, source code is probably not the place.
A tab's role historically was to represent a level of indentation. Quoted paragraphs, lists, etc - all got an extra level of indentation than the parent text. You could also use nesting - ie multiple levels of indentation to represent scope. Sounds a lot like indentation of source code, doesn't it? Yes, traditionally it's 8 spaces and that's the default on many editors. Fine. And many people prefer 4 space indentations, and funnily enough virtually all sane editors allow you to change the visualisation of the tabs to however many characters you prefer (including 4). This also uses one ASCII character to represent one logical item - a unit of indentation. OTOH spaces have no logical nor aesthetic relationship to indentation/alignment, generate much larger files, and force the visualisation rather than defining context and leaving visualisation to editor defaults and user preferences. Think HTML with hardcoded fonts vs HTML with context tags (<B>, <H[1|2|...]>, etc).
Using spaces and disregarding tabs because "tabs _are_ 8 spaces" and "8 spaces is too much" is not rational, and it's not logical. It generates code that is bigger, less flexible, prone to inconsistencies, and all because of rules that in reality don't exist.
Cheers, Geoff
On May 29, 2002 01:48 pm, Geoff Thorpe wrote:
Hi there,
First, if you reply to this please just send it to the list - I don't need personal copies of every email on this thread - what kind of foolishness is it where everyone hits "reply to all" on list mail??? A little netiquette please ...
This is how things are setup on wine-* lists. If you hit "Reply", it just goes to you, not the list. Anyway, I'll edit the header for you from now on.
broken lines rather than indentation levels. If you use expression alignment, then you are from the same school of thought that bastardisation of HTML is legitimate because GUI-rendering of HTML is the paramount consideration. There are other schools of thought that state
No, it's the other way around. You use expression alignment because it's easier on the eye, not the automatic tool. Indentation and alignment is essential because it conveys structure. Brackets, for that matter, are rather useless -- if the code is not properly indented and formatted, noone will parse the brackets to figure out the structure.
that source code, like HTML, exists to logically describe context and mechanics. Logic before aesthetic. Etc. If you want to do ASCII art, source code is probably not the place.
We're not talking about ASCII art here, we're talking about an aesthetic source base. If that's not important to you, we really have nothing to talk about.
A tab's role historically was to represent a level of indentation. Quoted
Indeed. And when you print you code, how much will the printer indent a tab? Anyway, it seems we talk for the fun of it (?), but let me summarize my ideas: -- if you can avoid mixing tabs and space, all power to you It is nice, generates better diffs -- I don't believe it pays to enforce *no* spaces at the beginning of the line. It's nice, I like it too, but sometimes I do use spaces. -- I think it's *much* simpler and has a bigger payoff if we nicely recommend people use 4 space indentation, however they choose.
To conclude, I think source is like a picture. It is visual. You should look at it like at a nice drawing. You will notice that in general, the tools used to create drawings are more about that "how" rather than about the "what" to do. In other words, they don't give you much abstraction. I am a firm believer in separating content from presentation. But I'm not at all convinced that using the very thin abstraction of \t is worth getting religious about. Paper thin abstractions don't work. That's why people don't use HTML to convey content but have moved to XML, leaving HTML to worry about the presentation.
"Medland, Bill" a écrit :
-----Original Message----- From: Vincent Béron [mailto:vberon@mecano.gme.usherb.ca] Sent: Tuesday, May 28, 2002 10:44 PM To: wine-patches@winehq.org Subject: Stripping of whitespaces at the end of lines
This is the first post in a series of posts about the same subject. The plan is to post the rest in the following days (as the total is >2MB uncompressed, I don't want to send it all at once). Each patch will be compressed (diff.gz) for that same reason.
Alexandre, if you don't intend to apply it, please say so (along with why), so I won't post some big patches for nothing.
Changelog
- Strips whitespaces at the end of some C lines.
Vincent
I would have thought it would be safer simply for Alexandre to do the stripping locally rather than posting a whole load of patches.
At the same time how about agreeing the size of a tab or removing them altogether or agreeing always to use tabs for progra, indentation or ....;
Bill
I didn't want to start something about tab dimensions (not _that_ stupid). If we begin something about that, the next subject will be the mandatory use of vi to edit the files ;)
But there are a lot (>20000) of lines which have either some spaces/tabs or combination of both after the final ";" (or "," in the case of function arguments splitted on a couple of lines.) IMHO, it'd be better to remove them (although I admit it's mostly for esthetics reasons).
On the same vein, there are also a couple of instances where the final semi-colon is doubled, eg: "return S_OK;;". I removed the second one when grep encountered them.
If Alexandre wants to do it locally, I support him (our mailboxes will appreciate).
Vincent
Vincent Béron vberon@mecano.gme.usherb.ca writes:
If Alexandre wants to do it locally, I support him (our mailboxes will appreciate).
If you want me to do that please send me a script that I can run across the tree to do the change. Please don't send patches for this kind of things.
Alexandre Julliard a écrit :
Vincent Béron vberon@mecano.gme.usherb.ca writes:
If Alexandre wants to do it locally, I support him (our mailboxes will appreciate).
If you want me to do that please send me a script that I can run across the tree to do the change. Please don't send patches for this kind of things.
-- Alexandre Julliard julliard@winehq.com
Here it is. It only targets .c and .h files. The diff was ~4MB in size between before and after. The savings in a .tar.gz of the whole tree were modest, around 25KB.
Now to find a good set of arguments to feed indent(1) so we all use the same coding style...
Not! ;)
Vincent
#!/bin/sh
FILELIST=`find . ( -name *.c -o -name *.h ) -print` EXTENSION=notrailingspaces
for eachfile in ${FILELIST}; do sed -e "s/[[:space:]]+$//g" ${eachfile} >${eachfile}.${EXTENSION} ; sed -e "s/;+$/;/g" ${eachfile}.${EXTENSION} >${eachfile} ; rm ${eachfile}.${EXTENSION} ; done
-
Alexandre Julliard -
Andreas Mohr -
David Laight -
Dimitrie O. Paun -
Dimitrie O. Paun -
Geoff Thorpe -
Jeremy White -
jon＠siliconcircus.com -
Medland, Bill -
Uwe Bonnes -
Vincent Béron