Source code
import java.io.*;
import java.lang.*;
import java.util.*;
import java.math.*;
class SortMatrix {
/**
* * Write a function to sort a given matrix in ascending order according to the sum of its rows.
*
* > sortMatrix([[1, 2, 3], [2, 4, 5], [1, 1, 1]])
* [[1, 1, 1], [1, 2, 3], [2, 4, 5]]
* > sortMatrix([[1, 2, 3], [-2, 4, -5], [1, -1, 1]])
* [[-2, 4, -5], [1, -1, 1], [1, 2, 3]]
* > sortMatrix([[5, 8, 9], [6, 4, 3], [2, 1, 4]])
* [[2, 1, 4], [6, 4, 3], [5, 8, 9]]
*/
public static List<List<Integer>> sortMatrix(List<List<Integer>> m) {
if (m == null || m.size() == 0) {
return m;
}
List<List<Integer>> o = new ArrayList<>();
for (int i = 0; i < m.size(); i++) {
o.add(m.get(i));
}
for (int x = 0; x < o.size(); x++) {
for (int y = 0; y < o.size() - 1; y++) {
int a = 0, b = 0;
List<Integer> dx = o.get(y);
List<Integer> dy = o.get(y + 1);
for (Integer num : dx) {
a += num;
}
for (Integer num : dy) {
b += num;
}
if (a > b) {
List<Integer> temp = o.get(y);
o.set(y, o.get(y + 1));
o.set(y + 1, temp);
}
}
}
return o;
}
}
Run 1
The code is functional but unreadable due to poor naming, redundant operations, and unclear intent. The core logic is structured but uses short, meaningless variables like m, o, dx, dy, a, b, which obfuscate purpose. The nested bubble sort and repeated sum calculations are verbose and inefficient. Action granularity is mixed; some lines pack multiple actions together (e.g., int a=0, b=0;). The reading flow is disjointed because the code lacks helper methods or comments to explain the row-sum comparison. The initial null check is good, but the unnecessary imports and redundant loop that copies rows add noise. Overall, the code works but is hard to scan and maintain.
Run 2
The code is logically structured and relatively flat, but suffers from poor clarity and verbosity. Variable names like 'm', 'o', 'dx', 'dy', 'a', 'b' obscure intent, making the code hard to follow. The sorting algorithm (bubble sort) is inefficient and not evident from the code. The row-sum calculation is duplicated inside nested loops, violating DRY principles and inflating code length. The action granularity is mixed: some lines do multiple things, others are spread out. Reading flow is disrupted by unclear naming and lack of helper methods (e.g., rowSum). Error handling is minimal and returns a reference that may be null, which is ambiguous. Overall, it would require significant effort to understand and maintain.
Run 3
The code is logically structured and mostly flat, which helps readability. However, several issues reduce clarity: poor variable names (m, o, dx, dy, a, b), the use of a confusing bubble sort, and redundant copying of the input list. The code mixes row-sum calculation with sorting logic, and the nested loops for summing values could be simplified with helper methods or streams. The intent is only hinted at by the docstring, not by the code itself. Some lines perform multiple actions, such as initialization and summation. The reading flow is interrupted by unclear variable names and non-idiomatic Java constructs. Overall, the code works but could be much clearer and more maintainable with better naming, separate sum calculation, and a cleaner sorting approach.
Run 1
Code Structure: The method logically separates input validation, copying, sorting, and returning, but embeds row-sum calculation inside the sorting loops. Nesting: Two sorting loops containing summation loops and a conditional create moderately deep nesting. Clarity of intent: Documentation and examples clearly explain the goal, but abbreviated names such as m, o, a, b, dx, and dy obscure roles. Code length: Manual copying, bubble sorting, repeated summation, and broad imports make the implementation longer than necessary. Action granularity: Most lines perform one action, although the combined declaration of a and b slightly reduces clarity. Reading flow: Execution proceeds naturally from validation to output, but readers must track poorly named variables and repeated calculations to understand the comparison and swap.
Run 2
Code Structure: The method logically separates input validation, copying, sorting, and returning, but mixes row-sum calculation with sorting. Nesting: Nested sorting loops containing summation loops and a conditional create moderate depth. Clarity of intent: Documentation and examples clearly explain the goal, but names such as m, o, a, b, dx, and dy obscure roles. Code length: The method is manageable, though manual copying and repeated summation make it more verbose than a copy constructor and comparator-based sort. Action granularity: Most lines perform one action; the combined declaration of a and b is a minor exception. Reading flow: Execution proceeds naturally, but readers must track cryptic variables through the bubble-sort implementation. Broad, unnecessary imports add clutter.
Run 3
Code Structure: Logically organized into input validation, copying, sorting, and returning, but row summation and swapping are embedded in the sorting loop rather than separated into helpers. Nesting: Three loop levels increase the effort needed to follow the algorithm. Clarity of intent: The documentation and examples clearly explain the purpose, but names such as m, o, a, b, dx, and dy obscure meaning. Code length: Manual copying, bubble sorting, and repeated row-sum calculations make the implementation longer and more repetitive than necessary. Action granularity: Most lines perform one action, although a and b share a declaration. Reading flow: Consistent formatting and sequential stages support readability, but nested loops and terse names interrupt an otherwise natural flow. Unused wildcard imports add minor clutter.