Open iblislin opened 3 years ago
@barucden could you try out the style configure?
@barucden could you try out the style configure?
Sure. I tried running the commands locally, and one thing "bothers" me. It seems that the formater always splits the arguments of an invoked function into multiple lines. For example
- return ccall((:svm_train, libsvm), Ptr{SVMModel},
- (Ref{SVMProblem}, Ref{SVMParameter}),
- problem, param)
+ return ccall(
+ (:svm_train, libsvm),
+ Ptr{SVMModel},
+ (Ref{SVMProblem}, Ref{SVMParameter}),
+ problem,
+ param,
+ )
Perhaps it is not always necessary? Also notice the comma after the last argument.
Is it possible to allow only selected format adjustments? E.g., to adjust only spaces around =
and indentation, and leave the rest (such as splitting function arguments into multiple lines) to the contributors.
Is it possible to allow only selected format adjustments? E.g., to adjust only spaces around = and indentation, and leave the rest (such as splitting function arguments into multiple lines) to the contributors.
ATM, seems there isn't a config of enabling single rule only. The full list of configs is here: https://domluna.github.io/JuliaFormatter.jl/dev/api/#JuliaFormatter.format_text-Tuple{AbstractString}
I'm going the try out CustomStyle (https://domluna.github.io/JuliaFormatter.jl/dev/custom_styles/),
and check if we can ignore ccall
only or not.
I tried the YAS style. It does not split the argument list into multiple lines, which is nice. However, it is still difficult to set the appropriate row width. I personally try to keep each row 80 letters wide at most, except for the cases when I don't :) Sometimes I break this rule because it is just easier to read. I might be too conservative, but enforcing strictly defined formatting rules is perhaps unnecessarily inflexible.
How about just publishing a "style guide"? The YAS style, for instance, looks quite alright to me. The development here is not that wild after all :)
How about just publishing a "style guide"? The YAS style, for instance, looks quite alright to me. The development here is not that wild after all :)
hmm, seems it's the more suitable way at this moment. Let's pick YAS as the guideline for this repo. :+1: And yes, it's just a guideline, the rules can be broke if more readable.
Actually, the goal of formatter is to reduce the time spent on maintaining styles. I want a formatter that can remove whitespace automatically, so I can just accept PRs than let the bot do the rest of works. (I'm tired of sending some removing-space PR. :p).
I like your idea about enabling the only selected syntax transformation. I will try to work on that later if I have enough time bandwidth.
Yeah, if it could be configured to just fix white-spaces, that would be great!
Codecov Report
Continue to review full report at Codecov.