-
Notifications
You must be signed in to change notification settings - Fork 10
Code conventions and Workflow
nslandolt edited this page May 21, 2020
·
5 revisions
- In order to ensure standard format across our Python code base, all Python code should be run through Black before being committed to the repository
- Code should also adhere to the PEP 8 standard paying special attention to class/method/variable naming conventions
- Variables/methods that contain/return collections should be pluralized.
- Model classes return a single instance and should be singular
- Methods of a class should not be prefixed with the name of the class: ie: user.user_name > user.name
- In order to ensure standard format across our React code base, all React code should be run through Prettier before being committed to the repository
- Feature branches should only encompass a single feature and be short lived (1-2 days) -- it is suggested that branches have been code reviewed before being squashed and merged, but feel free to use your discretion
- When squashing merging your PR into master check to see if it has fallen behind master in commits. If the new commits in master effects your new changes, rebase your branch off of master before squashing and merging.
- GraphQL Faker will be used as a starting point to determine exactly what data the front end developers need from the API
- Once the data required has been determined, the front end design work can commence, and the real API calls can be implemented. No new API calls should be implemented unless explicitly asked for via our faker file
This project was built by the Treasury Board of Canada Secretariat in collaboration with the Canadian Centre for Cyber Security.