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 [email protected] or file a JIRA ticket
with INFRA.
---
