You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm going to guess from the answer to #406 that this is probably a similar situation, but I thought I'd ask anyway.
When getting into a large existing codebase, it's often interesting to find code that matches certain strings or regexps, such as deprecated identifiers, superseded typedefs, fragile functions, etc. It would be helpful if cloc could count such things. They might be specified as one or more --count-match options, which would cause generation of additional summary columns for the number of lines matching each of the specified regexps. This would be useful both for the summary counts and the per-file output.
If the code is structured like the How It Works section describes, this seems like something that would be reasonably straightforward to do at the end of step 5.iv, provided there's a convenient way to push the match options down into that processing and to have additional fields in the line count data structure.
The text was updated successfully, but these errors were encountered:
--include-content=<regex> will only count files whose contents match the regex. If nothing else, combined with --by-file, cloc will identify such files but won't count the number of instances where the regex is matched.
Then again, isn't grep, possibly with xargs and find, the tool for this job?
I'm going to guess from the answer to #406 that this is probably a similar situation, but I thought I'd ask anyway.
When getting into a large existing codebase, it's often interesting to find code that matches certain strings or regexps, such as deprecated identifiers, superseded typedefs, fragile functions, etc. It would be helpful if cloc could count such things. They might be specified as one or more --count-match options, which would cause generation of additional summary columns for the number of lines matching each of the specified regexps. This would be useful both for the summary counts and the per-file output.
If the code is structured like the How It Works section describes, this seems like something that would be reasonably straightforward to do at the end of step 5.iv, provided there's a convenient way to push the match options down into that processing and to have additional fields in the line count data structure.
The text was updated successfully, but these errors were encountered: