-
Notifications
You must be signed in to change notification settings - Fork 4
Coding Conventions and Team Policies
The following conventions are inspired by this reference.
This coding style guide has been adopted for Java, the core language of the application.
Follow the convention of prefixing the type, as in type_foo_bar.xml. Examples: fragment_contact_details.xml, view_primary_button.xml, activity_main.xml.
Similarly, this convention applies to ids: feature_button_next.
Organize files by feature, with subdirectories, if applicable.
project
│ README.md
│
└───travel
│ │
│ │
│ └───database
│ |
│ │
│ └───destinationpicker
│ │ file111.txt
│ │ file112.txt
│ │ ...
│
└───privatebrowsing
│ file021.txt
│ file022.txt
Use ButterKnife to bind XML elements to Java variables
@BindView(R.id.id_of_thing) TextView textVariable;Limit the use of the following
variable.findViewById(R.id.id_of_thing)Any text that appears in the application should be added as string resources. Naming convention applies.
Bad
<string name="network_error">Network error</string>
<string name="call_failed">Call failed</string>
<string name="map_failed">Map loading failed</string> Good
<string name="error_message_network">Network error</string>
<string name="error_message_call">Call failed</string>
<string name="error_message_map">Map loading failed</string>For UI, avoid nested views: use ConstraintLayout when possible.
Check this out for more information on this type of layout.
The following policies will indicate the minimum requirements and expectations that are to be followed for project management and planning purposes. If these are not met, they will either be edited by monitors (team leader: @amawai and @jadmalek) or indicated as lacking wherever appropriate.
Every pull request must have the following:
- Reference the task (if a separate issue has been made) or user story being addressed
- Minimum of 2 reviewers and 2 approvals for the pull request to be merged
- Minimum of 2 comments in code and 1 overall comment (whether it is for an approval or request for changes, unless previous comments have accounted for approval/changes reasons) per reviewer. Comments such as this looks good, runs fine, good job, etc. will be indicated as insufficient. Also, vague reviews (use of words like appears, seems, looks like, etc.) need to be avoided as they essentially imply uncertainty. This strict minimum can be softened for pull requests that involve fixing a bug, code refactoring, very small commits, or merging already pull requested code from develop into master
- Label the pull request with the feature being implemented and the sprint in question. If the pull request is for an environment fix or something else in particular, it will be labelled as such
Reviewers assigned to pull requests need to address them (comment, approve, etc.) within one day of the pull requests' creation.
For sprints 4 to 6 (releases 2 and 3), separate issues will be made for each task of a feature-based user story issue (thusly excludes stories addressing documentation, design or testing concerns). These task issues need to have the following:
- Reference the user story
- Assignee (maximum 1 person for traceability). Otherwise, do not break apart the story issue into separate task issues
- Risk assessment (high, medium or low)
- Priority assignment
- Number of story points
- Applicable labels, namely task and the feature type (or simply add the label environment, documentation, etc. if the task can be categorized as such)
- Add it to the "To do" in "Projects" and indicate the "Sprint"
Each and every single commit needs to consist of the following:
- Always reference the task (if a separate issue has been made) or user story being addressed (this is of the utmost importance)
- Indicated the purpose of the commit. Specifically, indicate the 'why' of what was done. Was it an addition? Was it a fix of something already present? Explain the commit based on these kinds of questions