lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From NightOwl888 <...@git.apache.org>
Subject [GitHub] lucenenet issue #174: Ported over Lucene.Net.Spatial
Date Wed, 05 Oct 2016 11:05:57 GMT
Github user NightOwl888 commented on the issue:

    https://github.com/apache/lucenenet/pull/174
  
    @eladmarg 
    
    There are a couple of snags that could make that idea difficult:
    
    1. Whitespace differences (different number of tabs/spaces, different line break chars,
etc)
    2. Different code formatting
    
    Beyond Compare is great because it gives you the ability to ignore whitespace and even
code comments. I am not sure if it has an API that can be utilized, though.
    
    Let's say version 1 in Java has this function signature:
    
    ```java
    public int Foo(string arg1, string arg2, string arg3, string arg4, string arg5, string
arg6, string arg7)
    {
        return doSomething(string arg1, string arg2, string arg3, string arg4, string arg5,
string arg6, string arg7);
    }
    ```
    
    Then for version 2, someone decided the code format should change to:
    
    ```java
    public int Foo(string arg1, string arg2, 
        string arg3, string arg4, 
        string arg5, string arg6, string arg7)
    {
        return doSomething(string arg1, string arg2, 
            string arg3, string arg4, 
            string arg5, string arg6, string arg7);
    }
    ```
    
    If your diff tool isn't smart enough to understand code formatting, it will see this as
a new function even though it is functionally equivalent.
    
    Most diff tools are only smart enough to work line by line. That is why I like Beyond
Compare because it can at least tell you *which characters* on the line changed and ignore
trivial things such as tabs and spaces. Unfortunately, it isn't smart enough to detect code
formatting changes, though (which would have cut about half of the time off of the BoboBrowse.Net
port) - or maybe it is and I haven't found the setting for it... The main issue there was
that someone decided that all of the opening curly braces `{` should be on the same line as
the function header instead of the line after.
    
    I am not saying this is something that can't (or shouldn't) be automated, but to ensure
it works properly you should make the tool smart enough to know when two different formats
of the same Java code are functionally identical - otherwise you have copied a lot of useless
code into the .NET part that will need a lot of manual cleanup.
    
    Of course, then there is also the matter of having the tool figure out *where* in the
.NET code it should insert the function, since we will have completely different file headers
and the functions will probably have different bodies, possibly different method accessibility,
slightly different parameter types, different code formatting, possibly different function
names, Java getters and setters that were made into .NET properties, etc.
    
    If it just spit out the diffs into a new directory of files that could then be manually
copied/ported into the .NET part you would have the best balance of automation vs manual cleanup.
Maybe you could go a step further and automate the process of removing the files from .NET
(and backing them up somewhere) that have been deleted in Java and creating new `.cs` files
for the corresponding new files in Java (and maybe even porting the code using one of the
existing automated porting tools).
    
    @nazjunaid - thanks for the update.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message