Difference between revisions of "VPP/CodeStyleConventions"

From fd.io
< VPP
Jump to: navigation, search
(Make)
 
(2 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
== DO I NEED TO APPLY STYLE ? ==
 
== DO I NEED TO APPLY STYLE ? ==
  
* If you don't see this at the end of your [.ch] file:
+
* If you '''don't''' see this at the end of your [.ch] file:
 
  /*
 
  /*
 
  * fd.io coding-style-patch-verification: ON
 
  * fd.io coding-style-patch-verification: ON
Line 14: Line 14:
 
  */
 
  */
  
you need to apply style.
+
you '''need''' to apply style.
  
 
== EMACS ==
 
== EMACS ==
Line 70: Line 70:
  
 
Make changes and run indent again. (in the above case indent took care of it for us, and backup file is sr.c~)
 
Make changes and run indent again. (in the above case indent took care of it for us, and backup file is sr.c~)
 +
 +
== Make ==
 +
 +
a couple of build targets make the process easy. At any time during the development process:
 +
  make checkstyle
 +
to see which files have style errors. And;
 +
  make fixstyle
 +
to fix them.
 +
 +
Be sure to fix any style errors before review as 'make checkstyle' is part of the verify job.

Latest revision as of 12:48, 6 June 2017

Introduction

  • Link to mailer describing it.

DO I NEED TO APPLY STYLE ?

  • If you don't see this at the end of your [.ch] file:
/*
* fd.io coding-style-patch-verification: ON
*
* Local Variables:
* eval: (c-set-style "gnu")
* End:
*/

you need to apply style.

EMACS

  • There is an emacs skel for a set of emacs scripts that will auto-format

Essentially the idea is that the skeleton will put some comments in that EMACS script understands, apply a predefined format style, that more importantly than "GNU" or "Linux" or where "{" goes, DOESN'T MUCK UP MACROS!

Pre-processor macros are a key part of VPP and need special format attention.

C-code style for VPP is "gnu"

  • Load the emacs skel by either opening and "M-x eval-buffer" or "M-x load-file" ..
.../build-root/emacs-lisp/fix-coding-style.el
  • Now you should have a meta-function "M-x fd-io-styleify"
  • Run this against an active buffer containing the VPP code you wish to apply the style to.

You should see diffs of this sort:

+/* *INDENT-OFF* */
VLIB_CLI_COMMAND (test_sr_debug, static) = {
    .path = "test sr debug",
    .short_help = "test sr debug on|off",
    .function = test_sr_debug_fn,
};
+/* *INDENT-ON* */
+
+/*
+ * fd.io coding-style-patch-verification: ON
+ *
+ * Local Variables:
+ * eval: (c-set-style "gnu")
+ * End:
+ */

NOTE: The bolded selective switching on/off of indentation to protect macro sanity.

  • Save file and, assuming you have installed "indent" from apt/rpm, from a bash prompt:
indent <files>

Note it maybe easier to do the following assuming you are only doing indent changes:

indent `git status -s | sed s/^...//`
  • Fix any warnings or errors

ie

alagalah@thing2:vpp (docs-format-sr)*$ indent vnet/vnet/sr/sr.c
indent: vnet/vnet/sr/sr.c:1056: Warning:old style assignment ambiguity in "=&".  Assuming "= &"

indent: vnet/vnet/sr/sr.c:1381: Warning:old style assignment ambiguity in "=&".  Assuming "= &"

indent: vnet/vnet/sr/sr.c:1624: Warning:old style assignment ambiguity in "=&".  Assuming "= &"

Make changes and run indent again. (in the above case indent took care of it for us, and backup file is sr.c~)

Make

a couple of build targets make the process easy. At any time during the development process:

 make checkstyle

to see which files have style errors. And;

 make fixstyle

to fix them.

Be sure to fix any style errors before review as 'make checkstyle' is part of the verify job.