[PATCH 0/148] include/asm-x86: checkpatch cleanups - formatting only - Kernel

This is a discussion on [PATCH 0/148] include/asm-x86: checkpatch cleanups - formatting only - Kernel ; From: Jrn Engel Date: Wed, 26 Mar 2008 12:41:42 +0100 > Do you have a non-consistency based reason to prefer the longer > version? Inconstent spacing fools people's eyes and leads to bugs, more often than not. After 15 years ...

+ Reply to Thread
Page 10 of 10 FirstFirst ... 8 9 10
Results 181 to 190 of 190

Thread: [PATCH 0/148] include/asm-x86: checkpatch cleanups - formatting only

  1. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    From: Jrn Engel
    Date: Wed, 26 Mar 2008 12:41:42 +0100

    > Do you have a non-consistency based reason to prefer the longer
    > version?


    Inconstent spacing fools people's eyes and leads to bugs,
    more often than not.

    After 15 years of kernel development, I can remember at
    least 10 or so multi-week-debugging sessions that could
    have been curtailed had I not mis-read a poorly spaced
    C statement.

    It matters in practical terms, not just consistency terms,
    trust me.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    On Wed, 26 March 2008 04:48:02 -0700, David Miller wrote:
    >
    > > Do you have a non-consistency based reason to prefer the longer
    > > version?

    >
    > Inconstent spacing fools people's eyes and leads to bugs,
    > more often than not.
    >
    > After 15 years of kernel development, I can remember at
    > least 10 or so multi-week-debugging sessions that could
    > have been curtailed had I not mis-read a poorly spaced
    > C statement.
    >
    > It matters in practical terms, not just consistency terms,
    > trust me.


    Sure, I buy that. What I'm arguing here is why we have to be
    consistently long instead of consistently short. CodingStyle seems to
    be silent on the question. And a quick grep shows that while being in
    the minority, I seem to be in a sizeable minority:
    joern@Dublin:/usr/src/kernel/logfs$ sgrep ' \*)' .|wc
    51687 346050 4213259
    joern@Dublin:/usr/src/kernel/logfs$ sgrep '[^ ]\*)' .|wc
    5838 33165 472462

    What is the reason why (void *)foo is better than (void*)foo? Just that
    fact that by random chance one them them became more common in our
    codebase and the minority always has to give in?

    Jörn

    --
    A victorious army first wins and then seeks battle.
    -- Sun Tzu
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    From: Jrn Engel
    Date: Wed, 26 Mar 2008 12:58:53 +0100

    > Sure, I buy that. What I'm arguing here is why we have to be
    > consistently long instead of consistently short. CodingStyle seems to
    > be silent on the question.


    Becauseitmoreeasilyallowsyoureyestoseethedifferent operators.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    On Wed, Mar 26, 2008 at 11:58 AM, Jrn Engel wrote:

    > What is the reason why (void *)foo is better than (void*)foo? Just that
    > fact that by random chance one them them became more common in our
    > codebase and the minority always has to give in?


    It doesn't matter. This is the crux of all interminable coding style
    discussions. There is no objectively best coding style. Pick one,
    stick to it. That's all that matters.

    Linux happens to have a particular coding style, GNU has another. When
    I hack Linux code I use one style, when I hack GNU coee I use another.
    Arguing about it is a waste of time.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    On Wed, 26 March 2008 05:01:16 -0700, David Miller wrote:
    >
    > > Sure, I buy that. What I'm arguing here is why we have to be
    > > consistently long instead of consistently short. CodingStyle seems to
    > > be silent on the question.

    >
    > Becauseitmoreeasilyallowsyoureyestoseethedifferent operators.


    How many different operators are there in a cast?

    But you seem to be arguing the i=0 case. Took me a while to notice
    that. Fair enough.

    Jörn

    --
    Maintenance in other professions and of other articles is concerned with
    the return of the item to its original state; in Software, maintenance
    is concerned with moving an item away from its original state.
    -- Les Belady
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: [patch] bkl2mtd: cleanup

    On Wed, 2008-03-26 at 12:10 +0100, Ingo Molnar wrote:
    > not a "simple one-line function prototype" anymore,
    > so i use the same template for everything:
    >
    > type
    > function_name(vars ...
    > more vars ...)
    > {


    It seems the most common linux style keeps type and function
    on the same line where possible and arguments on subsequent
    lines when necessary.

    type function_name(args...)

    type function_name(args_to_col80,
    more_args...)

    Perhaps that should be your default template.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. style of function definitions (Re: [patch] bkl2mtd: cleanup)

    Ingo Molnar @ Wed, 26 Mar 2008 12:10:21 +0100
    >
    > * Al Viro wrote:
    >

    []
    >> > -static int block2mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
    >> > +static int
    >> > +block2mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
    >> > size_t *retlen, const u_char *buf)

    >>
    >> Again, why split it that way?

    >
    > these are really nuances, so unless you are interested in such nuances
    > nowhere found in CodingStyle, stop reading here :-)


    Nuances, or not, there are all kinds of stuff in Linux. Very small
    journey from simple `grep` and trivial multi-line `sed` to a huge
    discovery can be found here:

    http://kernelnewbies.org/olecom#Function_definitions

    No matter what coding style is, the winner is "linux-2.6/fs/xfs", and
    i doubt anyone can fix that

    Maybe meta-patching by `sed` scripts in `git`? Just kidding.
    --
    -o--=O`C
    #oo'L O
    <___=E M
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: style of function definitions (Re: [patch] bkl2mtd: cleanup)


    On Sunday 2008-03-30 06:29, Oleg Verych wrote:
    > []
    >>>> -static int block2mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
    >>>> +static int
    >>>> +block2mtd_write(struct mtd_info *mtd, loff_t to, size_t len,
    >>>> size_t *retlen, const u_char *buf)
    >>>
    >>> Again, why split it that way?

    >>
    >> these are really nuances, so unless you are interested in such nuances
    >> nowhere found in CodingStyle, stop reading here :-)

    >
    > Nuances, or not, there are all kinds of stuff in Linux. Very small
    > journey from simple `grep` and trivial multi-line `sed` to a huge
    > discovery can be found here:
    >
    > http://kernelnewbies.org/olecom#Function_definitions
    >
    > No matter what coding style is, the winner is "linux-2.6/fs/xfs", and
    > i doubt anyone can fix that


    They at least have an excuse of having a historical unix background
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: style of function definitions (Re: [patch] bkl2mtd: cleanup)

    Jan Engelhardt @ Sun, Mar 30, 2008 at 6:31 AM:

    > > No matter what coding style is, the winner is "linux-2.6/fs/xfs", and
    > > i doubt anyone can fix that

    >
    > They at least have an excuse of having a historical unix background


    i.e. zoo of proprietary versions, expensive, without reliable implementation
    of basic tools and compilers, etc.

    Historical UNIX(R) isn't that good at all. Now it's POSIX(R) forcing all
    new development back.

    http://kernelnewbies.org/olecom#trailing_comments_crap
    http://kernelnewbies.org/olecom#trai..._comments_crap

    Q: why every parameter is on new line?
    A: thus we have more actual code line count

    Q: why trailing comments on every parameter?
    A: our C compiler have (had) 8 characters limit for variable names

    Q: don't you think streaming editor can handle that?
    A: our tools have not such thing

    Q: you have multi-line trailing comments there, don't you know
    it complicates line-oriented grep-like text processing?
    why don't you write freely in comment block before function definition?
    A: why do you care?

    --
    -o--=O`C
    #oo'L O
    <___=E M
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 109/148] include/asm-x86/serial.h: checkpatch cleanups - formatting only

    Hi,

    [Some CCs dropped. I don't think they're truly interested.]

    On 3/26/08, Jörn Engel wrote:
    > What is the reason why (void *)foo is better than (void*)foo? Just that
    > fact that by random chance one them them became more common in our
    > codebase and the minority always has to give in?


    I think the rationale for using (void *) over (void*) is that we
    usually write a space before the * in other places (again, it's about
    consistency). Or do you also write void*a; in variable declarations?


    Vegard

+ Reply to Thread
Page 10 of 10 FirstFirst ... 8 9 10