lkml.org 
[lkml]   [2006]   [Jul]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] drivers: Conversions from kmalloc+memset to k(z|c)alloc.
    On Sun, 23 Jul 2006, Michael Buesch wrote:
    [..]
    > Yeah, please stop it.
    > Did you actually _look_ at what indent does to code sometimes?
    > It sometimes (often?) renders perfectly readable code into a
    > huge blob of crap.

    Do you remember file names ?
    I'm just review diff after using indent with Lindent args and only in few
    places I saw something badly looking:
    - badly formated __asm__ () content
    - in case some functions with very long function names worser looling
    function header,
    - struct with filled field using multicolumt (why not use single col ?)

    IMO curent issue isn't "indent produces (generaly) bad output" but "in
    some very limited (compare to all amout of code) cases it produces
    something looking bad".
    In all other/most of cases (probably ~99%) Lindetd can be used
    .. but for NOW GENERALY IT IS NOT NOT USED.

    > Face reality. The linux kernel is following the general codingstyle
    > very well already. I don't think there is need to improve the current
    > codebase for non-existent codingstyle issues. And we already review
    > new code for codingstyle issues, so the codebase remains clean.

    Sorry but it is not true. There is no single coding style. Now in probably
    compareble amout of points is used constructions like:

    1) top of the function:

    static inline void *
    find_pa(unsigned long *vptb, void *ptr)

    or

    static inline void *find_pa(unsigned long *vptb, void *ptr)

    (Lindent produces second variant)

    2) type conversion:

    return (void *) result;
    or
    return (void*)result;
    or
    return (void *)result;

    (Lindent produces last)

    3) using tab or not (Lindent produces code with tabs)

    4) sometimes functions argumeta are formated in sigle colum but sometimes
    not:

    printk("%s Module Type: 0x%x - Unit ID 0x%x - "
    "Condition 0x%x\n",
    err_print_prefix,
    env->module_type,
    env->unit_id,
    env->condition);
    or
    printk("%s Module Type: 0x%x - Unit ID 0x%x - "
    "Condition 0x%x\n",
    env->module_type, env->unit_id, env->condition);

    5) remove trailing spaces or not (indent removes trailing spaces)

    and probably much, much more small details like this.

    > Look at other projects with horrible codingstyle problems
    > and suggest solutions to their _real_ issues. *cough*kde*cough*

    Sorry but in this case it is simple chicken and egg problem. First you
    must define "coding style" details and after this you
    can start work on tool for indenting all source code.

    Now I know why Linux code NEVER was autoformated using some tool. Cause is
    VERY simple: because THERE IS NO complet coding style definition for
    Linux tree.

    Current Documentation/CodingStyle contains only *very* limited neccessary
    for finish this details.
    There is not general rule like "if it produces correctly looking output
    use Lindet" so current Linux coding style is "free style" .. nothing more.

    Add general advice "try use Lindent" will allow start discuss on some
    never defined coding style details. Probaly it will als show some bad
    coded fregmets (for exxample when somen uses very long identifiers for
    variables or function names and it will badly look on 80 colums).
    Withouty this any time when "coding style" will back it can produce next
    flame theread.

    kloczek
    PS. In case coding style Linus is right "Documentations/specyfications is
    close to useless" because usability of Documentation/CodingStyle is realy
    cloase to useless but .. in *this* case ducumetation isn't guilty.
    --
    -----------------------------------------------------------
    *Ludzie nie mają problemów, tylko sobie sami je stwarzają*
    -----------------------------------------------------------
    Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek@rudy.mif.pg.gda.pl*
    \
     
     \ /
      Last update: 2006-07-24 02:15    [W:2.872 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site