Source code
public class GameOfLife {
public static void main(String[] args) {
char[][] grid = new char[32][32];
// fill the grid with initial values
for (int i = 0; i < 32; i++) {
for (int j = 0; j < 32; j++) {
// assign random value of # or .
grid[i][j] = Math.random() > 0.5 ? '#' : '.';
}
}
// calculate the next state of the grid
char[][] nextGrid = new char[32][32];
for (int i = 0; i < 32; i++) {
for (int j = 0; j < 32; j++) {
int liveNeighbours = countLiveNeighbours(grid, i, j);
if (grid[i][j] == '#' && (liveNeighbours == 2 || liveNeighbours == 3)) {
nextGrid[i][j] = '#';
} else if (grid[i][j] == '.' && liveNeighbours == 3) {
nextGrid[i][j] = '#';
} else {
nextGrid[i][j] = '.';
}
}
}
// output the next state of the grid
for (int i = 0; i < 32; i++) {
for (int j = 0; j < 32; j++) {
System.out.print(nextGrid[i][j]);
}
System.out.println();
}
}
private static int countLiveNeighbours(char[][] grid, int i, int j) {
int count = 0;
for (int x = -1; x <= 1; x++) {
for (int y = -1; y <= 1; y++) {
int row = i + x;
int col = j + y;
if (row >= 0 && row < 32 && col >= 0 && col < 32 && !(x == 0 && y == 0)) {
count += grid[row][col] == '#' ? 1 : 0;
}
}
}
return count;
}
}
Run 1
The code is structurally clear with separate main logic and a helper method for neighbor counting. Nesting is moderate (3 loops deep) and acceptable for grid operations. Intent is mostly clear, but magic numbers like 32 and hardcoded '#' '.' characters reduce clarity. Code length is reasonable but could be improved with named constants. Action granularity is good—most lines perform one action. Reading flow is natural, though the neighbor-check condition in countLiveNeighbours is long and somewhat hard to parse. Overall, the code is readable but would benefit from constants and perhaps extracting boundary logic for improved clarity.
Run 2
The code has a clear overall structure with logically separated sections: initialization, state calculation, output, and a helper method. However, the use of magic numbers (32) throughout hurts readability and maintainability. The nesting depth is moderate (two levels in most loops), but the `countLiveNeighbours` method has a complex conditional statement that combines multiple boundary checks, reducing clarity. The intent is fairly clear due to descriptive method names and comments, though the inline ternary operators add some cognitive load. Code length is reasonable and action granularity is mostly one action per line. Reading flow is natural and follows a logical sequence. The biggest weaknesses are the hardcoded array size and the dense neighbor-counting logic.
Run 3
The code is reasonably readable but has notable maintainability issues. The structure is logical, separating initialization, state computation, and output, with the neighbor counting extracted into a helper method. Nesting is moderate — mostly two levels, with a triple-nested condition in countLiveNeighbours. Intent is generally clear from comments and variable names, though magic numbers like 32 should be constants to clarify meaning. Code length is moderate; the neighbor check could be simplified for conciseness. Action granularity is mostly one action per line, aiding readability. Reading flow is natural — top-down with clear sequential steps. However, the lack of named constants, hardcoded grid dimensions, and slightly verbose boundary checks reduce clarity. Overall, the code is understandable but not highly polished.
Run 1
1. Code Structure: Initialization, state calculation, and output are logically separated, with neighbor counting extracted into a helper; main could be split further. 2. Nesting: Two-level loops are natural for grids, though conditionals add moderate depth. 3. Clarity of intent: Descriptive grid names, comments, and explicit rules make the purpose clear; repeated magic values (32, '#', '.') and index names reduce expressiveness. 4. Code length: Reasonably concise, with minor repetition in loop bounds and live-cell assignments. 5. Action granularity: Each line generally performs one clear action; ternary expressions remain compact and understandable. 6. Reading flow: The progression from initialization to calculation to output is natural, although the long boundary-check condition requires extra attention.
Run 2
Code Structure: Initialization, state calculation, and output are logically grouped, with neighbor counting extracted into a helper; main could be further decomposed. Nesting: Two nested loops plus conditionals create moderate, manageable depth. Clarity of intent: Descriptive names and section comments explain the purpose, though repeated magic values (32, '#', '.') and terse coordinate names reduce clarity. Code length: Reasonably concise, with some repetitive loop structure and duplicated live-cell assignments. Action granularity: Statements generally perform one action per line; ternary expressions are compact and understandable. Reading flow: Execution follows a natural initialize-update-print sequence, and the helper is straightforward, although its long boundary-and-center-exclusion condition requires extra attention.
Run 3
Code Structure: Initialization, state calculation, and output are logically ordered, with neighbor counting extracted into a helper; main could be split further. Nesting: Two nested loops plus conditionals create moderate, manageable depth. Clarity of intent: Descriptive names and section comments make the purpose clear, though repeated literals such as 32, '#' and '.' would benefit from named constants. Code length: Reasonably concise, with some repetitive grid traversal and assignments. Action granularity: Each line generally performs one action, and ternary expressions remain readable. Reading flow: Execution proceeds naturally from setup to computation to display; the lengthy boundary-check condition slightly slows reading.