SQL and PL/pgSQL Programming Style Guide: Unterschied zwischen den Versionen
Aus Geoinformation HSR
Stefan (Diskussion | Beiträge) (Die Seite wurde neu angelegt: «== SQL and general == * File names in lowercase_with_underscores, encoding UTF-8 * Use pgFormatter - online http://sqlformat.darold.net/ * Indent with 4 spaces…») |
Stefan (Diskussion | Beiträge) K |
||
Zeile 6: | Zeile 6: | ||
* Else follow this guideline https://www.sqlstyle.guide (compatible with Joe Celko’s SQL Programming Style book) | * Else follow this guideline https://www.sqlstyle.guide (compatible with Joe Celko’s SQL Programming Style book) | ||
− | == PL/pgSQL (inspired partially by [https://tandysony.com/2018/02/14/pep-8.html PEP 8]) | + | == PL/pgSQL (inspired partially by [https://tandysony.com/2018/02/14/pep-8.html PEP 8]) == |
* Naming conventions: | * Naming conventions: | ||
** Function names in lowercase_with_underscores (handle ST_-functions insensitive). | ** Function names in lowercase_with_underscores (handle ST_-functions insensitive). |
Version vom 1. Juni 2020, 19:21 Uhr
SQL and general
- File names in lowercase_with_underscores, encoding UTF-8
- Use pgFormatter - online http://sqlformat.darold.net/
- Indent with 4 spaces (don't use tags)
- Keywords, datatypes and functions should be all-lowercase (opposite to Joe Celko’s!)
- Else follow this guideline https://www.sqlstyle.guide (compatible with Joe Celko’s SQL Programming Style book)
PL/pgSQL (inspired partially by PEP 8)
- Naming conventions:
- Function names in lowercase_with_underscores (handle ST_-functions insensitive).
- Function parameter names in lowercase_with_underscores
- Local variables and functions start with _underscore
- All-uppercase for CONSTANT_VARIABLES
- Max line-length 80 characters (especially in comments)
- Whitespace and newlines:
- Two blank lines before top-level functions
- Use blank lines sparingly
- Spaces around = for assignment and in mathematical operators
- No spaces around = for default parameter values
- Multiple statements on the same line are discouraged
- Comments:
- Use inline comments sparingly & avoid obvious comments
- Write in whole sentence and in plain and easy-to-follow English
- Add space after line comment (- a comment); no space for commented-out code (-raise notice)
- Keep comments up to date - incorrect comments are worse than no comments
- All "public" functions should have docstrings (""")
- In docstrings, list each argument on a separate line
- Docstrings should have a blank line after first line and before the final """