4 ms·
- Don't chain multiple methods in a line. One call per line. IDEs will usually let you set breakpoints per line. - You can still use intermediate variables f
by ebola1717 10y ago
- Don't chain multiple methods in a line. One call per line. IDEs will usually let you set breakpoints per line.
- You can still use intermediate variables for readability
e.g. instead of
nums.filter((n) => n % 2 == 0).map((n) => n + 2).foreach((n) => print(n))
do:
nums.filter((n) => n % 2 == 0)
.map((n) => n + 2)
.foreach((n) => print(n))
or:
List<Integer> evens = nums.filter((n) => n % 2 == 0)
evens.map((n) => n + 2)
.foreach((n) => print(n))
- ajkjk 10y agoGood points. I just feel that this is something IDEs really need to solve, without involving work from me. And it might be a limitation of the JDK debugging system (though I imagine it could be shimmed into IDEs either way). Basically I want to see a "skip to next chained method" button alongside "step" and "step into" and "step over". And maybe another that lets me step to the next iteration of a given chained method as well.
- Tarean 10y agoI think java's problem here is how annoying it is to split these up. For example your example completely split up in java vs haskell: Java IntPredicate even = i -> i % 2 == 0; IntUnaryOperator add2 = i -> i + 2; UnaryOperator<IntStream> process = s -> s.filter(even).map(add2); for (int i in process.apply(numbers)) { System.out.println(String.valueOf(i)); } Haskell: printProcessed = mapM_ print . process where process = map (+2) . filter even
- pekk 10y agoIt's even more concise in APL, assuming you know how to read APL.