aeson
aeson copied to clipboard
Use auto-formatting (hindent?)
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?
If we can autocheck hindent in Travis, than why not. There was something I didn't liked in hindent style, but OTOH the style debate won't never converge to consensus anyway. IIRC hindent formatting is diff friendly, which is most important for me anyway.
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:
- Ensure that your project has at least one open-source licence. (we've decided to not define the term "open-source" and it is left to your own interpretation).
- Ensure that the issue tracker for your project is publicly accessible.
- Create a new issue in your issue tracker and clearly describe the task. Also mention the difficulty level (easy/medium/hard/tedious), either as a tag/label or somewhere in the title/description.
- If you have specific requirements for contributors (e.g., copyright waiver), it must be mentioned in the description of the task (preferably with a link to CONTRIBUTING.md).
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:
- Run hindent on the entire code base
- Add a formatting step to the
Makefile - Add a Travis CI step to
.travis.ymlandtravis/script.shthat verifies formatting. See if there's a binary available for download, otherwise install withstack install hindent --resolver nightly - Replace style guide in
CONTRIBUTING.mdwith a reference to hindent
Additional/optional tasks:
- Are there any configuration options for hindent we should decide on?
- There are alternative formatters like
hfmtandbrittany, are any of them worth considering?
@bergmark Currently it is not possible to use hindent with certain files using the CPP language extension. Would it be OK to skip those files in the formatting while this known bug is fixed?
If it is acceptable I can take on this task
@lorenzo related: https://github.com/bos/aeson/issues/529
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 https://github.com/commercialhaskell/hindent/issues/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 (hindent, fourmulo and stylish-haskell) and all of them have problems with syntax forms that are interrupted by CPP directives, e.g. the module header in src/Data/Aeson/Internal/ByteString.hs:
module Data.Aeson.Internal.ByteString (
mkBS,
withBS,
#ifdef MIN_VERSION_template_haskell
liftSBS,
#endif
) where
or tests in tests/PropertyGeneric.hs:
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
]
]
So in order to use any of these formatters these cases would probably have to be eliminated. I also encountered problems with hindent and Template Haskell, but haven't tested if they are present for the other formatters. If you think it would be cool to have automatic formatting let me know and I can investigate some more and create a PR that restructures the code where necessary and applies the formatting :)
have to be eliminated.
The compatibility CPP is unfortunately a MUST for a library like aeson. I'm not aware you can cheaply eliminate it without sacrificing something (like support window width, which is not an option).
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.
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.
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).