4 ms·
I am the main author for a static analysis tool for a dynamic language on the JVM. My tool also has many rules that could be considered controversial, some rule
by HamletDRC3 15y ago
I am the main author for a static analysis tool for a dynamic language on the JVM. My tool also has many rules that could be considered controversial, some rules that conflict with each other, and (I hope) many rules that are genuinely useful. Our message has always been: configure the ruleset based on the coding guidelines that you want for your project. There is no one ruleset to rule them all.
I, myself, have written many rules that I personally would never apply to my own codebase, but perhaps someone else might. My belief is that the world can benefit from static analysis tools and that adoption will be faster if we focus on providing as many rules as possible even if some are (in my opinion) questionable.
So CSS-Lint can be configured to only enforce the rules you want. If a user can find 5-10 rules that they like, then it seems like a good idea to start using the tool, especially if the team is larger and less highly skilled. But it seems petty to me to lambast a project just because you disagree with the name. Yes the intent of CSS-Lint is something different than base Lint, but I can say from experience that people looking for static analysis tools often google for "css lint" or "java lint" before understanding that Lint is a product and Static Analysis is the general term.
To summarize: CSS-Lint is just a name and the product is aggressively marketed. That doesn't mean it can't be useful.
- kitsaws 15y ago+1 for this comment For all static (heck, even runtime) analysis tools, I would rather have more rules than less - and disable the ones I don't like/want/agree with. I wrote the code, I set the standard for rules, it's that simple.