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
Use auto-formatting (hindent?) #527
Comments
If we can autocheck |
Hi there! Is this issue still relevant? If so, would any of the maintainers be interested in providing some mentorship/general help on resolving this so that the newcomers and first-time contributors would have an easier time? I would like to add this as one of the issues for the upcoming Haskell Weekly's Call for Participation section. See discussion in #75. These are the guidelines we'd like to stick to in the future:
Thank you! |
Hi @alexeyzab, We're always happy to provide help with contributions. I think this would be a good beginner-level task as it shouldn't modify behavior of the library. I think we satisfy all of your guidelines. Let me know if I'm missing something. TODO list:
Additional/optional tasks:
|
@bergmark Currently it is not possible to use hindent with certain files using the If it is acceptable I can take on this task |
Re. the travis step, is it possible to have it not break the build? I'm not sure if we want to force contributors to install hindent. I could do the formatting before making a release instead. |
Yes, it is possible |
There are important bugs that need to be fixed in hindent before this is done. This one is very serious mihaimaruseac/hindent#433 |
Alright, thanks for looking into this @lorenzo! |
Hi, I'd like to try and push this forward as first issue. I tried three formatters (
or tests in
So in order to use any of these formatters these cases would probably have to be eliminated. I also encountered problems with |
The compatibility CPP is unfortunately a MUST for a library like |
I think the idea is not to get rid of CPP altogether, but to rewrite the CPP so that the chosen formatter can handle it, or make some feature requests to the formatter. |
The genericTests :: TestTree
genericTests =
testGroup "generic" [
testGroup "toJSON" [
testGroup "Nullary" [ ... ]
...
#if !MIN_VERSION_base(4,16,0)
, testGroup "OptionField" [
testProperty "like Maybe" $
\x -> gOptionFieldToJSON (OptionField (Option x)) === thMaybeFieldToJSON (MaybeField x)
, testProperty "roundTrip" (toParseJSON gOptionFieldParseJSON gOptionFieldToJSON)
]
#endif
]
] is the code which should work. I don't want to compromise on a way the code is structured now. I'm not unhappy because of current (inconsistent) formatting, and I'm not so happy with outputs of any formatter that I'd like to sacrifice more than just looking at their ugly outputs. |
Point taken.
This is exactly what I meant but I see that you have a coding style you would like to stick to. I will check for another issue to tackle (open for suggestions). |
I think auto-formatting is a big win. hindent also formats very close to what I do personally anyway so I'm a big fan, but there are a lot of differences from the aeson style.
What do others think?
The text was updated successfully, but these errors were encountered: