Coding standards and developmental best practices at OSU Libraries & Press.
Language Notes:
- "Use" is a positive instruction, equivalent to "must use".
- "Prefer" indicates a better option and its alternative to watch out for.
- "Avoid" means don't do it unless you have good reason.
- "Don't" means there's never a good reason.
- Use two spaces to an indent.
- Use unix-style line endings.
- Use a newline at the end of the file.
- Don't leave trailing whitespace.
- Do document every method using comments.
- Prefer automatic documentation systems which use tag syntax.
- Specific recommendations can be found in the language-specific files.
- Avoid inline comments.
- Use Git for source control.
- Do work in feature branches, named with a prefix 'feature/[branch-name]'.
- Publish feature branches to the GitHub repository when:
- Collaboratively developing the feature.
- Seeking code review in advance of a pull request.
- Sharing the feature externally.
- If your code isn't going to be useful or meaningful to others, clean it up first.
- Keep branches clean before publishing. Public commit history is immutable.
- Send pull requests to merge features to Master.
- Delete branches when they are fully merged and no longer needed.
- Keep pull requests clean.
- Retain 'milestone' commits, representing substantial peices of work.
- Squash minor and personal workflow commits into milestones.
- Pull requests are subject to review. Someone other than you must merge them.
- Let CI finish before merging a pull request.
- Use environment variables to store confidential information.
- If this is not possible be sure that an example config is provided, the true config is not in source control, and the proper config is set up in production via an automatic deploy step.
