Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Uniform code style #190

Merged
merged 11 commits into from
Nov 21, 2022
1 change: 1 addition & 0 deletions .JuliaFormatter.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
style = "blue"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BlueStyle seems like the most well-established specification, whereas SciML is more recent. However JuliaFormatter cannot do it all, so we must tell contributors to adhere to the style guidelines in general. Should we add a badge to the README too?

Copy link
Member

@simonschoelly simonschoelly Nov 20, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason to prefer BlueStyle? (I am not yet familiar with these styles). We could also specify our own rules right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In any cases, most of the changes here seem to be sensible.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just use it because it's already well documented, so we can point contributors to the exhaustive specification by Invenia. We could make up our own rules but that would require explaining them to everyone in our docs.

Also, it's easier to contribute when you're already familiar with the style guide, which wouldn't be the case for Graphs-specific rules.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My hot take is that the precise choice of style does not matter, as long as it's clear and easy to apply, and BlueStyle satisfies both criteria

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it makes sense to use some common style, as then people don't need to reconfigure their editor differently for every project.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the default format by JuliaFormatter? Would that also be an option?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default format by JuliaFormatter is much less well-specified than BlueStyle. One of the perks of BlueStyle is that it also gives coherent writing advice to the contributors that cannot be enfored by a simple linter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe it makes sense to use some common style, as then people don't need to reconfigure their editor differently for every project.

Another perk of JuliaFormatter is that the formatting in the Julia extension for VSCode is based on it. And it takes into account the .JuliaFormatter.toml file at the root of the package to format each file according to the local specification (in our case style = "blue")

60 changes: 38 additions & 22 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,23 +5,32 @@ Following these guidelines will reduce friction and improve the speed at which y

## Bug reports

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.
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.
The example should include any data needed. If the problem is incorrectness, then please post the correct result along with an incorrect result.

Please include version numbers of all relevant libraries and Julia itself.

## Development guidelines

- 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.
- PRs should contain one logical enhancement to the codebase.
- Squash commits in a PR.
- 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).
- Minimize dependencies on external packages, and avoid introducing new dependencies that would increase the compilation time by a lot.
Here are a few principles to keep in mind when writing a Pull Request (PR).

### Correctness

- Correctness is a necessary requirement. Add tests to make sure that any new function displays the right behavior.
- 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.
- Put type assertions on all function arguments where conflict may arise (use abstract types, `Union`, or `Any` if necessary).
- 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).
- Take steps to ensure that code works correctly and efficiently on edge cases (disconnected graphs, empty graphs, ...).
- 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.
- 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).

### Style

- Write your code using Invenia's [BlueStyle](https://github.com/invenia/BlueStyle)
- Format it with [JuliaFormatter](https://github.com/domluna/JuliaFormatter.jl) before pushing

### Efficiency

- Once you have a correct implementation, make a PR so we can help improve performance.
- Minimize dependencies on external packages, and avoid introducing new dependencies that would increase the compilation time by a lot.
- Write code to reuse memory wherever possible. For example:

```julia
Expand All @@ -34,7 +43,9 @@ function f(g, v)
return sum(storage)
end
```

should be rewritten as two functions

```julia
function f(g::AbstractGraph, v::Integer)
storage = Vector{Int}(undef, nv(g))
Expand All @@ -49,45 +60,50 @@ function f!(g::AbstractGraph, v::Integer, storage::AbstractVector{Int})
return sum(storage)
end
```

This gives users the option of reusing memory and improving performance.

### Minimizing use of internal struct fields
### Misc

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.
Code that is instrumental to defining a concrete graph type can use the internal structure of that type.
- 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).

## Git usage
## Git(Hub) usage

### Getting started on a package contribution

In order to make it easier for you to contribute and review Pull Requests (PRs),
it would be better to be familiar with git fundamentals.

In order to make it easier for you to contribute and review PRs, it would be better to be familiar with Git fundamentals.
Most importantly:

- clone the repository from JuliaGraphs/Graphs.jl
- fork the repository on your own github account
- fork the repository on your own GitHub account
- make the modification to the repository, test and document all your changes
- push to the fork you created
- open a PR.

See the [JuMP documentation](https://jump.dev/JuMP.jl/dev/developers/contributing/) for a more detailed guide.

### Advanced: visualize opened PRs locally:
### PR hygiene

- PRs should contain one logical enhancement to the codebase.
- Squash commits in a PR.
- 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).

### Advanced: visualize opened PRs locally

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.
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.
If you added the package with the `] dev` command, it is likely at `$HOME/.julia/dev/Graphs`.

These instructions were taken from [this gist](https://gist.github.com/piscisaureus/3342247).

Locate the section for your github remote in the `.git/config` file. It looks like this:
Locate the section for your GitHub remote in the `.git/config` file. It looks like this:

```
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = [email protected]:JuliaGraphs/Graphs.jl.git
```

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:
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:

```
[remote "origin"]
Expand All @@ -96,7 +112,7 @@ Now add the line `fetch = +refs/pull/*/head:refs/remotes/origin/pr/*` to this se
fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
```

Now fetch all the pull requests:
Now fetch all the PRs:

```
$ git fetch origin
Expand All @@ -108,7 +124,7 @@ From github.com:JuliaGraphs/Graphs.jl
...
```

To check out a particular pull request:
To check out a particular PR:

```
$ git checkout pr/999
Expand Down
9 changes: 8 additions & 1 deletion Project.toml
Original file line number Diff line number Diff line change
Expand Up @@ -16,18 +16,25 @@ SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
Statistics = "10745b16-79ce-11e8-11f9-7d13ad32a3b2"

[compat]
Aqua = "0.5"
ArnoldiMethod = "0.1, 0.2"
Compat = "3.40, 4"
DataStructures = "0.17, 0.18"
Documenter = "0.27"
Inflate = "0.1.3"
JuliaFormatter = "1"
SimpleTraits = "0.9"
StableRNGs = "1"
julia = "1.6"

[extras]
Aqua = "4c88cf16-eb10-579e-8560-4a9242c79595"
Base64 = "2a0f44e3-6c83-55bd-87e4-b1978d98bd5f"
DelimitedFiles = "8bb1440f-4735-579b-a4ab-409b98df4dab"
Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
JuliaFormatter = "98e50ef6-434e-11e9-1051-2b60c6c9e899"
StableRNGs = "860ef19b-820b-49d6-a774-d7a799459cd3"
Test = "8dfed614-e22c-5e08-85e1-65c5234f0b40"

[targets]
test = ["Base64", "DelimitedFiles", "StableRNGs", "Test"]
test = ["Aqua", "Base64", "DelimitedFiles", "Documenter", "JuliaFormatter", "StableRNGs", "Test"]
5 changes: 4 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,9 @@
# Graphs.jl

[![Build Status](https://github.com/JuliaGraphs/Graphs.jl/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/JuliaGraphs/Graphs.jl/actions/workflows/ci.yml?query=branch%3Amaster) [![codecov.io](http://codecov.io/github/JuliaGraphs/Graphs.jl/coverage.svg?branch=master)](http://codecov.io/github/JuliaGraphs/Graphs.jl?branch=master) [![](https://img.shields.io/badge/docs-latest-blue.svg)](https://juliagraphs.org/Graphs.jl/dev/)
[![Documentation](https://img.shields.io/badge/docs-latest-blue.svg)](https://juliagraphs.org/Graphs.jl/dev/)
[![Build status](https://github.com/JuliaGraphs/Graphs.jl/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/JuliaGraphs/Graphs.jl/actions/workflows/ci.yml?query=branch%3Amaster)
[![Code coverage](http://codecov.io/github/JuliaGraphs/Graphs.jl/coverage.svg?branch=master)](http://codecov.io/github/JuliaGraphs/Graphs.jl?branch=master)
[![Code style: Blue](https://img.shields.io/badge/code%20style-blue-4495d1.svg)](https://github.com/invenia/BlueStyle)

## Overview

Expand Down
14 changes: 5 additions & 9 deletions benchmark/benchmarks.jl
Original file line number Diff line number Diff line change
@@ -1,22 +1,18 @@
using BenchmarkTools
using Graphs


DIGRAPHS = Dict{String,DiGraph}(
"complete100" => complete_digraph(100),
"path500" => path_digraph(500)
"complete100" => complete_digraph(100), "path500" => path_digraph(500)
)

GRAPHS = Dict{String,Graph}(
"complete100" => complete_graph(100),
"tutte" => smallgraph(:tutte),
"path500" => path_graph(500)
"complete100" => complete_graph(100),
"tutte" => smallgraph(:tutte),
"path500" => path_graph(500),
)


suite = BenchmarkGroup()
include("core.jl")


tune!(suite);
results = run(suite, verbose = true, seconds = 10)
results = run(suite; verbose=true, seconds=10)
46 changes: 23 additions & 23 deletions benchmark/centrality.jl
Original file line number Diff line number Diff line change
@@ -1,26 +1,26 @@

@benchgroup "centrality" begin
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): degree" Graphs.degree_centrality($g)
@bench "$(name): closeness" Graphs.closeness_centrality($g)
if nv(g) < 1000
@bench "$(name): betweenness" Graphs.betweenness_centrality($g)
@bench "$(name): katz" Graphs.katz_centrality($g)
end
end
end #graphs
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): degree" Graphs.degree_centrality($g)
@bench "$(name): closeness" Graphs.closeness_centrality($g)
if nv(g) < 1000
@bench "$(name): betweenness" Graphs.betweenness_centrality($g)
@bench "$(name): katz" Graphs.katz_centrality($g)
end
if nv(g) < 500
@bench "$(name): pagerank" Graphs.pagerank($g)
end
end
end # digraphs
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): degree" Graphs.degree_centrality($g)
@bench "$(name): closeness" Graphs.closeness_centrality($g)
if nv(g) < 1000
@bench "$(name): betweenness" Graphs.betweenness_centrality($g)
@bench "$(name): katz" Graphs.katz_centrality($g)
end
end
end # graphs
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): degree" Graphs.degree_centrality($g)
@bench "$(name): closeness" Graphs.closeness_centrality($g)
if nv(g) < 1000
@bench "$(name): betweenness" Graphs.betweenness_centrality($g)
@bench "$(name): katz" Graphs.katz_centrality($g)
end
if nv(g) < 500
@bench "$(name): pagerank" Graphs.pagerank($g)
end
end
end # digraphs
end # centrality
22 changes: 12 additions & 10 deletions benchmark/connectivity.jl
Original file line number Diff line number Diff line change
@@ -1,12 +1,14 @@
@benchgroup "connectivity" begin
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): strongly_connected_components" Graphs.strongly_connected_components($g)
end
end # digraphs
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): connected_components" Graphs.connected_components($g)
end
end # graphs
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): strongly_connected_components" Graphs.strongly_connected_components(
$g
)
end
end # digraphs
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): connected_components" Graphs.connected_components($g)
end
end # graphs
end # connectivity
13 changes: 6 additions & 7 deletions benchmark/core.jl
Original file line number Diff line number Diff line change
@@ -1,10 +1,9 @@
suite["core"] = BenchmarkGroup(["nv", "edges", "has_edge"])


# nv
suite["core"]["nv"] = BenchmarkGroup(["graphs", "digraphs"])
suite["core"]["nv"]["graphs"] = @benchmarkable [nv(g) for (n,g) in $GRAPHS]
suite["core"]["nv"]["digraphs"] = @benchmarkable [nv(g) for (n,g) in $DIGRAPHS]
suite["core"]["nv"]["graphs"] = @benchmarkable [nv(g) for (n, g) in $GRAPHS]
suite["core"]["nv"]["digraphs"] = @benchmarkable [nv(g) for (n, g) in $DIGRAPHS]

# iterate edges
function iter_edges(g::AbstractGraph)
Expand All @@ -16,8 +15,8 @@ function iter_edges(g::AbstractGraph)
end

suite["core"]["edges"] = BenchmarkGroup(["graphs", "digraphs"])
suite["core"]["edges"]["graphs"] = @benchmarkable [iter_edges(g) for (n,g) in $GRAPHS]
suite["core"]["edges"]["digraphs"] = @benchmarkable [iter_edges(g) for (n,g) in $DIGRAPHS]
suite["core"]["edges"]["graphs"] = @benchmarkable [iter_edges(g) for (n, g) in $GRAPHS]
suite["core"]["edges"]["digraphs"] = @benchmarkable [iter_edges(g) for (n, g) in $DIGRAPHS]

# has edge
function all_has_edge(g::AbstractGraph)
Expand All @@ -34,5 +33,5 @@ function all_has_edge(g::AbstractGraph)
end

suite["core"]["has_edge"] = BenchmarkGroup(["graphs", "digraphs"])
suite["core"]["has_edge"]["graphs"] = @benchmark [all_has_edge(g) for (n,g) in $GRAPHS]
suite["core"]["has_edge"]["digraphs"] = @benchmark [all_has_edge(g) for (n,g) in $DIGRAPHS]
suite["core"]["has_edge"]["graphs"] = @benchmark [all_has_edge(g) for (n, g) in $GRAPHS]
suite["core"]["has_edge"]["digraphs"] = @benchmark [all_has_edge(g) for (n, g) in $DIGRAPHS]
10 changes: 5 additions & 5 deletions benchmark/edges.jl
Original file line number Diff line number Diff line change
Expand Up @@ -32,9 +32,9 @@ end

n = 10000
@benchgroup "edges" begin
@bench "$(n): fille" fille($n)
@bench "$(n): fillp" fillp($n)
a, b = fille(n), fillp(n)
@bench "$(n): tsume" tsum($a)
@bench "$(n): tsump" tsum($b)
@bench "$(n): fille" fille($n)
@bench "$(n): fillp" fillp($n)
a, b = fille(n), fillp(n)
@bench "$(n): tsume" tsum($a)
@bench "$(n): tsump" tsum($b)
end # edges
4 changes: 2 additions & 2 deletions benchmark/insertions.jl
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
@benchgroup "insertions" begin
n = 10000
@bench "ER Generation" g = SimpleGraph($n, 16 * $n)
n = 10000
@bench "ER Generation" g = SimpleGraph($n, 16 * $n)
end
5 changes: 2 additions & 3 deletions benchmark/parallel/egonets.jl
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,6 @@ using BenchmarkTools
return a
end


function mapvertices(f, g::Graph)
n = nv(g)
a = zeros(Int, n)
Expand All @@ -43,13 +42,13 @@ using BenchmarkTools

function comparison(f, g)
println("Mulithreaded on $(Threads.nthreads())")
b1 = @benchmark mapvertices($f, $g)
b1 = @benchmark mapvertices($f, $g)
println(b1)

println("singlethreaded")
b2 = @benchmark mapvertices_single($f, $g)
println(b2)
println("done")
return println("done")
end

nv_ = 10000
Expand Down
24 changes: 12 additions & 12 deletions benchmark/traversals.jl
Original file line number Diff line number Diff line change
@@ -1,14 +1,14 @@
@benchgroup "traversals" begin
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): bfs_tree" Graphs.bfs_tree($g, 1)
@bench "$(name): dfs_tree" Graphs.dfs_tree($g, 1)
end
end # graphs
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): bfs_tree" Graphs.bfs_tree($g, 1)
@bench "$(name): dfs_tree" Graphs.dfs_tree($g, 1)
end
end # digraphs
@benchgroup "graphs" begin
for (name, g) in GRAPHS
@bench "$(name): bfs_tree" Graphs.bfs_tree($g, 1)
@bench "$(name): dfs_tree" Graphs.dfs_tree($g, 1)
end
end # graphs
@benchgroup "digraphs" begin
for (name, g) in DIGRAPHS
@bench "$(name): bfs_tree" Graphs.bfs_tree($g, 1)
@bench "$(name): dfs_tree" Graphs.dfs_tree($g, 1)
end
end # digraphs
end # traversals
Loading