From: Lino Sanfilippo
> Sent: 04 November 2016 20:07
...
> In this case it is IMHO rather the declaration + initialization that makes
> "bar" hard to find at one glance, not the use of RXT. You could do something
> like
>
> [longish list of reverse xmas tree identifiers...]
> struct f
Joe Perches writes:
> On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
>> From: Madalin Bucur
>> Date: Wed, 2 Nov 2016 22:17:26 +0200
>>
>> > This introduces the Freescale Data Path Acceleration Architecture
>> > +static inline size_t bpool_buffer_raw_size(u8 index, u8 cnt)
>> > +{
>> > +
On Fri, Nov 04, 2016 at 10:05:15AM -0700, Randy Dunlap wrote:
> On 11/03/16 23:53, Joe Perches wrote:
> > On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
> >> From: Madalin Bucur
> >> Date: Wed, 2 Nov 2016 22:17:26 +0200
> >>
> >>> This introduces the Freescale Data Path Acceleration Archit
On 04.11.2016 18:44, Joe Perches wrote:
> On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote:
>> From: Lino Sanfilippo
>> > On 04.11.2016 07:53, Joe Perches wrote:
>> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to
>> >> shortest
>> >> #446: FILE: drivers/net/ethernet/ethoc.
On Fri, 2016-11-04 at 11:07 -0400, David Miller wrote:
> From: Lino Sanfilippo
> > On 04.11.2016 07:53, Joe Perches wrote:
> >> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to
> >> shortest
> >> #446: FILE: drivers/net/ethernet/ethoc.c:446:
> >> +int size = bd.
On 11/03/16 23:53, Joe Perches wrote:
> On Thu, 2016-11-03 at 15:58 -0400, David Miller wrote:
>> From: Madalin Bucur
>> Date: Wed, 2 Nov 2016 22:17:26 +0200
>>
>>> This introduces the Freescale Data Path Acceleration Architecture
>>> +static inline size_t bpool_buffer_raw_size(u8 index, u8 cnt)
>
From: Lino Sanfilippo
Date: Fri, 4 Nov 2016 12:01:17 +0100
> Hi,
>
> On 04.11.2016 07:53, Joe Perches wrote:
>>
>> CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to
>> shortest
>> #446: FILE: drivers/net/ethernet/ethoc.c:446:
>> +int size = bd.stat >> 16;
>> +
Hi,
On 04.11.2016 07:53, Joe Perches wrote:
CHECK:REVERSE_XMAS_TREE: Prefer ordering declarations longest to shortest
#446: FILE: drivers/net/ethernet/ethoc.c:446:
+ int size = bd.stat >> 16;
+ struct sk_buff *skb;
should not this case be valid? Op
Joe Perches writes:
> #define VDREG8(a0) ((const u16[]){\
> a0 + 0x000, a0 + 0x010, a0 +0x020, a0 + 0x030, \
> a0 + 0x100, a0 + 0x110, a0 +0x120, a0 + 0x130})
>
> as "const u16[]" is a $Type but "const u16[]" is not.
>
> Still, as written, the code seems fragile a
On Mon, 2015-06-22 at 08:38 +0200, Krzysztof Hałasa wrote:
> Joe Perches writes:
>
> > It might be better to use some base + index macro
> > as it could be smaller object code.
> >
> > Something like:
> >
> > #define REG_NO(base, multiplier, index) (base + (multiplier * index))
> >
> > re
Joe Perches writes:
> It might be better to use some base + index macro
> as it could be smaller object code.
>
> Something like:
>
> #define REG_NO(base, multiplier, index) (base + (multiplier * index))
>
> reg_write(vc->dev, REG_NO(0x10, 1, vc->ch), dma_cfg);
> or
>
> #define VDMA_C
On Mon, 2015-06-22 at 07:33 +0200, Krzysztof Hałasa wrote:
> Joe Perches writes:
>
> > How is the macro used?
> > #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
>
> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 +
> 5, a0 + 6, a0 + 7})
[]
> #define VD
Joe Perches writes:
> How is the macro used?
> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
#define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3, a0 + 4, a0 + 5,
a0 + 6, a0 + 7})
#define REG8_2(a0) ((const u16[8]){a0, a0 + 2, a0 + 4, a0 + 6, a0 + 8, a0 +
0xA, a0 + 0
On Fri, 2015-06-19 at 12:52 +0200, Krzysztof Hałasa wrote:
> Frans Klaver writes:
>
> > Ah, right. One might say that this is a false positive, but that's up
> > to Joe or Andy I guess.
> >
> > It may be valid C code, but I think this construction is slightly
> > funky to begin with.
> >
> > Whic
Frans Klaver writes:
> Ah, right. One might say that this is a false positive, but that's up
> to Joe or Andy I guess.
>
> It may be valid C code, but I think this construction is slightly
> funky to begin with.
>
> Which file is this?
A new file, not yet sent anywhere.
--
Krzysztof Halasa
Ind
On Fri, Jun 19, 2015 at 12:31 PM, Krzysztof Hałasa wrote:
> Frans Klaver writes:
>
>>> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
>>>
>>> vs
>>>
>>> #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
>>> ^
>>
>> The prescribed
Frans Klaver writes:
>> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
>>
>> vs
>>
>> #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
>> ^
>
> The prescribed style is to have no space between cast and castee. So,
> the top opti
Hi,
On Fri, Jun 19, 2015 at 10:35 AM, Krzysztof Hałasa wrote:
> Hi,
>
> a simple question: which style is preferred?
>
> #define REG8_1(a0) ((const u16[8]){a0, a0 + 1, a0 + 2, a0 + 3})
>
> vs
>
> #define REG8_1(a0) ((const u16[8]) {a0, a0 + 1, a0 + 2, a0 + 3})
> ^^
Hi Benny :)
* Benny Halevy <[EMAIL PROTECTED]> dixit:
> Using only spaces as DervishD suggested works around that using brute
> force by forcing the user to the author's preference which is
> legitimate but may not be the most productive way.
I admit it.
> I think that my proposal of using
On Mon, Nov 12, 2007 at 10:13:08AM +0200, Benny Halevy wrote:
> checkpatch allows to indent with any number of tabs and up to 7 spaces.
> This is consistent with Documentation/CodingStyle and therefore can be
> considered "correct". However, forcing everybody to the same tab expansion
> setup is t
On Nov. 08, 2007, 17:58 +0200, Chris Snook <[EMAIL PROTECTED]> wrote:
> Benny Halevy wrote:
>> Greetings,
>>
>> I would like to hear peoples opinion about the indentation convention
>> described below that I personally found the most practical with
>> several different editors.
>>
>> The gist of it
On Nov. 11, 2007, 11:23 +0200, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> DervishD wrote:
>> Bonjour Xavier :)
>>
>> * Xavier Bestel <[EMAIL PROTECTED]> dixit:
>>
>>> Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
>>>
* Benny Halevy <[EMAIL PROTECTED]> dixit
DervishD wrote:
Bonjour Xavier :)
* Xavier Bestel <[EMAIL PROTECTED]> dixit:
Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
* Benny Halevy <[EMAIL PROTECTED]> dixit:
I would like to hear peoples opinion about the indentation convention
described below that I
On Nov. 10, 2007, 14:27 +0200, Xavier Bestel <[EMAIL PROTECTED]> wrote:
> Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
>> Hi Benny :)
>>
>> * Benny Halevy <[EMAIL PROTECTED]> dixit:
>>> I would like to hear peoples opinion about the indentation convention
>>> described below that I
Bonjour Xavier :)
* Xavier Bestel <[EMAIL PROTECTED]> dixit:
> Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
> > * Benny Halevy <[EMAIL PROTECTED]> dixit:
> > > I would like to hear peoples opinion about the indentation convention
> > > described below that I personally found
Le samedi 10 novembre 2007 à 13:04 +0100, DervishD a écrit :
> Hi Benny :)
>
> * Benny Halevy <[EMAIL PROTECTED]> dixit:
> > I would like to hear peoples opinion about the indentation convention
> > described below that I personally found the most practical with
> > several different editors.
>
Hi Benny :)
* Benny Halevy <[EMAIL PROTECTED]> dixit:
> I would like to hear peoples opinion about the indentation convention
> described below that I personally found the most practical with
> several different editors.
While I respect you opinion about tabs, I find tab indentation the most
Benny Halevy wrote:
Greetings,
I would like to hear peoples opinion about the indentation convention
described below that I personally found the most practical with
several different editors.
The gist of it is that tabs should be used for nesting, not for decoration.
Indent your code with as ma
On Jul 7 2007 18:49, Jim Cromie wrote:
> forex:
>
> static ssize_t
> store_fan_div (struct device *dev, struct device_attribute *devattr,
> const char *buf, size_t count)
> {...}
>
> IIRC, many like the entire sig on one line, because its grep friendly.
> I personally like the ab
>> static ssize_t
>> store_fan_div (struct device *dev, struct device_attribute *devattr,
>> const char *buf, size_t count)
>> {...}
>>
>>
>> IIRC, many like the entire sig on one line, because its grep friendly.
>> I personally like the above, but grep-ability is hard to argu
On Sat, 07 Jul 2007 18:49:07 -0600 Jim Cromie wrote:
> Linus Torvalds wrote:
> >
> >
> > Yes, code should be less than 80 characters wide.
> >
> > But hey, sometimes it's just more readable to have one line that is
> > slightly longer than it should be, than to split something that is awkward
Linus Torvalds wrote:
For example, if I get a patch for something that is a whole driver, I
generally think that while I *prefer* to see it follow the kernel coding
style, I also expect that the person who sends me the driver is the one
who is going to maintain it in the future, and thus his
t;,
| Jan Engelhardt <[EMAIL PROTECTED]>,
| dave young <[EMAIL PROTECTED]>, Willy Tarreau <[EMAIL PROTECTED]>,
| [EMAIL PROTECTED], [EMAIL PROTECTED]
| Subject: Re: coding style
| Date: Sat, 16 Jun 2007 19:43:12 +0200
|
| [EMAIL PROTECTED] wrote:
| > [Stefan Richte
[EMAIL PROTECTED] wrote:
> [Stefan Richter - Sat, Jun 16, 2007 at 03:07:43PM +0200]
> | Cyrill Gorcunov wrote:
> | > There sould be someting making strict rule over alignment (as it done
> | > for the tabs size).
> |
> | That's impracticable. Alignment, as it serves readability, cannot be
> | cov
On Sat, 16 Jun 2007, Jan Engelhardt wrote:
> >
> >Heh. Actually, Linux maintainers have generally very consciously _avoided_
> >trying to "enforce" coding style issues.
>
> Really? "it's not going to be merged unless you turn all uint32_t into
> u_int32_t" is a paraphrased variant of what I was
[Stefan Richter - Sat, Jun 16, 2007 at 03:07:43PM +0200]
| Cyrill Gorcunov wrote:
| > There sould be someting making strict rule over alignment (as it done
| > for the tabs size).
|
| That's impracticable. Alignment, as it serves readability, cannot be
| covered by a few strict rules.
| --
| Ste
Hey,
On Fri, Jun 15, 2007 at 11:16:08AM +0200, Jan Engelhardt wrote:
> >> so which one is preferred for the kernel?
>
> err = very_long_function_name(lots_of_arguments,
> less,
> less,
> less,
>
Cyrill Gorcunov wrote:
> There sould be someting making strict rule over alignment (as it done
> for the tabs size).
That's impracticable. Alignment, as it serves readability, cannot be
covered by a few strict rules.
--
Stefan Richter
-=-=-=== -==- =
http://arcgraph.de/sr/
-
To unsubscri
Randy Dunlap wrote:
> On Fri, 15 Jun 2007 23:18:04 +0400 Cyrill Gorcunov wrote:
>> Actually it would be perfect to get strict rules also for math. and log.
>> operators being splitted on several lines:
>
> I disagree that CodingStyle should contain such strict rules for
> line continuations.
Peop
Jan Engelhardt wrote:
> On Jun 15 2007 13:39, Linus Torvalds wrote:
>> On Fri, 15 Jun 2007, Jan Engelhardt wrote:
>>> Linux maintainers will enforce \t "being"[1] 8, and will also enforce
>>> the 80-column limit[2].
>> Heh. Actually, Linux maintainers have generally very consciously _avoided_
>> t
Jan Engelhardt wrote:
> On Jun 15 2007 13:21, Linus Torvalds wrote:
>> On Fri, 15 Jun 2007, Cyrill Gorcunov wrote:
>>> |
>>> | from CodingStyle:
>>> | Tabs are 8 characters,
[...]
>> I did indeed write that.
>>
>> Tabs are 8 characters in the kernel coding style.
>
> That clarification ("in t
On Jun 15 2007 13:39, Linus Torvalds wrote:
>On Fri, 15 Jun 2007, Jan Engelhardt wrote:
>>
>> Linux maintainers will enforce \t "being"[1] 8, and will also enforce
>> the 80-column limit[2].
>
>Heh. Actually, Linux maintainers have generally very consciously _avoided_
>trying to "enforce" coding
On Fri, 15 Jun 2007 23:18:04 +0400 Cyrill Gorcunov wrote:
> [Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
> |
> | On Jun 15 2007 11:03, Randy Dunlap wrote:
> | >>
> | >> "use tabs for indents and spaces for alignment"
> | >>
> | >> If that means you need to use two dozen spaces, then
On Fri, 15 Jun 2007, Jan Engelhardt wrote:
>
> Linux maintainers will enforce \t "being"[1] 8, and will also enforce
> the 80-column limit[2].
Heh. Actually, Linux maintainers have generally very consciously _avoided_
trying to "enforce" coding style issues.
We encourage. Sometimes people act
On Jun 15 2007 13:21, Linus Torvalds wrote:
>On Fri, 15 Jun 2007, Cyrill Gorcunov wrote:
>> |
>> |from CodingStyle:
>> |Tabs are 8 characters, and thus indentations are also 8
>> |characters. There are heretic movements that try to make
>> |indentations 4 (or even 2!) characters
On Jun 15 2007 12:45, Kok, Auke wrote:
>>
>> Well tabs should _never_ be assumed to be 8, and in this regard, as I see it,
>> CodingStyle has a bug. Tabs are there so that the user can set their width
>> according to _their_ taste, simply so that both sides,
>>
>> from CodingStyle:
>> Tabs are
On Fri, 15 Jun 2007, Cyrill Gorcunov wrote:
> |
> | from CodingStyle:
> | Tabs are 8 characters, and thus indentations are also 8
> | characters. There are heretic movements that try to make
> | indentations 4 (or even 2!) characters deep, and that is akin
> | to trying to d
On Jun 15 2007 23:41, Cyrill Gorcunov wrote:
>
>Dunno who wrote that part :(. Jan, look:
>
> Now, some people will claim that having 8-character indentations makes
> the code move too far to the right, and makes it hard to read on a
> 80-character terminal screen. The answer to
[Kok, Auke - Fri, Jun 15, 2007 at 12:45:23PM -0700]
| Jan Engelhardt wrote:
| >On Jun 15 2007 12:21, Kok, Auke wrote:
| >>Cyrill Gorcunov wrote:
| >>>[Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
| >>>| On Jun 15 2007 11:03, Randy Dunlap wrote:
| >>>| > >
| >>>| > > "use tabs for indent
Jan Engelhardt wrote:
On Jun 15 2007 12:21, Kok, Auke wrote:
Cyrill Gorcunov wrote:
[Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
| On Jun 15 2007 11:03, Randy Dunlap wrote:
| > >
| > > "use tabs for indents and spaces for alignment"
| > >
| > > If that means you need to use two do
[Jan Engelhardt - Fri, Jun 15, 2007 at 09:31:27PM +0200]
|
| On Jun 15 2007 12:21, Kok, Auke wrote:
| > Cyrill Gorcunov wrote:
| >> [Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
| >> | On Jun 15 2007 11:03, Randy Dunlap wrote:
| >> | > >
| >> | > > "use tabs for indents and spaces for
On Jun 15 2007 12:21, Kok, Auke wrote:
> Cyrill Gorcunov wrote:
>> [Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
>> | On Jun 15 2007 11:03, Randy Dunlap wrote:
>> | > >
>> | > > "use tabs for indents and spaces for alignment"
>> | > >
>> | > > If that means you need to use two dozen s
[Kok, Auke - Fri, Jun 15, 2007 at 12:21:23PM -0700]
| Cyrill Gorcunov wrote:
| >[Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
| >|
| >| On Jun 15 2007 11:03, Randy Dunlap wrote:
| >| >>
| >| >> "use tabs for indents and spaces for alignment"
| >| >>
| >| >> If that means you need to u
Cyrill Gorcunov wrote:
[Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
|
| On Jun 15 2007 11:03, Randy Dunlap wrote:
| >>
| >> "use tabs for indents and spaces for alignment"
| >>
| >> If that means you need to use two dozen spaces, then so be it.
| >
| >I don't think that's what tha
[Jan Engelhardt - Fri, Jun 15, 2007 at 09:10:49PM +0200]
|
| On Jun 15 2007 11:03, Randy Dunlap wrote:
| >>
| >> "use tabs for indents and spaces for alignment"
| >>
| >> If that means you need to use two dozen spaces, then so be it.
| >
| >I don't think that's what that rule means, but I didn't
On Jun 15 2007 11:03, Randy Dunlap wrote:
>>
>> "use tabs for indents and spaces for alignment"
>>
>> If that means you need to use two dozen spaces, then so be it.
>
>I don't think that's what that rule means, but I didn't write it,
>so I'm not absolutely sure about it.
>
>but we know that tab
[Kok, Auke - Fri, Jun 15, 2007 at 11:05:07AM -0700]
| Chris Friesen wrote:
| >Consider two people, one with tabs as 8 characters and one with tabs as
| >4 characters. If person A aligns using a tab plus a space (giving 9
| >characters), then the alignmnet will be all screwed up for person B (who
Chris Friesen wrote:
Consider two people, one with tabs as 8 characters and one with tabs as
4 characters. If person A aligns using a tab plus a space (giving 9
characters), then the alignmnet will be all screwed up for person B (who
will see 5 characters of alignment).
The only rule that wo
On Fri, 15 Jun 2007 11:54:14 -0600 Chris Friesen wrote:
> Cyrill Gorcunov wrote:
>
> > Thanks to all of you for answering. Actually I was concerning about function
> > arguments' alignment (on separated lines) not about indentation. So as I see
> > it's a question of bent ;) And a simple rule exi
Cyrill Gorcunov wrote:
Thanks to all of you for answering. Actually I was concerning about function
arguments' alignment (on separated lines) not about indentation. So as I see
it's a question of bent ;) And a simple rule exist - use tabs for indents
and spaces for alignment (when amount of spac
[Jan Engelhardt - Fri, Jun 15, 2007 at 11:16:08AM +0200]
|
|
| Cyrill wrote:
| >> err = foo(arg_a, arg_b, arg_c,
| >>arg_d);
| 1234
|
| (note: monospace font needed)
|
|
| Dave wrote:
| > The Documentation/CodingStyle says:
| >
| > Outside of comments, docume
On 6/15/07, Bernd Petrovitsch <[EMAIL PROTECTED]> wrote:
Says the one without real name who is full quoting including even the
mailing list footers.
hmm. including footers was a mistake. sigh!
but i really dont understand why the real name is needed unless im
submitting some patches!
"What's
Cyrill wrote:
>> err = foo(arg_a, arg_b, arg_c,
>>arg_d);
1234
(note: monospace font needed)
Dave wrote:
> The Documentation/CodingStyle says:
>
> Outside of comments, documentation and except in Kconfig, spaces are never
> used for indentation, and the above
On Fri, 2007-06-15 at 12:17 +0530, debian developer wrote:
[...]
> And *Please* do not top-post!
Says the one without real name who is full quoting including even the
mailing list footers.
SCNR,
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> the current "checkpatch.pl" script rejects this notion and requires
> that you use tabs whenever you can (you can still align code within
> the length of one tab).
Tool deficiency.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsub
Hi,
2007/6/15, debian developer <[EMAIL PROTECTED]>:
And *Please* do not top-post!
I know gmail directly goes to the top while replying, but think of
other mail clients out there.
Yes, it go to the top directly, and tabs of pasted code will be
converted to white spaces, so I need use mutt to
On 6/15/07, dave young <[EMAIL PROTECTED]> wrote:
Hi,
The Documentation/CodingStyle says:
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken.
Regards
dave
2007/6/15, Kok, Auke <[EMAIL PROTECTED]>:
> Will
Hi,
The Documentation/CodingStyle says:
Outside of comments, documentation and except in Kconfig, spaces are never
used for indentation, and the above example is deliberately broken.
Regards
dave
2007/6/15, Kok, Auke <[EMAIL PROTECTED]>:
Willy Tarreau wrote:
> On Thu, Jun 14, 2007 at 10:48:36P
Willy Tarreau wrote:
On Thu, Jun 14, 2007 at 10:48:36PM +0400, Cyrill Gorcunov wrote:
Hi to all,
a simple question the answer to witch I didn't find in CodingStyle.
Look for a code snip:
err = foo(arg_a, arg_b, arg_c,
arg_d);
the second line contains 'd' arg aligned wi
On Thu, Jun 14, 2007 at 10:48:36PM +0400, Cyrill Gorcunov wrote:
>
> Hi to all,
>
> a simple question the answer to witch I didn't find in CodingStyle.
> Look for a code snip:
>
> err = foo(arg_a, arg_b, arg_c,
> arg_d);
>
> the second line contains 'd' arg aligned with tabs
On 4/6/07, Roland Dreier <[EMAIL PROTECTED]> wrote:
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
that the line with "bar" on it is properly indented with one tab
(since it is part of the if statement that is also indented one tab),
and then four spaces are used
> > So in practical terms "\n \t" and "\n\t" are identical;
> > although the former "should not" be used, it doesn't
> > actually affect what CodingStyle is primarily trying to
> > control (i.e. what the code looks like).
>
> That's not what CodingStyle is trying to control. Not "what the
> code
On 4/6/07, Stefan Richter <[EMAIL PROTECTED]> wrote:
David Brownell wrote:
[...]
>>> 1 if (To control chain reactions, your odds
>>> 2 Improve if you've got cadmium rods) {
>>> 3 In your fission reactor
>>> 4 Their lack is a factor
>>> 5 }
>>> 6 In scre
On Friday 06 April 2007 18:57, David Brownell wrote:
> On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote:
> > David,
> >
> > http://tglx.de/private/tglx/usbnet.png
> >
> > /me recommends emacs-develock.el for colorful white space wreckage
> > display !
>
> Then I'd have to switch to EMACS .
David Brownell <[EMAIL PROTECTED]> writes:
> So in practical terms "\n \t" and "\n\t" are identical;
> although the former "should not" be used, it doesn't
> actually affect what CodingStyle is primarily trying to
> control (i.e. what the code looks like).
That's not what CodingStyle is trying to
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> Tabs should be used for indent, not padding. People wanting to use
> different-sized tabs can change settings in their editor, i.e.
> to make a tab 12 instead of 8. Or 6. Or whatever. If tabs only ever
> appear at the front, this works, it breaks when t
On Apr 6 2007 15:40, David Brownell wrote:
>> >if (...) {
>> >THAT WAS ONE MORE TAB
>> >}
>> >
>> >Come on, stop wasting everyone's time with utter nonsense.
>> I was never debating these two things.
>Actually, you did.
If it was perceived I did, then I owe you an apology.
>
On Friday 06 April 2007 4:21 pm, Thomas Gleixner wrote:
> David,
>
> On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote:
> > This particular issue doesn't actually affect indentation, since the
> > tab trumps that space. So it's a bit off-agenda for this particular
> > flamage.
>
> ROTFL, t
David,
On Fri, 2007-04-06 at 15:57 -0700, David Brownell wrote:
> This particular issue doesn't actually affect indentation, since the
> tab trumps that space. So it's a bit off-agenda for this particular
> flamage.
ROTFL, the tab trumps the space. Is this a card game ?
> > Please change your c
On Friday 06 April 2007 3:17 pm, Thomas Gleixner wrote:
> David,
>
> http://tglx.de/private/tglx/usbnet.png
>
> /me recommends emacs-develock.el for colorful white space wreckage
> display !
Then I'd have to switch to EMACS ... no thanks! ;)
At the risk of switching to a VI/EMACS flamewar (cou
On Friday 06 April 2007 3:07 pm, Jan Engelhardt wrote:
>
> On Apr 6 2007 15:05, David Brownell wrote:
> >
> >> but... egads! Linus
> >> put spaces before the &&s to line them up nicely!
> >>
> >> "more in the breach" and all that I guess...
> >
> >Yeah, nobody likes style nazis. On the other h
On Friday 06 April 2007 3:04 pm, Jan Engelhardt wrote:
> > if (...) {
> > THAT WAS ONE MORE TAB
> > }
> >
> >and
> >
> > for (...) {
> > THAT WAS ALSO ONE MORE TAB
> > }
> >
> >Come on, stop wasting everyone's time with utter nonsense.
>
> I was never debat
David,
On Fri, 2007-04-06 at 14:05 -0700, David Brownell wrote:
> Please change your coding style to conform to Documentation/CodingStyle.
>
> *** Only indent with tabs!! ***
>
> Every one of those examples violates that simple rule.
>
> Why does *anyone* have even the slighte
On Apr 6 2007 15:05, David Brownell wrote:
>
>> but... egads! Linus
>> put spaces before the &&s to line them up nicely!
>>
>> "more in the breach" and all that I guess...
>
>Yeah, nobody likes style nazis. On the other hand, it's rather
>unusual to be the target of style nazism for actually f
Hello David,
On Apr 6 2007 13:57, David Brownell wrote:
>> though I do not speak for
>> them, seem to do it much the way I described, judging from the code they
>> wrote/write.
>
>Your eyes are broken then ...
Sorry? I could have simply told you to look into kernel/signal.c LINE
220 (that's in
On Friday 06 April 2007 2:38 pm, Roland Dreier wrote:
> [I can't believe I'm stepping into an indentation flamewar, but here goes...]
At least you weren't the target of attacks there ... for daring to
actually follow the only published Linux style guide in that area!!
> > Please change your cod
On Friday 06 April 2007 2:37 pm, Jeremy Fitzhardinge wrote:
> David Brownell wrote:
> > Please change your coding style to conform to Documentation/CodingStyle.
> >
> > *** Only indent with tabs!! ***
> >
> > Every one of those examples violates that simple rule.
> >
>
> Spaces
On Apr 6 2007 14:05, David Brownell wrote:
>
>Please change your coding style to conform to Documentation/CodingStyle.
>
> *** Only indent with tabs!! ***
>
>Every one of those examples violates that simple rule.
>
>Why does *anyone* have even the slightest difficulty understandi
On Fri, 2007-04-06 at 14:38 -0700, Roland Dreier wrote:
[snip]
> If you have a git tree handy, you can do "git show 68380b58" and see
> that Linus himself wrote:
>
> if (get_wq_data(work) == cwq
> && work_pending(work)
> && !list_empty(&work->entry)) {
>
> I have to admi
David Brownell wrote:
> On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
>
>> I usually indent this way if expressions exceed the 80 columns limit:
Or in other words:
- When a new scope is opened, increase indentations by 8 characters.
Use a tab for that.
- When wrapping within an
David Brownell wrote:
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
I usually indent this way if expressions exceed the 80 columns limit:
if (foo___ &&
bar___) {
doit;
}
and
if ((one___ ||
one_an
[I can't believe I'm stepping into an indentation flamewar, but here goes...]
> Please change your coding style to conform to Documentation/CodingStyle.
>
> *** Only indent with tabs!! ***
>
> Every one of those examples violates that simple rule.
Yes, Documentation/Coding
David Brownell wrote:
> Please change your coding style to conform to Documentation/CodingStyle.
>
> *** Only indent with tabs!! ***
>
> Every one of those examples violates that simple rule.
>
Spaces are used to indent all over the kernel; using a few spaces to pad
out some i
On Friday 06 April 2007 12:16 pm, Jan Engelhardt wrote:
> >> and that the inner block code
> >> (lines 3 and 4) should have more indent than line 2.
> >
> >We disagree. The "inner" block should in all cases have one-tab indent.
>
> You disagree. "We", as in, the kernel coders,
... agree with wh
On Friday 06 April 2007 12:03 pm, Stefan Richter wrote:
>
> I usually indent this way if expressions exceed the 80 columns limit:
>
> if (foo___ &&
> bar___) {
> doit;
> }
> and
> if ((one___ ||
>one_and_a_half) &&
>
On Apr 6 2007 10:29, David Brownell wrote:
>> Using
>> /^\t+\x20{2,8}/ on continuation line(s) is perfect because it does
>> not cause either the continuation line(s) or the inner block code to
>> move too much to the right.
>
>No, that's a clear violation of CodingStyle on two separate points:
>
David Brownell wrote:
[...]
>>> 1 if (To control chain reactions, your odds
>>> 2 Improve if you've got cadmium rods) {
>>> 3 In your fission reactor
>>> 4 Their lack is a factor
>>> 5 }
>>> 6 In screams of "A meltdown! Ye gods!"
>>>
>>> Now, the former m
On Tue, 13 Feb 2007 09:37:38 +0200 Muli Ben-Yehuda wrote:
> On Mon, Feb 12, 2007 at 03:47:50PM -0800, Joe Perches wrote:
>
> > Now that most of the sizeof(array)/sizeof(array[0]) conversions have
> > been done (there are about 800 done and about another 130 left),
> > perhaps it could be useful t
On Tue, 2007-02-13 at 21:54 +1100, Nick Piggin wrote:
> Bernd Petrovitsch wrote:
> > On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote:
> >
> >>Joe Perches wrote:
> >
> > [...]
> >
> >>>perhaps:
> >>>
> >>>#define array_for_each(element, array) \
> >>> for ((element) = (array); \
> >>>
Bernd Petrovitsch wrote:
On Tue, 2007-02-13 at 18:42 +1100, Nick Piggin wrote:
Joe Perches wrote:
[...]
perhaps:
#define array_for_each(element, array) \
for ((element) = (array); \
(element) < ((array) + ARRAY_SIZE((array))); \
(element)++)
If you're go
1 - 100 of 130 matches
Mail list logo
