Open gww-certik opened 2 years ago
Why don't you separate those analysis? For example:
find src \
-name "*.js" \
-o -name "*.ts" \
-o -name "*.php" \
-o -name "*.bash" \
| xargs scc
find test-e2e test-unit \
-name "*.js" \
-o -name "*.py" \
-o -name "*.ts" \
-o -name "*.php" \
-o -name "*.bash" \
| xargs scc
Furthermore --count-tests
seems quite under-specified: there might be various project layouts and naming conventions.
Maybe *test*
pattern can refer to test code hierarchy or a feature module of unit test framework, statistical library etc. in the name of a directory.
In Rust tests are in same file , usually between :
#[cfg(test)]
mod tests {
...
}
https://doc.rust-lang.org/stable/rust-by-example/testing/unit_testing.html
In Rust tests are in same file , usually between :
Wow. Great. :thinking: Is it a legacy code? Is there any chance to use integration tests instead of private testing of private code? https://doc.rust-lang.org/stable/rust-by-example/testing/integration_testing.html
NOTE: I am not familiar with Rust at all.
Putting tests on bottom of files is Rust idiomatic. So tests are close to code they relate to and easier to keep up to date.
On Sat, 27 Nov 2021, 11:02 Csongor T. G., @.***> wrote:
In Rust tests are in same file , usually between :
Wow. Great. 🤔 Is it a legacy code? Is there any chance to use integration tests instead of private testing of private code?
https://doc.rust-lang.org/stable/rust-by-example/testing/integration_testing.html
NOTE: I am not familiar with Rust at all.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boyter/scc/issues/305#issuecomment-980534421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWLS4N4PUZXPRSQRX37GJXLUOCUEBANCNFSM5IX2IEVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Been thinking about this. I think it might be best served by what I was planning on doing eventually and have custom parsers for the more common file types. The reason being the languages.json works well for generic languages, but some such as Java, C, PHP, Python, Rust etc... could get some performance gains out of a specific parser for them.
In addition it would allow for some modifications such as this.
Now where I can see this being problematic is how it gets reported, as it would mean either reporting 2 lines in the output per language where this happens, or via adding a new column.
Consider the following,
$ scc --by-file
───────────────────────────────────────────────────────────────────────────────
Language Files Lines Blanks Comments Code Complexity
───────────────────────────────────────────────────────────────────────────────
Go 53 9510 1370 809 7331 1358
───────────────────────────────────────────────────────────────────────────────
service/search.go 1061 142 134 785 159
data/models/code.go 736 72 13 651 71
service/search_test.go 434 8 0 426 2
service/background_cloner.go 431 73 45 313 92
index/caisson_test.go 420 75 25 320 63
Knowing where to put the new format is a problem there. Say I put the tests into service/search.go
where should the test count go? I don't think another column is appropriate since tests can have blank lines or comments as well, but a new row is problematic too because where do the counts go? It also makes sorting a bit painful but thats not a huge issue.
Tokei might have the answer because it checks some language types for other languages and reports on them such as this,
$ tokei
===============================================================================
Language Files Lines Code Comments Blanks
===============================================================================
HTML 37 2021 1737 15 269
|- JavaScript 2 366 295 13 58
(Total) 2387 2032 28 327
Which is a possibility although I am not sold on it. Its the best I can think of at the moment though.
There is one more aspect to it.
If I count statistics, I would like to know how many lines are there of : code & comments in code; tests & comments in tests;
On Mon, Nov 29, 2021 at 2:23 AM Ben Boyter @.***> wrote:
Been thinking about this. I think it might be best served by what I was planning on doing eventually and have custom parsers for the more common file types. The reason being the languages.json works well for generic languages, but some such as Java, C, PHP, Python, Rust etc... could get some performance gains out of a specific parser for them.
In addition it would allow for some modifications such as this.
Now where I can see this being problematic is how it gets reported, as it would mean either reporting 2 lines in the output per language where this happens, or via adding a new column.
Consider the following,
$ scc --by-file ─────────────────────────────────────────────────────────────────────────────── Language Files Lines Blanks Comments Code Complexity ─────────────────────────────────────────────────────────────────────────────── Go 53 9510 1370 809 7331 1358 ─────────────────────────────────────────────────────────────────────────────── service/search.go 1061 142 134 785 159 data/models/code.go 736 72 13 651 71 service/search_test.go 434 8 0 426 2 service/background_cloner.go 431 73 45 313 92 index/caisson_test.go 420 75 25 320 63
Knowing where to put the new format is a problem there. Say I put the tests into service/search.go where should the test count go? I don't think another column is appropriate since tests can have blank lines or comments as well, but a new row is problematic too because where do the counts go? It also makes sorting a bit painful but thats not a huge issue.
Tokei might have the answer because it checks some language types for other languages and reports on them such as this,
$ tokei
Language Files Lines Code Comments Blanks
HTML 37 2021 1737 15 269 |- JavaScript 2 366 295 13 58 (Total) 2387 2032 28 327
Which is a possibility although I am not sold on it. Its the best I can think of at the moment though.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/boyter/scc/issues/305#issuecomment-981213029, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWLS4NYSPJZJCO5JUE2UP2TUOLI2JANCNFSM5IX2IEVQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
I just added the ability to exclude based on filename patterns, so for go you could exclude tests using the below
scc -n _test.go
You can also supply multiple
scc -n _test.go,main.go
The above would not count any main.go files or files containing _test.go.
Added because I needed it. But I thought it might be useful for this case as well. You will need to build off master to get this but if you are in a bind it might help.
So far I could not find any tool that supports ignoring Rust test code so I am upvoting this.
Feature request: ability to count (maybe via optional flag
--count-tests
) lines of code that belong to tests.