NightOwl888 commented on issue #648:
URL: https://github.com/apache/lucenenet/issues/648#issuecomment-1279730960

   I have added some issues from the scans above, although, there is a lot in 
there and I could use some help reviewing and creating issues. Of course, if it 
is a change that would cause us to diverge greatly from the Java source, we 
don't want to do it. Some things that I noticed that we definitely **do not 
want to change**:
   
   1. `goto` statements / Refactor the containing loop to do more than one 
iteration - These are mostly workarounds for the lack of support for the 
[labeled continue 
statement](https://www.programiz.com/java-programming/continue-statement#labeled-continue)
 in .NET. This is the best way to keep the execution order the same in Java and 
.NET when stepping through the code.
   2. Cognitive Complexity - we want to remain in sync with Java Lucene here.
   3. Associated TODO - it is detecting the TODO statements from Lucene. All 
TODO statements that apply to Lucene.NET are marked with either `LUCENENET 
TODO:` or `LUCENE TO-DO`. If we can change the scan to look for those instead, 
it would be great. NOTE: A PR that would be accepted would be to change them 
all (except for the plain TODOs from Lucene) to be `LUCENENET TODO`.
   4. Remove this commented out code. - If the commented code existed in 
Lucene, we want to keep it. If not, please point it out so we can decide 
case-by-case.
   5. Rename class 'SOMEClass' to match pascal case naming rules, consider 
using 'SomeClass'. - We are generally better off using the original class names.
   6. Remove the unnecessary Boolean literal(s) - If these exist in Lucene, we 
should keep them.
   
   Some things we **can change**, but are not that critical:
   
   1. redundant jump statements (if they exist in Java) - The ones I noticed 
were just `return` statements at the end of a method. We can fix these, but we 
should comment them out in the source code and leave a `// LUCENENET:` comment 
after them why they were removed.
   2. unused private fields - These are in code that is auto-generated in Java 
(we don't have auto-generation setup yet in .NET). Again, we can fix them, but 
should comment out the unused field and leave a `// LUCENENET:` comment after 
them why they were removed.
   
   If you could adjust the scan to exclude the issues we don't want to change 
and the issues I have already opened so we can see what remains, that would be 
great.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to