[PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

On Sat, 17 Dec 2011 18:57:33 -0500, Austin Clements  wrote:

> Not knowing anything about uncrustify, would it be possible to set up
> a pre-commit hook that at least rejects newly added code that doesn't
> fit the style?

I think that would be possible. It might take a little slightly fancy
scripting since uncrustify just outputs the indented file.  Moved
code might yield false positives, and we'd probably need to find tune
the config a bit for this to be usable.

d

[PATCH] uncrustify.cfg: initial support for notmuch coding style

[Austin Clements]

Quoth David Bremner on Dec 17 at  6:50 pm:
> On Sat, 17 Dec 2011 11:28:15 -0400, David Bremner  
> wrote:
> > +#
> > +# sample usage:
> > +#uncrustify --replace -c uncrustify.cfg foo.c
> 
> There are several different possible workflows, here is what I have
> found convenient.  To simplify the example, suppose we have a single
> patch, and no uncommitted changes.

Not knowing anything about uncrustify, would it be possible to set up
a pre-commit hook that at least rejects newly added code that doesn't
fit the style?

[PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

On Sat, 17 Dec 2011 11:28:15 -0400, David Bremner  wrote:
> +#
> +# sample usage:
> +#uncrustify --replace -c uncrustify.cfg foo.c

There are several different possible workflows, here is what I have
found convenient.  To simplify the example, suppose we have a single
patch, and no uncommitted changes.

I like to do this one file at a time; I'm not sure there is really any
good reason.

1) $ uncrustify --replace -c uncrustify.cfg a.c

2) Now carefully look at the changes and selectively add the ones you
   agree with. I use magit (in emacs) for this. Git citool can also
   stage a line at a time.

3) $ git commit --amend

4) $ git reset --hard # blow away any changes you didn't agree with.
   # remember, no uncommited changes to start with 

Now repeat for each other c/c++/.h file your patch modifies.

In principle you could do something similar to produce "Style cleanups
for file a.c" commits by doing a regular commit in step 3.

d

[PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

From: David Bremner 

Uncrustify is a free (as in GPL2+) tool that indents and beautifies
C/C++ code. It is similar to GNU indent in functionality although
probably more configurable (in fairness, indent has better
documentation).  Uncrustify does not have the indent mis-feature of
needing to have every typedef'ed type defined in the
configuration (even standard types like size_t).

In an ideal situation, running uncrustify on notmuch code would be
NOP; currently this is not true for all files because 1) the
configuration is not perfect 2) the coding style of notmuch is not
completely consistent; in particular the treatment of braces after
e.g. for (_) is not consistent.
---
 uncrustify.cfg |   98 
 1 files changed, 98 insertions(+), 0 deletions(-)
 create mode 100644 uncrustify.cfg

diff --git a/uncrustify.cfg b/uncrustify.cfg
new file mode 100644
index 000..7eab7c4
--- /dev/null
+++ b/uncrustify.cfg
@@ -0,0 +1,98 @@
+#
+# uncrustify config file for the linux kernel
+#
+# $Id: linux-indent.cfg 488 2006-09-09 12:44:38Z bengardner $
+# Taken from the uncrustify distribution under license (GPL2+)
+#
+# sample usage:
+#uncrustify --replace -c uncrustify.cfg foo.c
+#
+#
+
+indent_with_tabs   = 2 # 1=indent to level only, 2=indent with 
tabs
+align_with_tabs= TRUE  # use tabs to align
+align_on_tabstop   = TRUE  # align on tabstops
+input_tab_size = 8 # original tab size
+output_tab_size= 8 # new tab size
+indent_columns = 4
+
+indent_label   = 2 # pos: absolute col, neg: relative 
column
+
+
+#
+# inter-symbol newlines
+#
+
+nl_enum_brace  = remove# "enum {" vs "enum \n {"
+nl_union_brace = remove# "union {" vs "union \n {"
+nl_struct_brace= remove# "struct {" vs "struct \n {"
+nl_do_brace = remove   # "do {" vs "do \n {"
+nl_if_brace = remove   # "if () {" vs "if () \n {"
+nl_for_brace= remove   # "for () {" vs "for () \n {"
+nl_else_brace   = remove   # "else {" vs "else \n {"
+nl_while_brace  = remove   # "while () {" vs "while () \n {"
+nl_switch_brace = remove   # "switch () {" vs "switch () \n {"
+nl_brace_while = remove# "} while" vs "} \n while" - cuddle 
while
+nl_brace_else  = remove# "} else" vs "} \n else" - cuddle else
+nl_func_var_def_blk= 1
+nl_fcall_brace = remove# "list_for_each() {" vs 
"list_for_each()\n{"
+nl_fdef_brace  = force # "int foo() {" vs "int foo()\n{"
+# nl_after_return  = TRUE;
+# nl_before_case   = 1
+
+# Add or remove newline between return type and function name in definition
+nl_func_type_name  = force
+
+#
+# Source code modifications
+#
+
+# mod_paren_on_return  = remove# "return 1;" vs "return (1);"
+# mod_full_brace_if= remove# "if (a) a--;" vs "if (a) { a--; }"
+# mod_full_brace_for   = remove# "for () a--;" vs "for () { a--; }"
+# mod_full_brace_do= remove# "do a--; while ();" vs "do { a--; } 
while ();"
+# mod_full_brace_while = remove# "while (a) a--;" vs "while (a) { a--; 
}"
+
+
+#
+# inter-character spacing options
+#
+
+# sp _return_paren = force # "return (1);" vs "return(1);"
+sp_sizeof_paren= remove# "sizeof (int)" vs 
"sizeof(int)"
+sp_before_sparen   = force # "if (" vs "if("
+sp_after_sparen= force # "if () {" vs "if (){"
+sp_sparen_brace= force
+sp_after_cast  = force # "(int) a" vs "(int)a"
+sp_inside_braces   = add   # "{ 1 }" vs "{1}"
+sp_inside_braces_struct= add   # "{ 1 }" vs "{1}"
+sp_inside_braces_enum  = add   # "{ 1 }" vs "{1}"
+sp_assign  = force
+sp_arith   = force
+sp_bool= add
+sp_compare = add
+sp_assign  = add
+sp_after_comma = add
+sp_func_def_paren  = force # "int foo (){" vs "int foo(){"
+sp_func_call_paren = force # "foo (" vs "foo("
+sp_func_proto_paren= force # "int foo ();" vs "int foo();"
+
+#
+# Aligning stuff
+#
+
+align_enum_equ_span= 4 # '=' in enum definition
+# align_nl_cont= TRUE
+# align_var_def_span   = 2
+# align_var_def_inline = TRUE
+# align_var_def_star   = FALSE
+# align_var_def_colon  = TRUE
+# align_assign_span= 1
+align_struct_init_span = 3 # align stuff in a structure init '= { 
}'
+align_right_cmt_span   = 3
+# align_pp_define_span = 8;
+# align_pp_define_gap  = 4;
+
+# cmt_star_cont= FALSE
+
+# indent_brace = 0
-- 
1.7.7.3

[PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

From: David Bremner brem...@debian.org

Uncrustify is a free (as in GPL2+) tool that indents and beautifies
C/C++ code. It is similar to GNU indent in functionality although
probably more configurable (in fairness, indent has better
documentation).  Uncrustify does not have the indent mis-feature of
needing to have every typedef'ed type defined in the
configuration (even standard types like size_t).

In an ideal situation, running uncrustify on notmuch code would be
NOP; currently this is not true for all files because 1) the
configuration is not perfect 2) the coding style of notmuch is not
completely consistent; in particular the treatment of braces after
e.g. for (_) is not consistent.
---
 uncrustify.cfg |   98 
 1 files changed, 98 insertions(+), 0 deletions(-)
 create mode 100644 uncrustify.cfg

diff --git a/uncrustify.cfg b/uncrustify.cfg
new file mode 100644
index 000..7eab7c4
--- /dev/null
+++ b/uncrustify.cfg
@@ -0,0 +1,98 @@
+#
+# uncrustify config file for the linux kernel
+#
+# $Id: linux-indent.cfg 488 2006-09-09 12:44:38Z bengardner $
+# Taken from the uncrustify distribution under license (GPL2+)
+#
+# sample usage:
+#uncrustify --replace -c uncrustify.cfg foo.c
+#
+#
+
+indent_with_tabs   = 2 # 1=indent to level only, 2=indent with 
tabs
+align_with_tabs= TRUE  # use tabs to align
+align_on_tabstop   = TRUE  # align on tabstops
+input_tab_size = 8 # original tab size
+output_tab_size= 8 # new tab size
+indent_columns = 4
+
+indent_label   = 2 # pos: absolute col, neg: relative 
column
+
+
+#
+# inter-symbol newlines
+#
+
+nl_enum_brace  = remove# enum { vs enum \n {
+nl_union_brace = remove# union { vs union \n {
+nl_struct_brace= remove# struct { vs struct \n {
+nl_do_brace = remove   # do { vs do \n {
+nl_if_brace = remove   # if () { vs if () \n {
+nl_for_brace= remove   # for () { vs for () \n {
+nl_else_brace   = remove   # else { vs else \n {
+nl_while_brace  = remove   # while () { vs while () \n {
+nl_switch_brace = remove   # switch () { vs switch () \n {
+nl_brace_while = remove# } while vs } \n while - cuddle 
while
+nl_brace_else  = remove# } else vs } \n else - cuddle else
+nl_func_var_def_blk= 1
+nl_fcall_brace = remove# list_for_each() { vs 
list_for_each()\n{
+nl_fdef_brace  = force # int foo() { vs int foo()\n{
+# nl_after_return  = TRUE;
+# nl_before_case   = 1
+
+# Add or remove newline between return type and function name in definition
+nl_func_type_name  = force
+
+#
+# Source code modifications
+#
+
+# mod_paren_on_return  = remove# return 1; vs return (1);
+# mod_full_brace_if= remove# if (a) a--; vs if (a) { a--; }
+# mod_full_brace_for   = remove# for () a--; vs for () { a--; }
+# mod_full_brace_do= remove# do a--; while (); vs do { a--; } 
while ();
+# mod_full_brace_while = remove# while (a) a--; vs while (a) { a--; 
}
+
+
+#
+# inter-character spacing options
+#
+
+# sp _return_paren = force # return (1); vs return(1);
+sp_sizeof_paren= remove# sizeof (int) vs 
sizeof(int)
+sp_before_sparen   = force # if ( vs if(
+sp_after_sparen= force # if () { vs if (){
+sp_sparen_brace= force
+sp_after_cast  = force # (int) a vs (int)a
+sp_inside_braces   = add   # { 1 } vs {1}
+sp_inside_braces_struct= add   # { 1 } vs {1}
+sp_inside_braces_enum  = add   # { 1 } vs {1}
+sp_assign  = force
+sp_arith   = force
+sp_bool= add
+sp_compare = add
+sp_assign  = add
+sp_after_comma = add
+sp_func_def_paren  = force # int foo (){ vs int foo(){
+sp_func_call_paren = force # foo ( vs foo(
+sp_func_proto_paren= force # int foo (); vs int foo();
+
+#
+# Aligning stuff
+#
+
+align_enum_equ_span= 4 # '=' in enum definition
+# align_nl_cont= TRUE
+# align_var_def_span   = 2
+# align_var_def_inline = TRUE
+# align_var_def_star   = FALSE
+# align_var_def_colon  = TRUE
+# align_assign_span= 1
+align_struct_init_span = 3 # align stuff in a structure init '= { 
}'
+align_right_cmt_span   = 3
+# align_pp_define_span = 8;
+# align_pp_define_gap  = 4;
+
+# cmt_star_cont= FALSE
+
+# indent_brace = 0
-- 
1.7.7.3

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

On Sat, 17 Dec 2011 11:28:15 -0400, David Bremner da...@tethera.net wrote:
 +#
 +# sample usage:
 +#uncrustify --replace -c uncrustify.cfg foo.c

There are several different possible workflows, here is what I have
found convenient.  To simplify the example, suppose we have a single
patch, and no uncommitted changes.

I like to do this one file at a time; I'm not sure there is really any
good reason.

1) $ uncrustify --replace -c uncrustify.cfg a.c

2) Now carefully look at the changes and selectively add the ones you
   agree with. I use magit (in emacs) for this. Git citool can also
   stage a line at a time.

3) $ git commit --amend

4) $ git reset --hard # blow away any changes you didn't agree with.
   # remember, no uncommited changes to start with 
   
Now repeat for each other c/c++/.h file your patch modifies.

In principle you could do something similar to produce Style cleanups
for file a.c commits by doing a regular commit in step 3.

d


___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] uncrustify.cfg: initial support for notmuch coding style

[Austin Clements]

Quoth David Bremner on Dec 17 at  6:50 pm:
 On Sat, 17 Dec 2011 11:28:15 -0400, David Bremner da...@tethera.net wrote:
  +#
  +# sample usage:
  +#uncrustify --replace -c uncrustify.cfg foo.c
 
 There are several different possible workflows, here is what I have
 found convenient.  To simplify the example, suppose we have a single
 patch, and no uncommitted changes.

Not knowing anything about uncrustify, would it be possible to set up
a pre-commit hook that at least rejects newly added code that doesn't
fit the style?
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH] uncrustify.cfg: initial support for notmuch coding style

[David Bremner]

On Sat, 17 Dec 2011 18:57:33 -0500, Austin Clements amdra...@mit.edu wrote:

 Not knowing anything about uncrustify, would it be possible to set up
 a pre-commit hook that at least rejects newly added code that doesn't
 fit the style?

I think that would be possible. It might take a little slightly fancy
scripting since uncrustify just outputs the indented file.  Moved
code might yield false positives, and we'd probably need to find tune
the config a bit for this to be usable.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch