User Tools

Site Tools

Trace:
tools:style_guides:bash

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
tools:style_guides:bash [2018/09/07 14:46]
pechevar 		tools:style_guides:bash [2018/09/07 15:14] (current)
pechevar
Line 1: Line 1:
-These are basic style recommendations, compiled from google official style guide (https://google-styleguide.googlecode.com/svn/trunk/shell.xml) and other useful websites.+These are basic style recommendations, compiled from[[https://google.github.io/styleguide/shell.xml|  google  
 + official style guide ]] and other useful websites. 
 In order to achieve more efficient and homogeneous coding, it's been agreed that new codes submitted to the different git projects would be accepted to be committed to the master branches only if the style guide recommendations are respected. This is also a strong recommendation for your personal scripts. In order to achieve more efficient and homogeneous coding, it's been agreed that new codes submitted to the different git projects would be accepted to be committed to the master branches only if the style guide recommendations are respected. This is also a strong recommendation for your personal scripts.
  
-  * File Header+====== File Header ====== 
 The first line of your file must indicate in which language your script is written (http://en.wikipedia.org/wiki/Shebang_%28Unix%29), generally bash (#!/bin/bash). The first line of your file must indicate in which language your script is written (http://en.wikipedia.org/wiki/Shebang_%28Unix%29), generally bash (#!/bin/bash).
 Every file must have a top-level comment including a brief overview of its contents and eventually how to use it. Author information is recommended. Every file must have a top-level comment including a brief overview of its contents and eventually how to use it. Author information is recommended.
Line 24: Line 27:
 # Adapted: Pierre-Antoine Bretonnière - IC3 , January 2013 # Adapted: Pierre-Antoine Bretonnière - IC3 , January 2013
 </code> </code>
-  * Indentation+====== Indentation ======
 Indent 2 spaces. NO TABS. Indent 2 spaces. NO TABS.
  
 Use blank lines between blocks to improve readability. Indentation is two spaces. Whatever you do, don't use tabs. For existing files, stay faithful to the existing indentation. Use blank lines between blocks to improve readability. Indentation is two spaces. Whatever you do, don't use tabs. For existing files, stay faithful to the existing indentation.
  
-  * Loops+====== Loops ======
 Put ; do and ; then on the same line as the while, for or if. Put ; do and ; then on the same line as the while, for or if.
  
Line 51: Line 54:
 done done
 </code> </code>
-  * Case statement+======  Case statement ======
  
 Indent alternatives by 2 spaces. Indent alternatives by 2 spaces.
Line 75: Line 78:
 Simple commands may be put on the same line as the pattern and ;; as long as the expression remains readable. Simple commands may be put on the same line as the pattern and ;; as long as the expression remains readable.
  
-  * Command Substitution+====== Command Substitution ======
 Use $(command) instead of backticks. Use $(command) instead of backticks.
  
Line 88: Line 91:
 var="`command \`command1\``" var="`command \`command1\``"
 </code bash> </code bash>
-  * Test, [ and [[+ 
 +====== Test, [ and [[ ======
 <nowiki>[[</nowiki> <nowiki>[[</nowiki>
 <nowiki>[[</nowiki> <nowiki>[[</nowiki>
Line 113: Line 117:
 fi fi
 </code> </code>
-  * Function and variables names+======  Function and variables names ======
 Lower-case, with underscores to separate words. Parentheses are required after the function name. The keyword function is optional, but must be used consistently throughout a project. Lower-case, with underscores to separate words. Parentheses are required after the function name. The keyword function is optional, but must be used consistently throughout a project.
 Same thing for variables: lower-case, with underscores to separate words, with names as explicit as possible. Same thing for variables: lower-case, with underscores to separate words, with names as explicit as possible.
 However, constant (paths, environment variables and parameters passed through namelists) must be all caps, separated with underscores, declared at the top of the file. However, constant (paths, environment variables and parameters passed through namelists) must be all caps, separated with underscores, declared at the top of the file.
  
-  * Arithmetic +======  Arithmetic ====== 
-Never use the let command, nor use the $[...] syntax, nor use the shell helper expr.  Instead, use $((...)) to perform all math operations in conjunction with the colon null utility.+Never use the let command, nor use the ''$[...]'' syntax, nor use the shell helper expr.  Instead, use `$((...))` to perform all math operations in conjunction with the colon null utility.
  
-When using variables, avoid using the ${var} form when possible.  The shell knows to look up var as ${var} for you and omitting the ${...} leads to cleaner code. Note: this does not mean you should avoid using ${var} in non-arithmetic code.+When using variables, avoid using the ''${var}'' form when possible.  The shell knows to look up var as ''${var}''for you and omitting the ''${...}'' leads to cleaner code. Note: this does not mean you should avoid using ''${var}'' in non-arithmetic code.
  
 Example Example
Line 140: Line 144:
 echo $(( (min * 60) + sec )) echo $(( (min * 60) + sec ))
 </code> </code>
-  * Pipelines+====== Pipelines ======
 Pipelines (http://blog.petersobot.com/pipes-and-filters) should be split one per line if they don't all fit on one line. Pipelines (http://blog.petersobot.com/pipes-and-filters) should be split one per line if they don't all fit on one line.
  
tools/style_guides/bash.1536331616.txt.gz · Last modified: 2018/09/07 14:46 by pechevar

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki