Skip to content

Commit 48631cc

Browse files
UserBugUserBug
committed
Clean up version number
1 parent c9967b5 commit 48631cc

19 files changed

+2934
-2
lines changed

‎.editorconfig

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
[*]
2+
indent_style = space
3+
indent_size = 4

‎.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
.idea

‎README.md

Lines changed: 26 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,26 @@
1-
# code_guide
2-
Coding Standards and Best practics
1+
# Code Guide for Web Development in JS stack
2+
This guide contains a set of guidelines for developers.
3+
The purpose of which is to identify common patterns of bad coding
4+
and suggest a better approach.
5+
6+
### v2 - Current version
7+
[Code Guide - v2](https://github.com/UserBug/codeGuide/tree/v2)
8+
9+
### v1
10+
11+
* [Git](https://github.com/UserBug/codeGuide/blob/v1/docs/git.md)
12+
* [Naming convention](https://github.com/UserBug/codeGuide/blob/v1/docs/namingConvention.md)
13+
* [Files](https://github.com/UserBug/codeGuide/blob/v1/docs/files.md)
14+
* [Common JavaScript](https://github.com/UserBug/codeGuide/blob/v1/docs/javaScript.md)
15+
* [React](https://github.com/UserBug/codeGuide/blob/v1/docs/react.md)
16+
* [React Hooks](https://github.com/UserBug/codeGuide/blob/v1/docs/reactHooks.md)
17+
* [React Component testing](https://github.com/UserBug/codeGuide/blob/v1/docs/reactComponentTesting.md)
18+
* [Styles](https://github.com/UserBug/codeGuide/blob/v1/docs/styles.md)
19+
* [Split Code](https://github.com/UserBug/codeGuide/blob/v1/docs/splitCode/index.md)
20+
21+
Tools:
22+
* [ESLint Playground](
23+
https://eslint.org/play/#eyJ0ZXh0IjoiXG4iLCJvcHRpb25zIjp7InBhcnNlck9wdGlvbnMiOnsiZWNtYVZlcnNpb24iOiJsYXRlc3QiLCJzb3VyY2VUeXBlIjoic2NyaXB0IiwiZWNtYUZlYXR1cmVzIjp7fX0sInJ1bGVzIjp7fSwiZW52Ijp7ImVzNiI6dHJ1ZX19fQ==
24+
)
25+
---
26+
Copyright © 2017 Stanislav Kochenkov

‎docs/files.md

Lines changed: 157 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,157 @@
1+
## Files
2+
3+
### Support only case sensitive path.
4+
5+
According to the naming convention, register is an extremely important part of the name.
6+
For example, "User" is a class, and "user" is an instance of the class "User."
7+
8+
```javascript
9+
// Two absolutely correct imports that can exist in one file.
10+
import Documents from './components/Documents';
11+
import documents from './components/documents';
12+
```
13+
14+
The lack of sensitivity to the register leads to uncertainty of imports
15+
and the inability to correctly support the launch of projects on Unix.
16+
17+
---
18+
19+
### Separate entities by files
20+
21+
If your logic requires more than 400 lines of code, it's time to think about splitting it into a couple of files.
22+
For example: move all constants to file "constants.js", move large functions to separate files, move validations.
23+
24+
Benefits:
25+
26+
* The less code the easier it is to understand it.
27+
* Files with clear names make it easy to navigate the project.
28+
* Separation of code into small entities makes it easier to write unit tests.
29+
* Conflicts in small files are easier to resolve when merging into a git.
30+
* It's easier to split code into modules.
31+
32+
---
33+
34+
### Self described file names
35+
36+
All files and folders should have names that describe content.
37+
38+
✔ For example:
39+
40+
* If the file contains a list of constants which is exported, use the name "constants.js".
41+
* If there is some helper function which is exported by default, the file should have a name like the name of this
42+
function ("someHelperToDoCalculations.js").
43+
* File which export by default JS Class should be named as this Class with the first letter in uppercase. “MyClass.js”
44+
45+
❌ Don't use common words like:
46+
47+
* "module" (use name of this module),
48+
* "hoc" (use name of React class),
49+
* "middleware" (use type of middleware or what it do)
50+
51+
```json
52+
"unicorn/filename-case": [
53+
"error",
54+
{
55+
"cases": {
56+
"camelCase": true,
57+
"pascalCase": true
58+
}
59+
}
60+
]
61+
```
62+
63+
[eslint-plugin-unicorn - filename-case](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/filename-case.md)
64+
[eslint-plugin-unicorn - no-empty-file](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/no-empty-file.md)
65+
66+
---
67+
68+
### Group files by modules and not by type - Screaming Architecture
69+
70+
Much more often it is necessary to modify one particular module than all files with constants in the project. Therefore:
71+
72+
* It makes it easier to find all the files associated with the module.
73+
* Repeatedly simplifies the replacement/modification of structure in the module.
74+
* Each module becomes independent, and can be implemented using a different architecture that better meets the
75+
requirements.
76+
77+
[Screaming Architecture - Uncle Bob](https://blog.cleancoder.com/uncle-bob/2011/09/30/Screaming-Architecture.html)
78+
79+
##### ❌ BAD
80+
81+
```
82+
root
83+
components
84+
grid
85+
button
86+
input
87+
constants
88+
grid
89+
button
90+
input
91+
reducers
92+
grid
93+
button
94+
input
95+
```
96+
97+
##### ✔ GOOD
98+
99+
```
100+
root
101+
grid
102+
component
103+
constants
104+
reducer
105+
button
106+
component
107+
constants
108+
reducer
109+
input
110+
component
111+
constants
112+
reducer
113+
```
114+
115+
---
116+
117+
### Don't use file extension “.jsx”.
118+
119+
For example, we have 2 files in the "lib" folder: "MyClass.jsx" and "MyClass.js".
120+
After compilation both of these files become "MyClass.js", which can lead to errors when using this file in the code.
121+
It is just one of many examples...
122+
**Summary**: JSX is not required anymore.
123+
[Facebook issue](https://github.com/facebook/create-react-app/issues/87)
124+
125+
---
126+
127+
### Separate exports
128+
129+
If the file contains many independent entities, export them independently.
130+
This will allow the collector to make the TreeShacking and reduce the size of the final file.
131+
132+
##### ❌ BAD
133+
134+
```javascript
135+
const myFunction = () => {
136+
};
137+
const mysomeConst = 3;
138+
const config = {};
139+
140+
export default {
141+
myFunction,
142+
mysomeConst,
143+
config,
144+
};
145+
```
146+
147+
##### ✔ GOOD
148+
149+
```javascript
150+
export const myFunction = () => {
151+
};
152+
export const mysomeConst = 3;
153+
export const config = {};
154+
```
155+
156+
---
157+
Copyright © 2017 Stanislav Kochenkov

‎docs/git.md

Lines changed: 115 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,115 @@
1+
## Git
2+
3+
### Basic Foundation
4+
5+
Any branching strategies or approaches adopted in the repository should extend from the Basic Foundation:
6+
7+
#### Commit often and push frequently
8+
9+
* Help roll back to a specific good point in time
10+
* Helps share work to: test, get feedback, identify dependencies.
11+
* Provides context
12+
[GitLab - Commit often and push frequently](https://docs.gitlab.com/ee/topics/gitlab_flow.html#commit-often-and-push-frequently)
13+
14+
#### Feature branch serves the developer.
15+
16+
* It can contain any raw and not ready-made code
17+
* It is not stable and can be changed or deleted by the developer at any time
18+
* Internal commits should primarily help the developer.
19+
20+
#### Pull request is a confirmation from the developer that everything is ready.
21+
22+
* Acceptance criteria met
23+
* Definition of Done met
24+
* Tests completed successfully
25+
* The developer is ready to receive feedback from the reviewers
26+
27+
#### The main branch of the project should always be tested and stable
28+
29+
---
30+
31+
### Recommended branching strategies:
32+
33+
* [GitLab Flow](https://docs.gitlab.com/ee/topics/gitlab_flow.html)
34+
* [Git Flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow)
35+
* [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow)
36+
37+
---
38+
39+
### Feature branch recommendations
40+
41+
* Should have a short life.
42+
* Should contain only one Feature.
43+
* Should represent changes from one and only one developer.
44+
* Should frequently pull changes from main branch.
45+
* Should squash all commits before merged into main branch.
46+
* Should be removed after they are merged into main branch.
47+
48+
---
49+
50+
### Any name of feature branch should start with ticket id
51+
52+
Availability of ticket id in name of the feature branch,
53+
allows people and issue tracking systems (JIRA) find and show valid links to the branch in Git repo.
54+
The best way to do this - is to create a branch for development directly from issue tracking systems.
55+
Examples of branch names: ```OOPP-76-some-feature```, ```EX-2391-some-feature```...
56+
57+
---
58+
59+
### Any git commit message should start with ticket id
60+
61+
If there is a ticket id in the comment name, it will be displayed on the page of ticket in issue tracking system.
62+
Most modern editors allow you to do this automatically, or you can add git pre commit hook:
63+
[Automatically Prepend a Jira Issue ID to Git Commit](https://gist.github.com/robatron/01b9a1061e1e8b35d270)
64+
65+
Pay attention, since all individual commits will be merged with squash,
66+
the commit text is not important. The developer himself decides which text is convenient for him.
67+
Example of commit: ```[OOR-76] add some component```
68+
69+
---
70+
71+
### Recommended workflow for Task
72+
73+
1. The task is taken for development in the current iteration.
74+
2. __Developer__ creates a feature branch through issue tracking systems (JIRA) from develop branch.
75+
3. __Developer__ writes the code and unit tests only in the feature branch.
76+
4. __Developer__ merges all new changes from develop branch into his feature branch and resolve all conflicts.
77+
5. __Developer__ do smoke testing.
78+
6. __Developer__ create in Pull Request to develop branch, and add at least one __Reviewer__.
79+
7. __Developer__ informs the __Reviewer__ that Pull Request is pending approval for feature branch.
80+
8. __Tester__ checks all acceptance criteria for the task,
81+
and performs integration testing of the features.
82+
Launches automated tests.
83+
9. __Reviewer__ looks through the code and with the help of comments in the Pull Request can leave comments on improving
84+
the code.
85+
The __Reviewer__ informs the __Developer__ that the review is complete.
86+
If necessary, __Developer__ makes edits and returns to step #3
87+
10. __Developer__ merges feature branch into the development branch and squash commits.
88+
11. __Tester__ creates a task to complete automated end-to-end testing and performs it in an independent workflow.
89+
(Steps #7 and #8 can be executed in parallel or reversed.)
90+
91+
### Recommended workflow for Integration
92+
93+
It is recommended to use the integration branch
94+
if the work involves the development of changes by several developers in parallel
95+
and its release together.
96+
97+
1. Tasks are accepted for development in the current iteration and distributed among the developers.
98+
2. __Lead__ creates an integration branch from the development branch.
99+
3. __Developer__ creates a feature branch through issue tracking systems (JIRA) from __integration__ branch.
100+
4. __Developer__ perform regular "workflow for Task" in feature branch.
101+
5. __Lead__ merges all new changes from develop branch into iteration branch and resolve all conflicts.
102+
6. __Developer__ merges all new changes from iteration branch into his feature branch and resolve all conflicts.
103+
7. __Lead__ create in Pull Request to develop branch, and add at least one __Reviewer__.
104+
8. __Lead__ informs the __Reviewer__ that Pull Request is pending approval for integration branch.
105+
9. __Tester__ checks all acceptance criteria for the task,
106+
and performs integration testing of the features.
107+
Launches automated tests.
108+
10. __Reviewer__ looks through the code and with the help of comments in the Pull Request can leave comments on
109+
improving the code.
110+
The __Reviewer__ informs the __Lead__ that the review is complete.
111+
If necessary, __Lead__ makes edits and returns to step #3
112+
11. __Lead__ merges iteration branch into the development branch WITHOUT squash commits.
113+
114+
---
115+
Copyright © 2017 Stanislav Kochenkov

0 commit comments

Comments
 (0)