Source code
import java.io.*;
import java.lang.*;
import java.util.*;
import java.math.*;
class MinCost {
/**
* * Write a function to find the minimum cost path to reach (m, n) from (0, 0) for the given cost matrix cost[][] and a position (m, n) in cost[][].
*
* > minCost([[1, 2, 3], [4, 8, 2], [1, 5, 3]], 2, 2)
* 8
* > minCost([[2, 3, 4], [5, 9, 3], [2, 6, 4]], 2, 2)
* 12
* > minCost([[3, 4, 5], [6, 10, 4], [3, 7, 5]], 2, 2)
* 16
*/
public static int minCost(List<List<Integer>> cost, int m, int n) {
// Initialize a 2D array of size (m+1) x (n+1) filled with zeros
int[][] d = new int[m + 1][n + 1];
// Loop over rows from 0 to m
for (int i = 0; i <= m; i++) {
// Loop over columns from 0 to n
for (int j = 0; j <= n; j++) {
// Assigning i1 to current row index, j1 to current column index
int i1 = i;
int j1 = j;
// Variables to store costs from neighboring cells
int min1 = Integer.MAX_VALUE;
int min2 = Integer.MAX_VALUE;
int min3 = Integer.MAX_VALUE;
// Check if current cell is at (0,0)
if (i1 == 0 && j1 == 0) {
// Base case: cost at starting point
d[i1][j1] = cost.get(i1).get(j1);
} else {
// If above row exists, get cost from the cell above
if (i1 - 1 >= 0) {
min1 = d[i1 - 1][j1] + cost.get(i1).get(j1);
}
// If left column exists, get cost from the cell to the left
if (j1 - 1 >= 0) {
min2 = d[i1][j1 - 1] + cost.get(i1).get(j1);
}
// If diagonal cell exists, get cost from diagonal
if (i1 - 1 >= 0 && j1 - 1 >= 0) {
min3 = d[i1 - 1][j1 - 1] + cost.get(i1).get(j1);
}
// Assign the minimum of the three possible costs
int[] temp = {min1, min2, min3};
Arrays.sort(temp);
d[i1][j1] = temp[0];
}
}
}
// Return the cost to reach cell (m, n)
return d[m][n];
}
}
Run 1
The code has a clear structure with logical initialization and nested loops, but it suffers from several readability issues. The excessive inline comments restate the obvious rather than explaining why, and variables i1/j1 are redundant aliases for i/j. The dynamic programming logic is straightforward but implemented verbosely: three min variables plus an array sort could be replaced with a single Math.min chain. While actions are generally one per line, the nesting is moderate (if/else inside nested loops), and the flow is disrupted by comment noise. The method lacks input validation for null/empty or out-of-bounds matrices. The Javadoc's examples are helpful but the code's verbosity and redundant assignments reduce clarity. Overall, the code is understandable but not polished.
Run 2
The code has a clear structure and mostly flat nesting, with one action per line. Comments explain intent, and the algorithm is easy to follow. However, readability suffers from redundancies: reassigning i/j into i1/j1 is unnecessary, sorting a three-element array to find the minimum is verbose and inefficient, and multiple if-checks for neighbor validity add clutter. Variable names like min1/min2/min3 are generic and don’t convey direction (up/left/diagonal). The method also lacks error handling for invalid m/n. Overall, the logic is understandable but could be made much cleaner with direct indexing, Math.min, and more descriptive naming.
Run 3
The code follows a clear structure and includes explanatory comments, but it is overly verbose and uses unnecessary complexity. The logic is understandable, but the use of three variables (min1, min2, min3) and sorting a three-element array to find a minimum is inefficient and harms clarity. Assigning i1 and j1 as copies of loop indices adds no value. The code is not deeply nested but could be more concise. The intent is fairly clear due to comments and structure, but the implementation distracts from the purpose. Overall, it is readable but could be significantly improved by simplifying the minimum-cost calculation and removing redundant variables.
Run 1
Code Structure: The single method follows a logical dynamic-programming sequence: initialization, matrix traversal, neighbor evaluation, and return. Nesting: Two loops containing a conditional and neighbor checks create moderate nesting, but consistent indentation helps. Clarity of intent: The documentation and comments explain the goal, although names such as d, min1, and temp are weak, and redundant i1/j1 aliases obscure rather than clarify. Code length: Unnecessary aliases, repetitive comments, repeated cost lookups, and unused wildcard imports add clutter. Action granularity: Statements generally perform one action per line, making operations easy to distinguish. Reading flow: Row-by-row traversal and explicit boundary checks are natural to follow, but sorting an array merely to select the minimum interrupts the otherwise straightforward recurrence.
Run 2
Code Structure: The single method is logically organized around initialization, matrix traversal, neighbor evaluation, and returning the result. Nesting: Two loops plus conditional branches create moderate nesting, though the blocks remain manageable. Clarity of intent: The documentation and comments explain the minimum-cost calculation, but names such as d, i1, min1, and temp are weak; sorting three values obscures a simple minimum operation. Code length: Redundant index aliases, repeated cost lookups, excessive explanatory comments, and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Row-by-row traversal and consistent formatting provide a natural progression, but repetitive comments and temporary variables interrupt the flow.
Run 3
Code Structure: A single method follows a logical dynamic-programming sequence: initialize, traverse, compute, return. Nesting: Two loops plus conditional branches create moderate nesting, but consistent indentation keeps it manageable. Clarity of intent: The method name, documentation, and comments explain the goal, while names such as d, i1, min1, and temp obscure variable roles. Code length: Redundant index aliases, repetitive comments, repeated cost lookups, and sorting three values instead of using Math.min add unnecessary length and complexity. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Row-by-row traversal and explicit boundary checks provide a natural progression, though excessive commentary and the temporary sorting step interrupt the recurrence's flow.