Open includesec-erik opened 3 months ago
It's an interesting idea but will take some thought to implement cleanly. At the moment cloc uses per-language filters to define what's a comment. Possibly the filter concept could be extended to additionally identify flavors (ie client or server). I'll need to think on this.
A common differentiation in many languages is between test-files and non-test-files. If cloc
is going to be modified to allow differentiation for some categories, then testing is an obvious target. For some languages this would be trivial to detect using the filename alone. Typescript test files typically end in .test.ts
or .spec.ts
. Golang test files typically end in _test.go
.
~Aerek
I'm liking this idea increasingly more. Before I start work on it though I need to tackle the long overdue feature of tracking git file renames (#765, #800). So it will be a while.
There are likely other languages/frameworks, but the client-side/server-side paradigm with JS/TS is the most common place this use case is present.
Server-side Express: Looking for
require('express');
would signal a NodeJS/Express server-side component.Current cloc....
New cloc....
Client-side NextJS: For situations such NextJS 13 and later (released Oct 2022), would it make sense for cloc to differentiate the kind of code similar to the example output below?
Current cloc...
New cloc....
Concluding thoughts on this feature's potential.... Pro: Differentiates between client-side and server-side code, those who are counting code would be more aware of the code in the code base and what the composition of it is as a counted item
Con: May have false positives due to other JS frameworks doing their silly things and having collisions with keywords used in Express and NodeJS.
Consideration point: Make it an optional feature to maximize the pro and minimize the con?
If determining the composition and context of the code cloc is counting is outside of the purpose of the tool, no worries, but wanted to bring this idea up as a quick search of past enhancements on github issues didn't mention anything like this concept.