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
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+38-22
Original file line number
Diff line number
Diff line change
@@ -5,23 +5,32 @@ Following these guidelines will reduce friction and improve the speed at which y
5
5
6
6
## Bug reports
7
7
8
-
If you notice code that crashes, is incorrect, or is too slow, please file a bug report. The report should be raised as a github issue with a minimal working example that reproduces the condition.
8
+
If you notice code that crashes, is incorrect, or is too slow, please file a bug report. The report should be raised as a GitHub issue with a minimal working example that reproduces the condition.
9
9
The example should include any data needed. If the problem is incorrectness, then please post the correct result along with an incorrect result.
10
10
11
11
Please include version numbers of all relevant libraries and Julia itself.
12
12
13
13
## Development guidelines
14
14
15
-
- Correctness is a necessary requirement; efficiency is desirable. Once you have a correct implementation, make a Pull Request (PR) so we can help improve performance.
16
-
- PRs should contain one logical enhancement to the codebase.
17
-
- Squash commits in a PR.
18
-
- If you want to introduce a new feature, open an issue to discuss a feature before you start coding (this maximizes the likelihood of patch acceptance).
19
-
- Minimize dependencies on external packages, and avoid introducing new dependencies that would increase the compilation time by a lot.
15
+
Here are a few principles to keep in mind when writing a Pull Request (PR).
16
+
17
+
### Correctness
18
+
19
+
- Correctness is a necessary requirement. Add tests to make sure that any new function displays the right behavior.
20
+
- Since Graphs.jl supports multiple implementations of the graph data structure using the `AbstractGraph`[type](https://juliagraphs.github.io/Graphs.jl/latest/types.html#AbstractGraph-Type-1), you should refrain from using the internal fields of structs such as `fadjlist`. Instead, you should use the functions provided in the API. Code that is instrumental to defining a concrete graph type can use the internal structure of that type.
20
21
- Put type assertions on all function arguments where conflict may arise (use abstract types, `Union`, or `Any` if necessary).
21
-
- If the algorithm was presented in a paper, include a reference to the paper (_e.g._, a proper academic citation along with an eprint link).
22
22
- Take steps to ensure that code works correctly and efficiently on edge cases (disconnected graphs, empty graphs, ...).
23
23
- We can accept code that does not work for directed graphs as long as it comes with an explanation of what it would take to make it work for directed graphs.
24
-
- Prefer the short circuiting conditional over `if`/`else` when convenient, and where state is not explicitly being mutated (*e.g.*, `condition && error("message")` is good; `condition && i += 1` is not).
24
+
25
+
### Style
26
+
27
+
- Write your code using Invenia's [BlueStyle](https://github.com/invenia/BlueStyle)
28
+
- Format it with [JuliaFormatter](https://github.com/domluna/JuliaFormatter.jl) before pushing
29
+
30
+
### Efficiency
31
+
32
+
- Once you have a correct implementation, make a PR so we can help improve performance.
33
+
- Minimize dependencies on external packages, and avoid introducing new dependencies that would increase the compilation time by a lot.
25
34
- Write code to reuse memory wherever possible. For example:
26
35
27
36
```julia
@@ -34,7 +43,9 @@ function f(g, v)
34
43
returnsum(storage)
35
44
end
36
45
```
46
+
37
47
should be rewritten as two functions
48
+
38
49
```julia
39
50
functionf(g::AbstractGraph, v::Integer)
40
51
storage =Vector{Int}(undef, nv(g))
@@ -49,45 +60,50 @@ function f!(g::AbstractGraph, v::Integer, storage::AbstractVector{Int})
49
60
returnsum(storage)
50
61
end
51
62
```
63
+
52
64
This gives users the option of reusing memory and improving performance.
53
65
54
-
### Minimizing use of internal struct fields
66
+
### Misc
55
67
56
-
Since Graphs supports multiple implementations of the graph data structure using the `AbstractGraph`[type](https://juliagraphs.github.io/Graphs.jl/latest/types.html#AbstractGraph-Type-1), you should refrain from using the internal fields of structs such as `fadjlist`. Instead, you should use the functions provided in the API.
57
-
Code that is instrumental to defining a concrete graph type can use the internal structure of that type.
68
+
- If the algorithm was presented in a paper, include a reference to the paper (_e.g._, a proper academic citation along with an eprint link).
58
69
59
-
## Git usage
70
+
## Git(Hub) usage
60
71
61
72
### Getting started on a package contribution
62
73
63
-
In order to make it easier for you to contribute and review Pull Requests (PRs),
64
-
it would be better to be familiar with git fundamentals.
65
-
74
+
In order to make it easier for you to contribute and review PRs, it would be better to be familiar with Git fundamentals.
66
75
Most importantly:
76
+
67
77
- clone the repository from JuliaGraphs/Graphs.jl
68
-
- fork the repository on your own github account
78
+
- fork the repository on your own GitHub account
69
79
- make the modification to the repository, test and document all your changes
70
80
- push to the fork you created
71
81
- open a PR.
72
82
73
83
See the [JuMP documentation](https://jump.dev/JuMP.jl/dev/developers/contributing/) for a more detailed guide.
74
84
75
-
### Advanced: visualize opened PRs locally:
85
+
### PR hygiene
86
+
87
+
- PRs should contain one logical enhancement to the codebase.
88
+
- Squash commits in a PR.
89
+
- If you want to introduce a new feature, open an issue to discuss a feature before you start coding (this maximizes the likelihood of patch acceptance).
90
+
91
+
### Advanced: visualize opened PRs locally
76
92
77
-
In order to make it easier for you to review Pull Requests (PRs), you can add this to your git config file, which should be located at `PACKAGE_LOCATION/.git/config`, where `PACKAGE_LOCATION` is where the Graphs.jl was cloned.
93
+
In order to make it easier for you to review PRs, you can add this to your git config file, which should be located at `PACKAGE_LOCATION/.git/config`, where `PACKAGE_LOCATION` is where the Graphs.jl was cloned.
78
94
If you added the package with the `] dev` command, it is likely at `$HOME/.julia/dev/Graphs`.
79
95
80
96
These instructions were taken from [this gist](https://gist.github.com/piscisaureus/3342247).
81
97
82
-
Locate the section for your github remote in the `.git/config` file. It looks like this:
98
+
Locate the section for your GitHub remote in the `.git/config` file. It looks like this:
Now add the line `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*` to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
106
+
Now add the line `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*` to this section. Obviously, change the GitHub URL to match your project's URL. It ends up looking like this:
91
107
92
108
```
93
109
[remote "origin"]
@@ -96,7 +112,7 @@ Now add the line `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*` to this se
0 commit comments