Skip to content

Commit 4f61537

Browse files
anishmanandharanishmanandhar
committed
Merge branch 'develop' of github.com:leapfrogtechnology/coding-standards-convention into java
# Conflicts: # sidebars.js
2 parents 8496745 + 0564f2f commit 4f61537

20 files changed

+13780
-3
lines changed

‎docs/git/branching_naming_convention.md‎

Lines changed: 19 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,19 @@
1+
---
2+
id: branch_naming_convention
3+
title: Branch Naming Convention
4+
sidebar_label: Branch Naming Convention
5+
---
6+
7+
#### The following convention should be followed:
8+
9+
* Branch name should exactly match with the corresponding JIRA ticket that you will be working on. `<project-name>-<ticket-number>`
10+
11+
Examples:
12+
* FHF-100
13+
* DEL-200
14+
15+
* If there's no JIRA or project management tool in use, the branch naming strategy should be feature specific.
16+
17+
Examples:
18+
* upgrade-php
19+
* add-button-tooltip

‎docs/git/branching_strategy.md‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
id: branching_strategy
3+
title: Branching Strategy
4+
sidebar_label: Branching Strategy
5+
---
6+
7+
#### Main Branches:
8+
9+
* master (Production)
10+
* dev (Development)
11+
* qa (QA)
12+
* uat (UAT)
13+
* staging (Staging)
14+
15+
#### Supporting Branches:
16+
17+
* Feature branches
18+
* Release branches
19+
* Hotfix branches
20+
21+
#### The following convention should be followed:
22+
23+
* Every branch should be a branch of `dev` and should be merged to `dev` after PR is reviewed
24+
* Every feature, task is done in a separate branch <b>named according to the JIRA issue name</b>.
25+
* Any critical bug after production release is done via hotfix branches. It is branched off from `master` and <b>merged back to master and dev after it’s done</b>.

‎docs/git/code_review_checklist.md‎

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
---
2+
id: code_review_checklist
3+
title: Code Review Checklist
4+
sidebar_label: Code Review Checklist
5+
---
6+
7+
Smart commits allows a team to perform actions on JIRA issues from a single commit. Users can enter the issue key and the desired action such as time tracking or closing an issue.
8+
9+
#### List:
10+
11+
* Description Confirmed?
12+
* The code meets the business requirements
13+
* Comments are comprehensible and add something to the maintainability of the code
14+
* Comments are neither too numerous nor verbose
15+
* Types have been generalized where possible
16+
* Parameterized types have been used appropriately
17+
* Exceptions have been used appropriately
18+
* Repetitive code has been factored out
19+
* Frameworks have been used appropriately – methods have all been defined appropriately
20+
* Command classes have been designed to undertake one task only
21+
* Unit tests are present and correct
22+
* Common errors have been checked for
23+
* Potential threading issues have been eliminated where possible
24+
* Any security concerns have been addressed
25+
* Performance was considered
26+
* The functionality fits the current design/architecture
27+
* The code is unit testable
28+
* The code does not use unjustifiable static methods/blocks
29+
* The code complies to coding standards
30+
* Logging used appropriately (proper logging level and details)
31+
* The code does not reinvent the wheel
32+
* The code does not have any side effect on existing functionality
33+
34+
35+
##### References:
36+
37+
<a href="https://lftechnology.atlassian.net/wiki/spaces/PPM/pages/25854080/Code+Review+Checklist+for+Reviewers" target="_blank"> Code Review Checklist</a>

‎docs/git/pull_request_best_pratices.md‎

Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
---
2+
id: pull_request_best_pratices
3+
title: Pull Request Best Practices
4+
sidebar_label: Pull Request Best Practices
5+
---
6+
7+
#### Best Practices:
8+
9+
* Pull Request should atleast be <b>reviewed by 1 person</b> before merging it to the base branch.
10+
* Only comment author can resolve comment – if code was corrected or after discussion author decides to fix it.
11+
* Don’t mention the same problem many times. Don’t bloat the code, say it once and ask to fix everywhere.
12+
* If there are pending, not resolved comments, the assignee is a code author who should fix or comment back.
13+
* If there are discussions commented by the code author, the assignee is reviewer, who should continue a discussion or resolve comments and approve.
14+
* Use labels to mark what actions should be next – e.g. `needs review`, `Reviewed By... ` etc.
15+
* Provide details/screenshots about what has been changed.

‎docs/git/smart_commit.md‎

Lines changed: 18 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,18 @@
1+
---
2+
id: smart_commit
3+
title: Smart Commit
4+
sidebar_label: Smart Commit
5+
---
6+
7+
Smart commits allows a team to perform actions on JIRA issues from a single commit. Users can enter the issue key and the desired action such as time tracking or closing an issue.
8+
9+
#### Some of the mostly used smart commands:
10+
11+
* `#comment`: Adds a comment to a JIRA issue. `ISSUE_KEY #comment <your comment text>`
12+
* `#time` : Records time tracking information against a JIRA issue.
13+
* `#<transition-name>` : Moves the JIRA issue to a particular workflow state.
14+
15+
#### Examples:
16+
17+
- git commit -m "FHF-34 #time 1w 2d 4h 30m Total work logged".
18+
- DEL-101 #time 4h 30m Fix null pointers #comment Fixed code #resolve

‎docs/git/tagging.md‎

Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
---
2+
id: tagging
3+
title: Tagging
4+
sidebar_label: Tagging
5+
---
6+
7+
Semantic Versioning is all about releases, not builds. This means that the version only increases after you release.
8+
9+
Following are the standards that should be followed while tagging releases:
10+
11+
* Every release should have a tag.
12+
* You can tag from any long running branch ( dev, qa, staging, master). However, we strictly follow tagging from master branch.
13+
* Tag name should follow the *major.minor.patch_* naming conventions as suggested by <a href="https://semver.org/" target="_blank">Semantic Versioning</a>
14+
* The tag for a version is in "X.Y.Z" format where,
15+
* Z is hot-fixes and patch release. If the release includes hot-fixes and patches, we increment this value by 1. Example : "2.7.1", "2.7.2"
16+
* Y includes major feature releases. If the release includes a major feature which is going to production for the first time we increase this value by 1. Example: "2.8.0", "2.9.0"
17+
* X is increased when there is a major change in the system which affects the entire application flow or UI/UX(flow) of a system. Example: "3.0.0", "4.0.0" .

‎docs/rest-api/delete.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
id: delete
3+
title: Delete Method
4+
sidebar_label: Delete
5+
---
6+
7+
As the name applies, **DELETE** APIs are used to delete resources (identified by the Request-URI).
8+
9+
A successful response of DELETE requests SHOULD be HTTP response code 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has been queued, or 204 (No Content) if the action has been performed but the response does not include an entity.
10+
11+
DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources. Repeatedly calling DELETE API on that resource will not change the outcome – however, calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed. Some may argue that it makes the DELETE method non-idempotent. It’s a matter of discussion and personal opinion.
12+
13+
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.
14+
15+
> * **/employees/{employee-id}**
16+
> * **/departments/{department-id}**
17+
18+
| Response code | Result/Reason |
19+
|---------------------------|------------------------------|
20+
|200 OK | Sucessfully deleted the Enity.|
21+
|401 (Unauthorized) | Invalid Credentials/ Invalid Authentication |
22+
|403 (Forbidden) | Invalid Authorization/ Insufficient rights/ Incorrect Role |
23+
|405 (Method Not allowed) | If API supports methods other than PUT request |
24+
|500 (Internal server error)| Server encountered an unexpected condition that prevented it from fulfilling the request.|

‎docs/rest-api/get.md‎

Lines changed: 25 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,25 @@
1+
---
2+
id: get
3+
title: Get Method
4+
sidebar_label: Get
5+
---
6+
7+
Use **GET requests** to retrieve resource representation/information only – and not to modify it in any way. As GET requests do not change the state of the resource, these are said to be safe methods. Additionally, GET APIs should be **idempotent**, which means that making multiple identical requests must produce the same result every time until another API (POST/PUT/PATCH/DELETE) has changed the state of the resource on the server.
8+
9+
> * **/employees**
10+
> * **/employees/{employee-id}/leaves**
11+
> * **/employees/{employee-id}/employee-reports**
12+
13+
Use query params to filter response or get subset or limited resource.
14+
15+
> * **/employees/{employee-id}/leaves?type={leave-type}&order-by={leave-date}**
16+
17+
| Response code | Result/Reason |
18+
|---------------------------|------------------------------|
19+
|200 OK | Sucessfully Fetched the Enity. <br/> Must include a response body. |
20+
|404 (Not found) | If Entity not found for given ID or is invalid ID|
21+
|405 (Method Not allowed) | If API supports methods other than GET request |
22+
|401 (Unauthorized) | Invalid Credentials/ Invalid Authentication |
23+
|403 (Forbidden) | Invalid Authorization/ Insufficient rights/ Incorrect Role |
24+
|410 (Gone) | Expired link/Server no longer serve this request.|
25+
|500 (Internal server error)| Server encountered an unexpected condition that prevented it from fulfilling the request. |

‎docs/rest-api/hateaos.md‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
---
2+
id: hateaos
3+
title: HATEAOS
4+
sidebar_label: HATEAOS
5+
---
6+
7+
#### HATEAOS

‎docs/rest-api/headers.md‎

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
---
2+
id: headers
3+
title: Headers Best Practices
4+
sidebar_label: Headers
5+
---
6+
7+
#### The following convention should be followed for REST API Headers
8+
9+
* Headers names should be **noun** and should be **Captialised-Case** separated by **(-)**. e.g **Token-Key**, **Account-ID**, **Tenant-ID** etc
10+
11+
* For cases like Acronym, use acronyms itself. eg. *PID-value*, *PIN*
12+
13+
* Headers can be used for meta information that the API carries for e.g
14+
* Authentication
15+
* Authorization
16+
* Versioning the API
17+
* Content-Type
18+
* Caching etc
19+
* <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers" target="_blank">More Examples</a>
20+
21+
* Avoid using headers for business logic
22+
23+
* Use headers for parameters that should not appear in the URL
24+
* for e.g https://api.application.com/users/{id}/fetch?apiKey=abcd123456789 //**BAD Practice**

0 commit comments

Comments
 (0)