Style Guides
Introduction
When working on collaborative code projects, it can be helpful to come to some agreements ahead of time regarding how to compose code and how to make changes to code repositories. Today, we are going to think through some of these issues by generating a code style guide.
Formatting and Naming
Standard formatting conventions are important for organizing, managing, and sharing code. Conventions ensure that:
If you were to step away from the project and come back to it in 5 years, you would be able to understand and navigate the code quickly.
If you were to share the repository with another developer, the developer would be able to understand and navigate the code quickly.
Here are some questions that you should consider as you draft this section of your style guide:
- What standards will you use for naming files? (e.g. underscores, dashes, etc.) How will you ensure that file names are easily differentiated by all team members?
- How will files be organized into folders in your repo? What will the main folders be?
- What standards will you use for formatting object names in your code? (e.g. underscores, dashes, etc.) How will you ensure that object names are easily differentiated by all team members?
- How will you comment code? Where should comments be placed in code? What will their purpose be? Do you expect full sentences?
- What are the expectations for white space in your code? Will you include spaces between each symbol/punctuation mark? What about parentheses?
- When will line breaks be added to the code?
- What standards will you use for code indentation?
Code Writing and Review
Developing standard processes for code writing and review will help ensure that team members are not overwriting each other’s work, that code is consistently being reviewed before inclusion in the repo, and that generally everyone understands their roles in the repo’s maintenance. It will also reduce merge conflicts. Here are some things to consider when drafting this portion of your style guide:
Will code always be written in separate branches? How will branches be named?
How will collaborators work across files? What mechanisms will you put into place to mitigate merge conflicts when collaborators are working on the same files?
Should there be a GitHub Issue associated with each pull request?
How often do you expect team members to commit their code? (e.g. after each substantive change; after changes to x lines of code)
What standards will you put in place for commit messages? What do you expect to see in a commit message?
When/how often will pull requests be issued?
When will you have team members review code? How will you designate that code needs to be reviewed?
After a review, if changes need to be made, what will the code editing process look like?
Who will be responsible for merging code?