Skip to content

Commit 1b5ef83

Browse files
anishmanandharanishmanandhar
committed
Merge branch 'javascript' of github.com:leapfrogtechnology/coding-standards-convention into develop
2 parents defd35e + 6dfc043 commit 1b5ef83

File tree

8 files changed

+396
-3
lines changed

8 files changed

+396
-3
lines changed

‎docs/java/variables.md‎

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -17,9 +17,10 @@ sidebar_label: Variables
1717

1818
* Variable name should be plural if that is a collections. for e.g **employees**, **leaves** represents a list.
1919

20-
* Variables names should be declared as per their types
20+
* Variables names should be declared as per their types
2121
* Map/KeyValue pair should be declared as *keyToValue* and *valueByKey*. For e.g **ageByName** or **nameToAge**.
2222
* Set can be prefixed as *unique* before variable names. For e.g **uniqueNames**
23+
* Boolean can be prefixed as **is/are/has** e.g. **isVisible**, **isEligible**, **hasMaximumAmount**
2324

2425
* Instance variable should be camelCase of their class names.
2526
* employeeService is an instance of EmployeeService.
@@ -28,4 +29,4 @@ sidebar_label: Variables
2829
## Constants
2930

3031
* Constants names holds same conventions as variable except it should be **UPPER_CASE** separated by **(_)** underscore.
31-
* **AGE_BY_NAME**, **EMPLOYEE_REPORT**
32+
* **AGE_BY_NAME**, **EMPLOYEE_REPORT**

‎docs/javascript/classes.md‎

Lines changed: 54 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,54 @@
1+
---
2+
id: classes
3+
title: Classes
4+
sidebar_label: Classes
5+
---
6+
7+
#### The following convention should be followed for `class` naming:
8+
9+
### Classes
10+
11+
* Avoid inbuilt names.
12+
* Classes/Components/Interfaces names should always be `PascalCase` and `noun`. i.e. `TaskService`, `Interceptor`, `Evaluation`
13+
* Describe the class resposibility in name.
14+
* Custom Exceptions should always be named ending with `Error` or `Exception` i.e. `ValidationError` , `ValidationException`
15+
16+
<!--JavaScript-->
17+
class SoftwareDeveloper {
18+
constructor(firstName, lastName) {
19+
this.firstName = firstName;
20+
this.lastName = lastName;
21+
}
22+
}
23+
24+
var me = new SoftwareDeveloper('John', 'Doe');
25+
26+
### Components
27+
28+
* Components are not everywhere in JavaScript, but commonly found in frontend frameworks like React/Polymer/Vue. Since a component is kinda instantiated -- but appended to the DOM instead -- like a JavaScript class, they are widely declared with `PascalCase` and `noun` too.
29+
30+
<!--Javascript-->
31+
// bad
32+
function userProfile(user) {
33+
return (
34+
<div>
35+
<span>First Name: {user.firstName}</span>
36+
<span>Last Name: {user.lastName}</span>
37+
</div>
38+
);
39+
}
40+
41+
// good
42+
function UserProfile(user) {
43+
return (
44+
<div>
45+
<span>First Name: {user.firstName}</span>
46+
<span>Last Name: {user.lastName}</span>
47+
</div>
48+
);
49+
}
50+
51+
When a component gets used, it distinguishes itself from native HTML and web components, because its first letter is always written in uppercase.
52+
53+
<!--Javascript-->
54+
`<UserProfile user={{ firstName: 'John', lastName: 'Doe' }}/>`

‎docs/javascript/functions.md‎

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
---
2+
id: functions
3+
title: Functions
4+
sidebar_label: Functions
5+
---
6+
7+
#### Functions
8+
9+
JavaScript functions are written in camel case too. In addition, it's a best practice to actually tell what the function is doing by giving the function name a verb as prefix.
10+
11+
<!--Javascript-->
12+
// good
13+
function getName(firstName, lastName) {
14+
return `${firstName} ${lastName}`;
15+
}
16+
17+
// bad
18+
function name(firstName, lastName) {
19+
return `${firstName} ${lastName}`;
20+
}
21+
22+
This verb as prefix can be anything (e.g. get, fetch, push, apply, calculate, compute, post). It's yet another soft rule to consider for having more self-descriptive JavaScript variables.

‎docs/javascript/js-general-guidelines.md‎

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
---
2+
id: js-general-guidelines
3+
title: JS General Coding Guidelines
4+
sidebar_label: Javascript
5+
---
6+
7+
### Code Quality
8+
9+
#### Linter Validation
10+
11+
[ESLint](https://eslint.org) is a recommended linting tool for the JavaScript codebases and it is configured to enforce the recommended coding standards rules for best practices and consistency in the code itself before the code is committed to GitHub even.
12+
This statically analyzes the code and ensures the code is consistent, readable, maintainable and properly formatted before it's pushed to the version control.
13+
14+
**So, first of all, the code must comply with these eslint rules used in the project and must not leave any errors.**
15+
16+
#### Other Guidelines
17+
18+
Apart from the eslint validation. Following should be taken care of.
19+
20+
- No hard coding, use constants/configuration values instead of hard-coding literal values.
21+
22+
- Group similar values under a enumerated constants.
23+
24+
- Avoid code duplication. If the same code needs to be reused in multiple places, create a extract a common function instead.
25+
26+
- Write pure functions where ever possible. It keeps the code more understandable and deterministic, plus it helps to avoid unexpected run time issues due to mutation.
27+
28+
- Don't mutate the parameters received in functions.
29+
30+
<!--Javascript-->
31+
32+
// DO NOT MUTATE function parameters.
33+
function getName(person) {
34+
person.name = person.firstName + ' ' + person.lastName;
35+
return person.name;
36+
}
37+
38+
// Try to make the function a pure function where ever possible and avoid unnecessary side-effects.
39+
function getName(person) {
40+
let fullName = person.firstName + ' ' + person.lastName;
41+
return fullName;
42+
}
43+
44+
- Avoid unnecessary else blocks as much as possible.
45+
46+
<!--Javascript-->
47+
48+
// Avoid unnecessary else block if possible.
49+
function nullIfEmpty(value) {
50+
if (typeof value === 'string') {
51+
return value.trim() === '' ? null : value;
52+
} else {
53+
return value;
54+
}
55+
}
56+
57+
// Like this
58+
function nullIfEmpty(value) {
59+
if (typeof value !== 'string') {
60+
return value;
61+
}
62+
return value.trim() === '' ? null : value;
63+
}
64+
65+
- Avoid nested if blocks, multiple if blocks.
66+
67+
- While writing code make sure it doesn't violate SRP (Single Responsibility Principle). To be more specific take care of the following:
68+
69+
- A function should do only one task.
70+
71+
- Avoid having more than 3 parameters in a function.
72+
73+
- Break down or refactor code with complexity into multiple smaller functions.
74+
75+
- Use **async/awai**t or Promises for async operation and avoid callback hells.
76+
77+
- DocBlocks – Add doc blocks for each and every function, to clearly mention what it does. Docblocks also should mention the parameter types or return types.
78+
79+
<!--Javascript-->
80+
/**
81+
* Hit the twilio API to send notifications.
82+
*
83+
*
84+
* @param {object} payload
85+
* @returns {Promise<object>}
86+
*/
87+
function sendNotification(payload) {
88+
return twilioClient.sendMessage(payload);
89+
}
90+
91+
- Make use of higher order functions for array and list manipulation and transformation eg: map, reduce, filter etc instead of plain old for loops.
92+
<!--Javascript-->
93+
// Avoid using loops for list/array transformation like this
94+
function submitForm(users) {
95+
let promises = [];
96+
for (let user of users) {
97+
if (isNotSaved(user)) {
98+
promises.push(saveUser(user));
99+
}
100+
}
101+
return Promise.all(promises);
102+
}
103+
104+
// Prefer a more functional approach for
105+
// transformation using higher order function.
106+
function submitForm(users) {
107+
let promises = users
108+
.filter(isNotSaved)
109+
.map(saveUser);
110+
return Promise.all(promises);
111+
}
112+
113+
- Use framework features, or util functions provided by libraries wherever possible instead of writing custom code.
114+
- Don't hard-code text data in the code itself, instead put text content/messages in the internationalization files and use the content identifiers instead.
115+
- Each Components, Classes, or Interfaces should be written in their own file. And the filename should be named same as it's identifier. They must be exported as **default export**.
116+
- Use **PascalCase** naming convention for Components, Classes, or interfaces.
117+
- Use **camelCase** for naming functions and variables.
118+
- Use **CAPITAL_CASE_WITH_UNDERSCORES** for defining constants eg: const **PAGINATION_MAX_ROWS** = 15.

‎docs/javascript/ts-general-guidelines.md‎

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
---
2+
id: ts-general-guidelines
3+
title: TypeScript Coding Guidelines
4+
sidebar_label: TypeScript
5+
---
6+
7+
### Code Quality
8+
9+
#### Linter Validation
10+
11+
TSLint is being used as a linting tool for the TypeScript codebases and it is configured to enforce the recommended coding standards rules for best practices and consistency in the code itself before the code is committed to GitHub even.
12+
13+
This statically analyzes the code and ensures the code is consistent, readable, maintainable and properly formatted before it's pushed to the version control.
14+
15+
**So, first of all, the code must comply with these tslint rules used in the project and must not leave any errors.**
16+
17+
Rules Enforced in Project: https://github.com/leapfrogtechnology/backbone-core/blob/dev/tslint.json
18+
19+
All TSLint Rules: https://palantir.github.io/tslint/rules/
20+
21+
### Other Guidelines
22+
23+
Apart from the eslint validation. Following should be taken care of.
24+
25+
- No hard coding, use constants/configuration values instead of hard-coding literal values.
26+
27+
- Group similar values under a enumerated constants.
28+
29+
- Avoid code duplication. If the same code needs to be reused in multiple places, create a extract a common function instead.
30+
31+
- Write pure functions where ever possible. It keeps the code more understandable and deterministic, plus it helps to avoid unexpected run time issues due to mutation.
32+
33+
- Don't mutate the parameters received in functions.
34+
35+
<!--Javascript-->
36+
37+
// DO NOT MUTATE function parameters.
38+
function getName(person) {
39+
person.name = person.firstName + ' ' + person.lastName;
40+
return person.name;
41+
}
42+
43+
// Try to make the function a pure function where ever possible and avoid unnecessary side-effects.
44+
function getName(person) {
45+
let fullName = person.firstName + ' ' + person.lastName;
46+
return fullName;
47+
}
48+
49+
- Avoid unnecessary else blocks as much as possible.
50+
51+
<!--Javascript-->
52+
53+
// Avoid unnecessary else block if possible.
54+
function nullIfEmpty(value) {
55+
if (typeof value === 'string') {
56+
return value.trim() === '' ? null : value;
57+
} else {
58+
return value;
59+
}
60+
}
61+
62+
// Like this
63+
function nullIfEmpty(value) {
64+
if (typeof value !== 'string') {
65+
return value;
66+
}
67+
return value.trim() === '' ? null : value;
68+
}
69+
70+
- Avoid nested if blocks, multiple if blocks.
71+
72+
- While writing code make sure it doesn't violate SRP (Single Responsibility Principle). To be more specific take care of the following:
73+
74+
- A function should do only one task.
75+
76+
- Avoid having more than 3 parameters in a function.
77+
78+
- Break down or refactor code with complexity into multiple smaller functions.
79+
80+
- Use **async/awai**t or Promises for async operation and avoid callback hells.
81+
82+
- DocBlocks – Add doc blocks for each and every function, to clearly mention what it does. Docblocks also should mention the parameter types or return types.
83+
84+
<!--Javascript-->
85+
/**
86+
* Hit the twilio API to send notifications.
87+
*
88+
*
89+
* @param {object} payload
90+
* @returns {Promise<object>}
91+
*/
92+
function sendNotification(payload) {
93+
return twilioClient.sendMessage(payload);
94+
}
95+
96+
- Make use of higher order functions for array and list manipulation and transformation eg: map, reduce, filter etc instead of plain old for loops.
97+
<!--Javascript-->
98+
// Avoid using loops for list/array transformation like this
99+
function submitForm(users) {
100+
let promises = [];
101+
for (let user of users) {
102+
if (isNotSaved(user)) {
103+
promises.push(saveUser(user));
104+
}
105+
}
106+
return Promise.all(promises);
107+
}
108+
109+
// Prefer a more functional approach for
110+
// transformation using higher order function.
111+
function submitForm(users) {
112+
let promises = users
113+
.filter(isNotSaved)
114+
.map(saveUser);
115+
return Promise.all(promises);
116+
}
117+
118+
- Use framework features, or util functions provided by libraries wherever possible instead of writing custom code.
119+
- Don't hard-code text data in the code itself, instead put text content/messages in the internationalization files and use the content identifiers instead.
120+
- Each Components, Classes, or Interfaces should be written in their own file. And the filename should be named same as it's identifier. They must be exported as **default export**.
121+
- Use **PascalCase** naming convention for Components, Classes, or interfaces.
122+
- Use **camelCase** for naming functions and variables.
123+
- Use **CAPITAL_CASE_WITH_UNDERSCORES** for defining constants eg: const **PAGINATION_MAX_ROWS** = 15.

‎docs/javascript/variables.md‎

Lines changed: 55 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,55 @@
1+
---
2+
id: variables
3+
title: Variables
4+
sidebar_label: Variables
5+
---
6+
7+
#### The following convention should be followed for variable naming
8+
9+
* Variable names should be **noun** or **adjectives** and should be **camelCase**. e.g age, balance, employeeReport etc
10+
<!--JavaScript-->
11+
// good
12+
var firstName = 'John';
13+
14+
// bad
15+
var firstname = 'John';
16+
17+
// bad
18+
var first_name = 'John';
19+
20+
// bad
21+
var FIRSTNAME = 'John';
22+
23+
// bad
24+
var FIRST_NAME = 'John';
25+
26+
* **JavaScript variables are case sensitive**. Therefore, JavaScript variables with lowercase and uppercase characters are different
27+
<!--JavaScript-->
28+
var name = 'John';
29+
30+
var Name = 'William';
31+
32+
var NAME = 'Tech';
33+
34+
console.log(name);
35+
// "John"
36+
37+
console.log(Name);
38+
// "William"
39+
40+
console.log(NAME);
41+
// "Tech"
42+
43+
* Variable names should be short yet meaningful. The choice of a variable name should be mnemonic, self descriptive and semantical
44+
designed to indicate its intention.
45+
46+
* One-character variable names must be avoided like i, j, k, m etc
47+
48+
* Variables names should be declared as per their types
49+
* Map/KeyValue pair should be declared as *keyToValue* and *valueByKey*. For e.g **ageByName** or **nameToAge**.
50+
* Set can be prefixed as *unique* before variable names. For e.g **uniqueNames**
51+
* Boolean can be prefixed as **is/are/has** e.g. **isVisible**, **isEligible**, **hasMaximumAmount**
52+
53+
### Constants
54+
55+
Constants intended to be non-changing variables are UPPER_CASE separated by underscore. e.g **HOURS_IN_DAY**, **PAGINATION_MAX_ROWS**

0 commit comments

Comments
 (0)