Feature #3703
implement TRPL based linting support
0%
Related issues
History
#1 Updated by Greg Shah almost 8 years ago
Add reports for "lint" to the standard reports for FWD Analytics.
The key thing here is having a pretty comprehensive list of items on which to report.
Examples:
- Keyword abbreviations.
- Field/Table/Database name abbreviations.
- Unqualified field or table names.
- Variables that are UNDO.
- Shared variable usage.
- Standalone expressions that have no side effects.
- References to a default frame.
- Queries without indexes.
- Indexes that aren't referenced.
- Fields that aren't referenced.
- Tables that aren't referenced.
- Platform-specific code.
- Transactions that span multiple program files.
- Locks that outlive transactions.
- Runtime preprocessor arguments.
- Dynamic code generation.
- Other code that can't work in an r-code (compiled) application.
- Parsing/preprocessing quirks.
- Runtime quirks that can be predicted from static code analysis.
- Coding standards.
This is not a complete list. I just jotted down some stuff that came to mind. We already have some of these built. Please post your own ideas to this task to save them.
We can review the Prolint tool (which is open source) and see if there are useful ideas (see their list of rules). Please note that the prolint approach will be missing the more advanced things that we can calculate since they are using a pretty weak AST (as compared to our more rich AST). When you add the deeper analysis of our annotations phase, there is so much that we can exploit which prolint cannot provide. But prolint may show some ideas for reports that are more basic. If they are useful we can create our own version. Their actual code is useless to us but the concepts could be useful.
#2 Updated by Greg Shah 9 months ago
- Subject changed from add lint reports to implement TRPL based linting support
Although my initial idea was to implement these as reports, it is likely that the reporting/analytics will migrate into our IDE support. This set of linting features is best exposed there too. Optimally, developers would be able to:
- individually choose (enable/disable) from an extensive list, which lint rules should be active
- add their own rules
I expect the rules to be written in TRPL. Each rule should be its own rule-set (not just a single expression). This allows more complicated calculations.
#3 Updated by Greg Shah 9 months ago
- Related to Feature #10700: expose analytics features in our IDE support added
#4 Updated by Greg Shah 9 months ago
- Related to Feature #10726: calculate and report code quality metrics added