-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perform an overall code cleanup #108
Conversation
CI seems to be failing because of unreachable codecov. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks nice! Even though I could argue that keeping one class per file is really Java-style, I don't mind extracting some things.
Please take a look at my comments.
BTW, I update codecov action on main, hopefully it will be more stable if you rebase.
return if (!snake && prev != null) { | ||
prev.previousSnake() | ||
} else { | ||
this | ||
} | ||
} | ||
|
||
override fun toString() = generateSequence(this) { it.prev } | ||
.joinToString(prefix = "[", postfix = "]") { "(${it.i}, ${it.j})" } | ||
override fun toString(): String { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why rewrite this method? For me, the existing implementation feels Kotlin-idiomatic
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mainly two reasons:
- like with one class per file, an implementation closer to the upstream Java one helps in porting future changes
- we need to keep in mind readability. While
generateSequence + joinToString
is definitely more kotlinesque, understanding what's happening when you approach it is much more challenging. With a sequential solution you immediately infer what the result will be.
src/commonMain/kotlin/io/github/petertrr/diffutils/text/DiffRow.kt
Outdated
Show resolved
Hide resolved
src/commonTest/kotlin/io/github/petertrr/diffutils/DiffUtilsTest.kt
Outdated
Show resolved
Hide resolved
src/commonMain/kotlin/io/github/petertrr/diffutils/algorithm/myers/MyersDiff.kt
Show resolved
Hide resolved
src/commonMain/kotlin/io/github/petertrr/diffutils/algorithm/myers/MyersDiff.kt
Outdated
Show resolved
Hide resolved
2 seems too restrictive, and it may actually reduce readability.
…ingConflictOutput
Explicit throws indicator are not idiomatic to Kotlin, and they tend to become out of sync pretty fast with the actual code that is *supposed* to throw.
bebe3e7
to
04efa7a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
Thank you! I'll try to get code coverage up with one of the following PRs to port the java-diff changes. |
As per title, this is just a cleanup to enhance readability or remove unused/duplicated APIs.
I've split each cleanup action into its own commit to make it easier to review them.