-
Notifications
You must be signed in to change notification settings - Fork 11
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
Generate hlint default configuration #234
Conversation
Important Auto Review SkippedAuto reviews are limited to the following labels: CodeRabbit. Please add one of these labels to enable auto reviews. Please check the settings in the CodeRabbit UI or the To trigger a single review, invoke the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
I'm not opposed to silencing the warnings, but I do like seeing them because some code should certainly be refactored. Thoughts @gelisam @david-christiansen |
As someone without time to really work on this project, my opinion doesn't matter that much. But here it is: I think hlint is great, but many of its defaults are not so useful. In particular, it pushes for a very point free style, which is harder to work with in practice. If I were active on the project, I'd want to go in and enable the suggestions a few at a time, considering whether they actually help, rather than just turning it all on and believing what it says, but as I said, I'm not active right now! |
I was fine with #233 because the Klister project would benefit from more contributors, and applying hlint suggestions seemed like an easy and inoffensive way for someone new to the codebase to get their feet wet without having to spend a long time understanding how everything works. Now that @david-christiansen points out that hlint "pushes for a very point free style", which I agree is "harder to work with in practice", I am not so convinced that #233 is a good idea. @philderbeast if you want to contribute to the Klister project and you are looking for an easy ticket to start with, may I recommend looking at the good first issue label? |
Merging as per #233 (comment) |
See #233. This is the
.hlint.yaml
configuration generated byhlint --default . > .hlint.yaml
with stock comments removed.