05 Nov, 2011

1 commit

  • After commit 38829dc9d7b4 ("Documentation/CodingStyle: flesh out if-else
    examples") highlight that if _only_one_ branch of a conditional
    statement is a single statement, then braces are to be used on both
    branches.

    Signed-off-by: Antonio Ospite
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Antonio Ospite
     

07 Aug, 2011

1 commit


07 Jul, 2011

1 commit


23 Mar, 2011

1 commit

  • There is a missing case for "Chapter 3: Placing Braces and Spaces". We
    often know we should not use braces where a single statement. The first
    case is:

    if (condition)
    action();

    Another case is:

    if (condition)
    do_this();
    else
    do_that();

    However, I can not find a description of the second case.

    Signed-off-by: Harry Wei
    Cc: Randy Dunlap
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Harry Wei
     

17 Mar, 2011

1 commit


13 Jun, 2009

1 commit


30 Jan, 2009

2 commits

  • I don't think emacs understands tilde expansion, so use
    "expand-file-name" to do that.

    Signed-off-by: Dan Carpenter
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Dan Carpenter
     
  • With the previous Emacs tips example the kernel style was made available
    for files in the kernel-tree only. This patch updates the tip to add a
    separate cc-mode indent style ("linux-tabs-only"). This makes it easy to
    switch between different indent styles and also makes the kernel style
    easily available for any filetype mode (c++, awk, ...) that is managed
    by the Emacs cc-mode.

    Signed-off-by: Teemu Likonen
    Signed-off-by: Randy Dunlap
    Signed-off-by: Linus Torvalds

    Teemu Likonen
     

26 Jul, 2008

1 commit


17 Oct, 2007

1 commit

  • I would suggest this change to make CodingStyle properly reflect the style
    used by the kernel, rather than the current wording which is wishful
    thinking and misleading, and comes from the same school of thought that
    gets off on prescriptive grammar, latin and comp.std.c

    Signed-off-by: Alan Cox
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Cox
     

19 Jul, 2007

1 commit

  • Update CodingStyle to talk about "-DDEBUG" message conventions and the
    new "-DVERBOSE_DEBUG" convention.

    Signed-off-by: David Brownell
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    David Brownell
     

17 Jul, 2007

2 commits


24 May, 2007

1 commit


09 May, 2007

2 commits


23 Dec, 2006

1 commit


11 Dec, 2006

1 commit

  • Add some kernel coding style comments, mostly pulled from emails
    by Andrew Morton, Jesper Juhl, and Randy Dunlap.

    - add paragraph on switch/case indentation (with fixes)
    - add paragraph on multiple-assignments
    - add more on Braces
    - add section on Spaces; add typeof, alignof, & __attribute__ with sizeof;
    add more on postfix/prefix increment/decrement operators
    - add paragraph on function breaks in source files; add info on
    function prototype parameter names
    - add paragraph on EXPORT_SYMBOL placement
    - add section on /*-comment style, long-comment style, and data
    declarations and comments
    - correct some chapter number references that were missed when
    chapters were renumbered

    Signed-off-by: Randy Dunlap
    Acked-by: Jesper Juhl
    Acked-by: Jan Engelhardt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

30 Sep, 2006

1 commit

  • This patch (as776) adds a new chapter to Documentation/CodingStyle,
    explaining the circumstances under which a function should return 0 for
    failure and non-zero for success as opposed to a negative error code for
    failure and 0 for success.

    Signed-off-by: Alan Stern
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alan Stern
     

23 Jun, 2006

1 commit


11 Jan, 2006

1 commit


09 Jan, 2006

2 commits


18 Sep, 2005

1 commit


11 Sep, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds