4 ms·

We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in

We actually made this number public in the post. It just appears laters around the conclusions sections. > On average, we’ve seen a reduction of 11 percent in the number of lines of code from this migration.

melling 4y ago
I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.
- krzyk 4y ago
  I wonder how much of this could be reduced if they used records in Java.
- kaba0 4y ago
  An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
  - strulovich 4y ago
    We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.
jillesvangurp 4y ago
There's also the line length to consider. I've seen the same on my own converted Java code. Less lines of code. But you also get lots of a really short lines. And some formatting actually spreads things out over multiple lines for readability. E.g. I use intellij's build in "put arguments on separate lines" a lot. Especially with named arguments, this is just nicer to look at. It's the same or less code but more lines. But less dense code. A more interesting metric might be simply the byte size of the source files. I would expect that to be slightly better than 11percent. Maybe closer to 20-25%.

melling 4y ago

I was hoping for more but 11% is still significant. So that’s an extra million lines of code that didn’t need to be debugged.

krzyk 4y ago
I wonder how much of this could be reduced if they used records in Java.
kaba0 4y ago
An extra million lines of {, @NotNull, .stream(), .toList(). Hardly any code that would actually have bugs.
- strulovich 4y ago
  We have a consistent braces style, so the lines that are removed are rarely those. A lot of the saves come from `?.` replacing null check chains. Many more from the shorter constructor and field initialization syntax (you can get a bunch of things in one short statement). A bunch more from usage of standard library lambda taking functions (`first`, `single`, etc.). Some more just comes from shorter lines due to less explicit types. These are all more some guesses due to conversions I've seen, and not the result of accurate analysis. We also use very little Java streams. A combination of Java 8 arriving late to Android code, and the preference to avoid extra allocations and inefficiencies streams can cause for shorter lists.

jillesvangurp 4y ago

There's also the line length to consider. I've seen the same on my own converted Java code. Less lines of code. But you also get lots of a really short lines. And some formatting actually spreads things out over multiple lines for readability. E.g. I use intellij's build in "put arguments on separate lines" a lot. Especially with named arguments, this is just nicer to look at. It's the same or less code but more lines. But less dense code. A more interesting metric might be simply the byte size of the source files. I would expect that to be slightly better than 11percent. Maybe closer to 20-25%.