defp deps do
[
{:green, ">= 0.1.3", only: :dev}
]
end
Add the following to .formatter.exs:
plugins: [Green.Lexmag.ElixirStyleGuideFormatter]
Configuration
While Green aims to work with no configuration, there will be cases where a little is needed.
Specifically, Green sometimes needs help in recognising function (and macro) calls that shouldn’t be pipelined. One example is assert/1, which isn’t part of the default :locals_without_parens configuration. To avoid assert foo(1) being turned into 1 |> foo() |> assert(), add this to .formatter.exs:
I guess you can easily consider it as outdated. I would recommend to rewrite it in this way:
# Bad
sentence
|> String.split(~r/\s/)
|> (fn words -> [@sentence_start | words] end).()
|> Enum.join(" ")
# Good
sentence
|> String.split(~r/\s/)
|> then(&[@sentence_start | &1])
|> Enum.join(" ")
Enforce predicate functions to end with a question mark (N3),
That should be easy as long as you require the @spec, simply remove prefix is_ and add ? suffix if such character is not already at the end of the function name.
This is handled by the Elixir formatter. It moves the comment after the expression to above said expression.
Put the expression being tested by comparison on the left side (U1)
I would not implement this. I’m not sure if it’s too far. However it should be easy to implement assuming “standardised” describe block naming:
describe "foo/1" do
test ":default works as same as in foo/0" do
# Bad
assert MyApp.foo() == MyApp.foo(:default)
# Good
assert MyApp.foo(:default) == MyApp.foo()
end
end
I think that superfluous comment != inline comment. That item means to not add pointless comments.
I wish I could add inline comments without the formatter ruining it for me… I’m sure there’s a way, I just hate that I would have to go out of my way to do it.
“Trust me”, except obvious SPAM there is no such thing like “pointless comments”. It’s not about comments, but few times I was asked to make code more readable for people who don’t know Elixir language. When doing so I have realised what kind of naming is used in different communities and I think that the last task I want to see in the issue board is a task like that.
Depends what kind of naming we deal with. Please keep in mind that such naming is recommended not only by someone’s style guide, but also by official documentation and in that case I don’t mind as long as it would not produce false positives.
You guys have been debating the comment rule but in fairness to the OP his docs explicitly marked that particular rule as being impossible to implement because it’s subjective.
I think what the rule is getting at is that new programmers can sometimes fall into a habit of over-commenting every line, even what it’s obvious what the code does. Everyone posting in this thread is probably experienced enough to have learned not to do that long ago
Appreciate the effort, but is there a way for the user to define their own rules?
For instance, I personally dislike a number of “standard” formatting practices and have my own way of formatting such cases.
Also, I would never let a formatter transform my functions calls into piped calls or the other way around b/c I use both of them purposefully. In my view, code formatting should mirror the intent and that’s how it should be used.
is there a way for the user to define their own rules?
Not yet. The priority is implementing existing, widely-used, rule sets.
I’m intending to allow the definition of custom rule sets eventually — i.e. which rules to activate — but it’s lower priority as I’m trying to help the push towards more standardization and less configuration.
I really like it!
One small concern: I haven’t tested it yet, but if your algo forces use to be closer to the module’s headline, it’s not a safe behavior, because resulting code sometimes depends of the macro call placement
Don’t use anonymous functions in pipelines (
