aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKate Ward <kate.ward@forestent.com>2018-01-25 15:27:32 +0100
committerKate Ward <kate.ward@forestent.com>2018-01-25 15:27:32 +0100
commit035a31e38f4e3359034de03d42ae9b9fddf91eca (patch)
tree310393c6729745e5a26c6694816faeb3e4f88015
parent63cef9595b0909d432ab4d93fd1e4b1fe2456081 (diff)
downloadshflags-035a31e38f4e3359034de03d42ae9b9fddf91eca.tar.gz
Ran through Markdown formatter.
-rw-r--r--CONTRIBUTING.md62
1 files changed, 28 insertions, 34 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index b071876..9915b70 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,5 +1,4 @@
-Coding Standards
-================
+# Coding Standards
shFlags is more than just a simple 20 line shell script. It is a pretty
significant library of shell code that at first glance is not that easy to
@@ -7,8 +6,7 @@ understand. To improve code readability and usability, some guidelines have been
set down to make the code more understandable for anyone who wants to read or
modify it.
-Function declaration
---------------------
+## Function declaration
Declare functions using the following form:
@@ -24,31 +22,30 @@ One-line functions are allowed if they can fit within the 80 char line limit.
doSomething() { echo 'done!'; }
```
-Function documentation
-----------------------
+## Function documentation
Each function should be preceded by a header that provides the following:
-1. A one-sentence summary of what the function does.
+1. A one-sentence summary of what the function does.
-1. (optional) A longer description of what the function does, and perhaps some
- special information that helps convey its usage better.
+1. (optional) A longer description of what the function does, and perhaps some
+ special information that helps convey its usage better.
-1. Args: a one-line summary of each argument of the form:
+1. Args: a one-line summary of each argument of the form:
- `name: type: description`
+ `name: type: description`
-1. Output: a one-line summary of the output provided. Only output to STDOUT
- must be documented, unless the output to STDERR is of significance (i.e. not
- just an error message). The output should be of the form:
+1. Output: a one-line summary of the output provided. Only output to STDOUT
+ must be documented, unless the output to STDERR is of significance (i.e. not
+ just an error message). The output should be of the form:
- `type: description`
+ `type: description`
-1. Returns: a one-line summary of the value returned. Returns in shell are
- always integers, but if the output is a true/false for success (i.e. a
- boolean), it should be noted. The output should be of the form:
+1. Returns: a one-line summary of the value returned. Returns in shell are
+ always integers, but if the output is a true/false for success (i.e. a
+ boolean), it should be noted. The output should be of the form:
- `type: description`
+ `type: description`
Here is a sample header:
@@ -66,8 +63,7 @@ Here is a sample header:
# boolean: success of operation (always returns True)
```
-Variable and function names
----------------------------
+## Variable and function names
All shFlags specific constants, variables, and functions will be prefixed
appropriately with 'flags'. This is to distinguish usage in the shFlags code
@@ -82,39 +78,37 @@ naming and use of variables, both public and private, is very important.
Accidental overriding of the variables can occur easily if care is not taken as
all variables are technically global variables in some shells.
-Type | Sample
----- | ------
+Type | Sample
+-------------------------------- | ---------------------
global public constant | `FLAGS_TRUE`
global private constant | `__FLAGS_SHELL_FLAGS`
global public variable | `flags_variable`
global private variable | `__flags_variable`
global macro | `_FLAGS_SOME_MACRO_`
public function | `flags_function`
-public function, local variable | ``flags_variable_`
+public function, local variable | `flags_variable_`
private function | `_flags_function`
private function, local variable | `_flags_variable_`
-Where it makes sense to improve readability, variables can have the first
-letter of the second and later words capitalized. For example, the local
-variable name for the help string length is `flags_helpStrLen_`.
+Where it makes sense to improve readability, variables can have the first letter
+of the second and later words capitalized. For example, the local variable name
+for the help string length is `flags_helpStrLen_`.
There are three special-case global public variables used. They are used due to
overcome the limitations of shell scoping or to prevent forking. The three
variables are:
-- `flags_error`
-- `flags_output`
-- `flags_return`
+- `flags_error`
+- `flags_output`
+- `flags_return`
-Local variable cleanup
-----------------------
+## Local variable cleanup
As many shells do not support local variables, no support for cleanup of
variables is present either. As such, all variables local to a function must be
cleared up with the `unset` built-in command at the end of each function.
-Indentation
------------
+## Indentation
Code block indentation is two (2) spaces, and tabs may not be used.