algorithm-archivists
Scripts to clean up AAA files
It would be great to have a set of scripts we can use to clean up some files in the AAA regularly.
- [x]
.editorconfiglanguages need to be sorted alphabetically - [x] languages in
book.jsonneed to be sorted alphabetically and indented properly - [ ] are there tabs in the AAA?
- [ ] do all language tags in the code import of the chapters match one in
book.json?
More ideas that we should probably discuss:
- [ ] script that runs linters with the
.editorconfigrules for some languages in bulk
I'll edit ideas in as they get discussed
script that runs linters with the .editorconfig rules for "all" languages in bulk
That would probably be a pain in the butt. We'd have to create linter configurations from templates for all sorts of different linters that get installed in different ways on different operating systems.
It would not be meant for users, just for us, we can run it once in a while. This way we wouldn't need to ask contributors to use spaces instead of tabs for example.
We can do that, but even then we should try to merge as clean and as good formatted PRs as possible.
Agreed. But some things fall through the cracks sometimes, I've merged code with tabs before because I hadn't noticed.
I agree with both points. We need to be more vigilant, but having a safety net is nice.
It would not be meant for users, just for us
I know. My comment still applies. Everyone of us would have to have a linter for every language installed. And on top of that we need to write linter configs for everything.
Or maybe we could have linters for the languages we use. I don't need to format JS code if you know how to do that, and I'll handle Haskell.
Then that would require every one of us to regularly run the tool. If I always make sure that indentation is correct, it's almost useless for me to run it. If someone forgets to check indentation every time, they're likely to forget to run the tool too. It would greatly reduce the tool's usefulness.
@jiegillet These scripts would then be executed by the user (or the reviewer) during the PR process, right? That’s way better then the general clean-up updates, since it wouldn’t have the issue @Butt4cak3 mentioned and it wouldn’t spam the commit history.
@Butt4cak3 it doesn’t hurt to have them tho. Maybe it catches something you as a reviewer miss. Humans aren’t perfect.
I had in mind scripts would do thing in batch, say look for every .cpp files and re-format them. We could run it every 6 months, or for every spring cleaning, or make it a Hacktoberfest contribution...
Of course those scripts would be in the AAA in tools or something, so users could run them too, I guess.
This is just a suggestion BTW, we don't have to do it ^^
And if you have other ideas, pitch in!
I mean... Go ahead. I'm not saying i don't like the idea. I'm usually the first one to notice wrong indentation, so it would be a welcome change. I'm just saying that it could be annoying to implement.
True, it might very hard/impossible to get right. But it could also be fun :)
It looks like the last discussion in this issued that was not handled in #506 is about the linters, which seems difficult to me. Where are we on that discussion?
Implementing linters is quite complex, because there can be a lot individual things involved - platform, IDE ... basically easiest solution is while doing PR check if it's made with required rules from code style.
I thought about linters in the past, which was one of the things I wanted CI for. Without having thought about it recently, I agree that we don't want to make everyone do it manually, or push hard that there must be a linter for every single language, etc. It would be incremental, things that can help reviewers if they exist, etc.
This should be a separate issue.
I'm all for the incremental change, I was thinking to implement a script for a Haskell linter and making it flexible enough so that other languages could use something similar. I'll need a bit of time.
I don't think it needs to be a separate issue.
We can also talk about other ideas to make our lives easier. For example, a script that checks which files have tabs in them, or a script that checks if the language in the code import matches the one in book.json, or whatever... Those could be helpful and under 30 lines. Any other ideas?
@jiegillet These scripts sounds like a good idea and could then be part of the standard PR review procedure.