From ffb70144085158a0b1dc6113764330226e02ab2a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1ll=20Haraldsson?= Date: Wed, 11 Sep 2019 09:39:28 +0000 Subject: [PATCH] Compatibility with formatter(s) Yes, you're more strict than Julia's style guide, that has this line: for i = firstindex(a):lastindex(a) uur guide and Karpinski's reasoning here: https://github.com/domluna/JuliaFormatter.jl/issues/34 I'm not sure I agree, but it's not good if the formatter generates style incompatible with guide(s). Your guide was updated in 2018 to reflect JuMP's but I at least didn't locate wording on this (yet) there. --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index a020343..3ef2be0 100644 --- a/README.md +++ b/README.md @@ -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).