Feature/LOC #1987
Feature/LOC #1987
Conversation
|
I should note that this resolved issue #591. |
|
I would personally prefer if all the methods mentioning LOC would have it expanded to LinesOfCode. |
| @@ -272,7 +274,7 @@ public void run() { | |||
|
|
|||
| @SuppressWarnings("PMD.CollapsibleIfStatements") | |||
| private void initialize() throws IOException { | |||
| synchronized (this) { | |||
There was a problem hiding this comment.
does this make any difference?
There was a problem hiding this comment.
Just that synchronizing on public objects is suspect as it breaks encapsulation — so I revised it.
| @@ -805,7 +805,7 @@ private boolean accept(File file) { | |||
| return !RuntimeEnvironment.getInstance().isIndexVersionedFilesOnly(); | |||
| } | |||
|
|
|||
| boolean accept(File parent, File file) { | |||
| private boolean accept(File parent, File file) { | |||
There was a problem hiding this comment.
is this relevant? or just a cleanup?
I was motivated to have it quite terse for the methods that are used in analyzers, since I had to edit hundreds of lines in them. Moreover since LOC is almost orthogonal to the bulk of logic in the xrefers, I wanted a tiny function name — I do think "LOC" is well-known enough acronym in source code analysis; if analyzers are ever updated to support logical lines-of-code, then "LLOC" also will be well-known. |
|
Excellent feature!!! |
|
@idodeclare pls use 'fixes #591' in one the commit comments then. |
That is certainly feasible in the future. Right now, only files have document data in the Lucene index. To store aggregated num-lines and LOC, it will be necessary to store Lucene data for directories — but without conflicting with the existing queries that all assume only file-level data. One straight-forward idea would be to add Lucene "documents" for directories with wholly-separate fields so that these new documents never appear in current queries. Of course it would also be necessary to write an aggregator that runs at the appropriate stages. |
|
This also brings a question about how to use these counts for restricting
searches.
Dne 26. 1. 2018 5:10 odp. napsal uživatel "C Fraire" <
notifications@github.com>:
… Will all the total lines and slocs be aggregated at repository root level ?
That is certainly feasible in the future. Right now, only files have
document data in the Lucene index. To store aggregated num-lines and LOC,
it will be necessary to store Lucene data for directories — but without
conflicting with the existing queries that all assume only file-level data.
One straight-forward idea would be to add Lucene "documents" for
directories with wholly-separate fields so that these new documents never
appear in current queries. Of course it would also be necessary to write an
aggregator that runs at the appropriate stages.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1987 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACzGDNoySlziaA8OuXLnX7uKUe2F05q5ks5tOfkBgaJpZM4RtMrk>
.
|
Yes, indeed. Relatedly, I did not update to show the counts in search results, as I did not have any idea how best to present them. |
|
I am merging this as is, thank you Chris, it looks good |
|
Thanks, @tarzanek ! |
|
I wonder how this will cope with incremental indexing. Will pre-existing files have LOC set to 0 ? Or is full reindex required ? |
|
Pre-existing documents will have blank LOC/#Lines — the same as for files which do not get an xref (e.g. Incrementally re-indexed files can get LOC/#Lines. Full re-index is required for completeness. |
Hello,
Please consider for integration this patch to count per-file physical lines-of-code (LOC;
Wiki) and to store LOC and total number of lines.
DirectoryListingis updated to present the counts while browsing.Thank you.