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

Compatibility with formatter(s) #14

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ Note that lines containing only comments are not considered empty lines.
- Do not explicitly name type variables in method signatures when unary `<:` or `>:` would suffice.
- Type variable bindings should always be enclosed within `{}` brackets when using `where` syntax, e.g. `Vector{Vector{T} where T}` is good, `Vector{Vector{T}} where {T}` is good, `Vector{Vector{T}} where T` is bad.
- A decimal should never be the last character in numeric literals (e.g. `1.` is bad, `1.0` is good).
- Use `in` instead of `=` when specifying `for` statement iteration variables (e.g. `for i = 1:5` is bad, `for i in 1:5` is good).
- Use `in` instead of `=` when specifying `for` statement except possibly for iteration variables (i.e. `for i = 1:5`).
- If a field type annotation in a struct definition would default to `Any`, explicitly annotate the field with `::Any`.
- In argument lists, always separate positional arguments from keyword arguments using a semicolon (`;`).
- In method signatures, only provide names to arguments that are actually referenced in the method body (e.g. `f(x::Number, y) = y` is bad, `f(::Number, y) = y` is good).
Expand Down