action #7178
closeduse perlcritic to improve code quality
0%
Description
our code is quite approachable by a gentle perlcritic (perlcritic --gentle .):
we mostly overuse Subroutine prototypes (which are only meant to define new syntax and domain specific languages) and we only have a handful of simple to fix warnings beyond that.
a slightly stricter rub (perlcritic --stern .) gives a number of additional reasonable pointers how to improve the code, that would then take a tad longer, though
anything stricter than --stern merits an own configuration file, not all of them are reasonable for us.
I also propose to add perlcritic checks and perltidy checks to make check, as a sanity check before check-in.
Updated by froh about 9 years ago
After careful consideration I really vote for removing at least method function prototypes (with careful testing) because method function prototypes are useless:
Method calls are not influenced by prototypes either, because the function to be called is indeterminate at compile time, since the exact code called depends on inheritance.
Because the intent of this feature is primarily to let you define subroutines that work like built-in functions, here are prototypes for some other functions that parse almost exactly like the corresponding built-in.
I also vote for removing the testapi function prototypes (and other function, not method prototoypes), which however requires very careful testing, as we might inadvertently enforce some obscure parameter type coercion with the $ parameters prototypes we have.
Updated by coolo over 8 years ago
- Status changed from New to In Progress
- Assignee changed from froh to coolo
after reviewing how we use them - I agree
Updated by coolo over 8 years ago
- Status changed from In Progress to Resolved