Minor markup formatting change

Andrew Janke 2015-05-29 22:39:50 -04:00
parent 55534bc2eb
commit 1cd6f5ce15

@ -1,14 +1,14 @@
##General Code Style## ## General Code Style ##
While you should follow the code style that's already there for files that you're modifying, the following are required for any new code. While you should follow the code style that's already there for files that you're modifying, the following are required for any new 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.
###Line Length and Long Strings### ### Line Length and Long Strings ###
Maximum line length is 80 characters. Maximum line length is 80 characters.
@ -29,7 +29,7 @@ long_string_2="I am an exceptionalllllllllllly
looooooooooooooooooooooooooooooooooooooooong string." looooooooooooooooooooooooooooooooooooooooong string."
``` ```
###Pipelines### ### Pipelines ###
Pipelines should be split one per line if they don't all fit on one line. Pipelines should be split one per line if they don't all fit on one line.
@ -63,7 +63,7 @@ $PWD
TODO: Add a list of all environment variables you can use. TODO: Add a list of all environment variables you can use.
###If / Loop### ### If / For / While ###
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`.
@ -84,9 +84,9 @@ for dir in ${dirs_to_cleanup}; do
done done
``` ```
##Variables## ## Variables ##
###Naming Conventions### ### Naming Conventions ###
Meaningful self-documenting names should be used. If the variable name does not make it reasonably obvious as to the meaning of the variable, appropriate comments should be added. Meaningful self-documenting names should be used. If the variable name does not make it reasonably obvious as to the meaning of the variable, appropriate comments should be added.
@ -109,7 +109,7 @@ local UPPERCASE=""
UPPERCASE="" UPPERCASE=""
``` ```
Variables name should not clobber command names, such as `dir` or `pwd`. Variable names should not clobber command names, such as `dir` or `pwd`.
``` ```
# Bad: # Bad:
@ -127,7 +127,7 @@ for zone in ${zones}; do
done done
``` ```
###Use local variables### ### Use local variables ###
Ensure that local variables are only seen inside a function and its children by using `local` or other `typeset` variants when declaring them. This avoids polluting the global name space and inadvertently setting or interacting with variables that may have significance outside the function. Ensure that local variables are only seen inside a function and its children by using `local` or other `typeset` variants when declaring them. This avoids polluting the global name space and inadvertently setting or interacting with variables that may have significance outside the function.
@ -150,9 +150,7 @@ echo "global_var = $global_var" # global_var = 37
# Good: # Good:
function func_good() { function func_good() {
local local_var="" local local_var=""
local_var=37 local_var=37
echo $local_var echo $local_var
} }
@ -165,7 +163,7 @@ global_var=$(func_good)
echo "global_var = $global_var" # move function result to global scope echo "global_var = $global_var" # move function result to global scope
``` ```
In the next example, lots of global variables are used over and over again, but the script "unfortunately" works anyway. The `parse_json()` function does not even return a value and the two functions shares their variables. You could also write all this without any function; this would have the same effect. In the next example, lots of global variables are used over and over again, but the script "unfortunately" works anyway. The `parse_json()` function does not even return a value and the two functions share their variables. You could also write all this without any function; this would have the same effect.
Bad-Example: with global variables Bad-Example: with global variables
``` ```
@ -259,7 +257,7 @@ parse_ubuntuusers_json
echo "foobar: $counter - $i" echo "foobar: $counter - $i"
``` ```
###Constants and Environment Variable Names### ### Constants and Environment Variable Names ###
All caps, separated with underscores, declared at the top of the file. All caps, separated with underscores, declared at the top of the file.
Constants and anything exported to the environment should be capitalized. Constants and anything exported to the environment should be capitalized.
@ -268,7 +266,7 @@ Constants and anything exported to the environment should be capitalized.
# Constant # Constant
readonly PATH_TO_FILES='/some/path' readonly PATH_TO_FILES='/some/path'
# Both constant and environment # Both constant and exported
declare -xr ORACLE_SID='PROD' declare -xr ORACLE_SID='PROD'
``` ```
@ -284,7 +282,7 @@ done
readonly VERBOSE readonly VERBOSE
``` ```
###Read-only Variables### ### Read-only Variables ###
Use `readonly` or `declare -r` to ensure they're read-only. Use `readonly` or `declare -r` to ensure they're read-only.
As globals are widely used in shell, it's important to catch errors when working with them. When you declare a variable that is meant to be read-only, make this explicit. As globals are widely used in shell, it's important to catch errors when working with them. When you declare a variable that is meant to be read-only, make this explicit.
@ -298,9 +296,9 @@ else
fi fi
``` ```
##Functions## ## Functions ##
###Naming Conventions### ### Naming Conventions ###
Lower-case, with underscores to separate words. Parentheses are required after the function name. The `function` keyword is optional when `()` is present after the function name, but it aids readability and prevents [conflicts with alias declarations](http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Aliasing), so please use it! Lower-case, with underscores to separate words. Parentheses are required after the function name. The `function` keyword is optional when `()` is present after the function name, but it aids readability and prevents [conflicts with alias declarations](http://zsh.sourceforge.net/Doc/Release/Shell-Grammar.html#Aliasing), so please use it!
@ -333,7 +331,7 @@ function _helper_util() {
} }
``` ```
###Use return values### ### Use return values ###
After a script or function terminates, a `$?` from the command-line gives the exit status of the script, that is, the last command executed in the script, which is, by convention, 0 on success or an integer in the range 1 - 255 on error. After a script or function terminates, a `$?` from the command-line gives the exit status of the script, that is, the last command executed in the script, which is, by convention, 0 on success or an integer in the range 1 - 255 on error.
@ -374,33 +372,34 @@ function my_good_func() {
} }
``` ```
###Check return values### ### Return values ###
Always check return values and give informative return values. Always check return values and give informative error messages. For unpiped commands, use `$?` or check directly via an if statement to keep it simple. Use nonzero return values to indicate errors.
For unpiped commands, use `$?` or check directly via an if statement to keep it simple.
``` ```
# Bad: # Bad:
mv "${file_list}" "${dest_dir}/" mv "${file_list}" "${dest_dir}/"
# Good:
mv "${file_list}" "${dest_dir}/" || exit 1
# Good: # Good:
if ! mv "${file_list}" "${dest_dir}/"; then if ! mv "${file_list}" "${dest_dir}/"; then
echo "Unable to move ${file_list} to ${dest_dir}" >&2 echo "Unable to move ${file_list} to ${dest_dir}" >&2
exit "${E_BAD_MOVE}" exit 1
fi fi
# Good: use "$?" to get the last return value # Good: use "$?" to get the last return value
mv "${file_list}" "${dest_dir}/" mv "${file_list}" "${dest_dir}/"
if [[ "$?" -ne 0 ]]; then if [[ "$?" -ne 0 ]]; then
echo "Unable to move ${file_list} to ${dest_dir}" >&2 echo "Unable to move ${file_list} to ${dest_dir}" >&2
exit "${E_BAD_MOVE}" exit 1
fi fi
``` ```
##Features and Bugs## ## Features and Bugs ##
###Command Substitution### ### Command Substitution ###
Use `$(command)` instead of backticks. Use `$(command)` instead of backticks.
@ -411,14 +410,14 @@ Nested backticks require escaping the inner ones with `\`. The `$(command)` form
var="`command \`command1\``" var="`command \`command1\``"
# Good: # Good:
var="$(command "$(command1)")" var="$(command \"$(command1)\")"
``` ```
###Eval### ### Eval ###
Eval is evil! Eval munges the input when used for assignment to variables and can set variables without making it possible to check what those variables were. Avoid `eval` if possible. Eval is evil! Eval munges the input when used for assignment to variables and can set variables without making it possible to check what those variables were. Avoid `eval` if possible.
##Sources## ## References ##
- [Shell Style Guide](https://google-styleguide.googlecode.com/svn/trunk/shell.xml) - [Shell Style Guide](https://google-styleguide.googlecode.com/svn/trunk/shell.xml)
- [BASH Programming - Introduction HOW-TO](http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html) - [BASH Programming - Introduction HOW-TO](http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html)