I propose we re-evaluate and streamline the linter rules across Django repositories—especially edx-platform—to enhance code quality while significantly reducing developer frustration and time loss.
Key Issues:
Overwhelming and Unclear Rules:
The current linter setup includes too many rules with unclear guidelines, leading to confusing error messages.
Developers often spend excessive time trying to decipher and fix these issues, sometimes triggering additional errors in the process.
Integration Challenges:
The complexity of our development environments (e.g., docker setups, devstack, tutor) makes it difficult to integrate linter feedback directly into code editors, exacerbating the problem.
Recommendations:
Simplify and Consolidate:
Reduce the number of linter rules to focus on high-impact areas like maintainability, readability, and bug reduction.
Adopt a single, consistent linter to avoid conflicting or redundant rules.
Evaluate actual maintainability problems in the codebase - e.g. functions with high cyclomatic complexity - and make that the guideline for choosing linter rules
Enhance Integration and Automation:
Improve integration with code editors to display linter feedback immediately and understandably.
Automate routine tasks (such as import reordering via isort in CI) to reduce manual effort.
This approach aims to uphold high coding standards while streamlining the development process and reducing unnecessary time spent on resolving linter errors.
Do you (or others) have any specific examples to share?
Agreed that this is a big annoyance compared to other codebases I work on where the linters run as you type.
Another big problem with pylint is that it’s incredibly slow, whether integrated into your editor or not. What do you think about making a big push to replace pylint entirely with ruff? I think doing so could address your other concerns at the same time, as it has fewer rules than pylint anyways.
I think migrating to ruff would be a big improvement.
Aside from the points you mention, it will be a huge relief that it has better formatting capabilities. Where in JavaScript we tend to use prettier, with ruff we can have it sort out most of the stylistic problems automatically.
I know that migration is not super easy and may take a while, but I’m sure we can take our time with this.
I don’t have a good example for the linter problems where you fix one thing and your fix just breaks something different.
However this PR is a good indication of how much time linter fixes can take, looking at the number of commits that just fix lint issues.
@jesperhodge I’d say you should start with a proof of concept. Pick a repo, and simplify its lint rules or (ideally) replace pylint with ruff, then open that as a PR and get buy-in from people. If there’s enough buy-in, you can make an update to the relevant OEP then once approved, put out a call for people to help with the transition.