You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Minor changes can be done directly by editing code on GitHub. GitHub automatically creates a temporary branch and
2
+
3
+
- Minor changes can be done directly by editing code on GitHub. GitHub automatically creates a temporary branch and
3
4
files a PR. This is only suitable for really small changes like: spelling fixes, variable name changes or error string
4
5
change etc. For larger commits, following steps are recommended.
5
-
* (Optional) If you want to discuss your implementation with the users of GoFr, use the GitHub discussions of this repo.
6
-
* Configure your editor to use goimport and golangci-lint on file changes. Any code which is not formatted using these
6
+
- (Optional) If you want to discuss your implementation with the users of GoFr, use the GitHub discussions of this repo.
7
+
- Configure your editor to use goimport and golangci-lint on file changes. Any code which is not formatted using these
7
8
tools, will fail on the pipeline.
8
-
* Contributors should begin working on an issue only after it has been assigned to them. To get an issue assigned, please comment on the GitHub thread
9
+
- Contributors should begin working on an issue only after it has been assigned to them. To get an issue assigned, please comment on the GitHub thread
9
10
and request assignment from a maintainer. This helps avoid duplicate or conflicting pull requests from multiple contributors.
10
-
* Issues labeled triage are not open for direct contributions. If you're interested in working on a triage issue, please reach out to the maintainers
11
-
to discuss it before proceeding in the Github thread.
11
+
- Issues labeled triage are not open for direct contributions. If you're interested in working on a triage issue, please reach out to the maintainers
12
+
to discuss it before proceeding in the Github thread.
12
13
<!-- spellchecker:off "favour" have to be ignored here -->
13
-
* We follow **American English** conventions in this project (e.g., *"favor"* instead of *"favour"*). Please keep this consistent across all code comments, documentation, etc.
14
+
- We follow **American English** conventions in this project (e.g., _"favor"_ instead of _"favour"_). Please keep this consistent across all code comments, documentation, etc.
14
15
<!-- spellchecker:on -->
15
-
* All code contributions should have associated tests and all new line additions should be covered in those testcases.
16
+
- All code contributions should have associated tests and all new line additions should be covered in those testcases.
16
17
No PR should ever decrease the overall code coverage.
17
-
* Once your code changes are done along with the testcases, submit a PR to development branch. Please note that all PRs
18
+
- Once your code changes are done along with the testcases, submit a PR to development branch. Please note that all PRs
18
19
are merged from feature branches to development first.
20
+
19
21
* PR should be raised only when development is complete and the code is ready for review. This approach helps reduce the number of open pull requests and facilitates a more efficient review process for the team.
20
22
* All PRs need to be reviewed by at least 2 GoFr developers. They might reach out to you for any clarification.
21
23
* Thank you for your contribution. :)
@@ -28,32 +30,28 @@ Testing is a crucial aspect of software development, and adherence to these guid
28
30
29
31
1.**Test Types:**
30
32
31
-
- Write unit tests for every new function or method.
32
-
- Include integration tests for any major feature added.
33
-
34
-
35
-
2.**Test Coverage:**
36
-
37
-
- No new code should decrease the existing code coverage for the packages and files.
38
-
> The `code-climate` coverage check will not pass if there is any decrease in the test-coverage before and after any new PR is submitted.
33
+
- Write unit tests for every new function or method.
34
+
- Include integration tests for any major feature added.
39
35
36
+
2.**Test Coverage:**
40
37
38
+
- No new code should decrease the existing code coverage for the packages and files.
39
+
> The `code-climate` coverage check will not pass if there is any decrease in the test-coverage before and after any new PR is submitted.
41
40
42
41
3.**Naming Conventions:**
43
42
44
-
- Prefix unit test functions with `Test`.
45
-
- Use clear and descriptive names.
43
+
- Prefix unit test functions with `Test`.
44
+
- Use clear and descriptive names.
45
+
46
46
```go
47
47
funcTestFunctionName(t *testing.T) {
48
48
// Test logic
49
49
}
50
50
```
51
51
52
-
53
-
54
52
4.**Table-Driven Tests:**
55
53
56
-
-Consider using table-driven tests for testing multiple scenarios.
54
+
- Consider using table-driven tests for testing multiple scenarios.
57
55
58
56
> [!NOTE]
59
57
> Some services will be required to pass the entire test suite. We recommend using docker for running those services.
@@ -96,53 +94,52 @@ docker run -d --name arangodb \
96
94
-e ARANGO_ROOT_PASSWORD=rootpassword \
97
95
--pull always \
98
96
arangodb:latest
99
-
<<<<<<< HEAD
100
97
docker run -d --name db -p 8091-8096:8091-8096 -p 11210-11211:11210-11211 couchbase
docker run -d --name oracle-free -p 1521:1521 -e ORACLE_PWD=YourPasswordHere container-registry.oracle.com/database/free:latest
105
-
>>>>>>> origin
101
+
docker run -it --rm -p 4443:4443 -e STORAGE_EMULATOR_HOST=0.0.0.0:4443 fsouza/fake-gcs-server:latest
106
102
```
107
103
108
104
> [!NOTE]
109
105
> Please note that the recommended local port for the services are different from the actual ports. This is done to avoid conflict with the local installation on developer machines. This method also allows a developer to work on multiple projects which uses the same services but bound on different ports. One can choose to change the port for these services. Just remember to add the same in configs/.local.env, if you decide to do that.
110
106
111
-
112
107
### Coding Guidelines
113
-
* Use only what is given to you as part of function parameter or receiver. No globals. Inject all dependencies including
108
+
109
+
- Use only what is given to you as part of function parameter or receiver. No globals. Inject all dependencies including
114
110
DB, Logger etc.
115
-
* No magic. So, no init. In a large project, it becomes difficult to track which package is doing what at the
111
+
- No magic. So, no init. In a large project, it becomes difficult to track which package is doing what at the
116
112
initialization step.
117
-
* Exported functions must have an associated godoc.
118
-
* Sensitive data(username, password, keys) should not be pushed. Always use environment variables.
119
-
* Take interfaces and return concrete types.
120
-
- Lean interfaces - take 'exactly' what you need, not more. Onus of interface definition is on the package who is
121
-
using it. so, it should be as lean as possible. This makes it easier to test.
122
-
- Be careful of type assertions in this context. If you take an interface and type assert to a type - then it's
123
-
similar to taking concrete type.
124
-
* Uses of context:
125
-
- We should use context as a first parameter.
126
-
- Can not use string as a key for the context. Define your own type and provide context accessor method to avoid
127
-
conflict.
128
-
* External Library uses:
129
-
- A little copying is better than a little dependency.
130
-
- All external dependencies should go through the same careful consideration, we would have done to our own written
131
-
code. We need to test the functionality we are going to use from an external library, as sometimes library
132
-
implementation may change.
133
-
- All dependencies must be abstracted as an interface. This will make it easier to switch libraries at later point
134
-
of time.
135
-
* Version tagging as per Semantic versioning (https://semver.org/)
113
+
- Exported functions must have an associated godoc.
114
+
- Sensitive data(username, password, keys) should not be pushed. Always use environment variables.
115
+
- Take interfaces and return concrete types.
116
+
- Lean interfaces - take 'exactly' what you need, not more. Onus of interface definition is on the package who is
117
+
using it. so, it should be as lean as possible. This makes it easier to test.
118
+
- Be careful of type assertions in this context. If you take an interface and type assert to a type - then it's
119
+
similar to taking concrete type.
120
+
- Uses of context:
121
+
- We should use context as a first parameter.
122
+
- Can not use string as a key for the context. Define your own type and provide context accessor method to avoid
123
+
conflict.
124
+
- External Library uses:
125
+
- A little copying is better than a little dependency.
126
+
- All external dependencies should go through the same careful consideration, we would have done to our own written
127
+
code. We need to test the functionality we are going to use from an external library, as sometimes library
128
+
implementation may change.
129
+
- All dependencies must be abstracted as an interface. This will make it easier to switch libraries at later point
130
+
of time.
131
+
- Version tagging as per Semantic versioning (https://semver.org/)
136
132
137
133
### Documentation
138
-
* After adding or modifying existing code, update the documentation too - [development/docs](https://github.com/gofr-dev/gofr/tree/development/docs).
139
-
* When you consider a new documentation page is needed, start by adding a new file and writing your new documentation. Then - add a reference to it in [navigation.js](https://gofr.dev/docs/navigation.js).
140
-
* If needed, update or add proper code examples for your changes.
141
-
* In case images are needed, add it to [docs/public](./docs/public) folder.
142
-
* Make sure you don't break existing links and references.
143
-
* Maintain Markdown standards, you can read more [here](https://www.markdownguide.org/basic-syntax/), this includes:
144
-
- Headings (`#`, `##`, etc.) should be placed in order.
145
-
- Use trailing white space or the <br> HTML tag at the end of the line.
146
-
- Use "`" sign to add single line code and "```" to add multi-line code block.
147
-
- Use relative references to images (in `public` folder as mentioned above.)
148
-
* The [gofr.dev documentation](https://gofr.dev/docs) site is updated upon push to `/docs` path in the repo. Verify your changes are live after next GoFr version.
134
+
135
+
- After adding or modifying existing code, update the documentation too - [development/docs](https://github.com/gofr-dev/gofr/tree/development/docs).
136
+
- When you consider a new documentation page is needed, start by adding a new file and writing your new documentation. Then - add a reference to it in [navigation.js](https://gofr.dev/docs/navigation.js).
137
+
- If needed, update or add proper code examples for your changes.
138
+
- In case images are needed, add it to [docs/public](./docs/public) folder.
139
+
- Make sure you don't break existing links and references.
140
+
- Maintain Markdown standards, you can read more [here](https://www.markdownguide.org/basic-syntax/), this includes:
141
+
- Headings (`#`, `##`, etc.) should be placed in order.
142
+
- Use trailing white space or the <br> HTML tag at the end of the line.
143
+
- Use "`" sign to add single line code and "```" to add multi-line code block.
144
+
- Use relative references to images (in `public` folder as mentioned above.)
145
+
- The [gofr.dev documentation](https://gofr.dev/docs) site is updated upon push to `/docs` path in the repo. Verify your changes are live after next GoFr version.
0 commit comments