Source code
public class VampireNumbers {
public static void main(String[] args) {
for (int i = 10; i < 100; i++) {
for (int j = i; j < 100; j++) {
int product = i * j;
if (product > 999 && product < 10000) {
int a = i / 10;
int b = i % 10;
int c = j / 10;
int d = j % 10;
int e = product / 1000;
int f = (product / 100) % 10;
int g = (product / 10) % 10;
int h = product % 10;
if (a == 0 && e == 0) continue;
if ((a == e && b == f && c == g && d ==h) ||
(a == f && b == e && c == h && d == g) ||
(a == g && b == h && c == e && d == f) ||
(a == h && b == g && c == f && d == e)) {
System.out.println(product);
}
}
}
}
}
}
Run 1
The code has a clear overall purpose and basic structure, but readability suffers from poor naming, repetitive logic, and unclear intent. The nested loops are only two levels deep, which is acceptable, but the combination of multiple boolean conditions on one line is hard to follow. Variable names like a through h are cryptic and force the reader to track digit positions mentally. No helper methods or comments explain the vampire number concept or the digit-matching logic. Action granularity is moderate, but the long conditional breaks the flow. The code is concise for its task, but not self-documenting. Overall, it is understandable with effort but not naturally readable.
Run 2
The code is structured logically enough with nested loops and basic variable extraction, but suffers from poor clarity of intent. The nesting is two levels deep, which is acceptable, but the conditional logic is confusing due to meaningless variable names (a-h) and repetitive, hard-coded condition checks. The action granularity is reasonable, with one operation per line in most places, but the overall reading flow is poor because the purpose of the checks is not evident. Code length is concise for the task, but the lack of helper methods or comments obscures the algorithm. The condition `if (a == 0 && e == 0)` is ambiguous and appears to be an incorrect filter. The final boolean expression is tangled and would benefit from being broken into a separate method with a descriptive name.
Run 3
The code has reasonable structure and relatively flat nesting but suffers from low clarity of intent and poor readability. Variable names like a, b, c, d, e, f, g, h are non-descriptive, making the permutation checks hard to follow. The monster OR condition is ambiguous and error-prone. Although one action per line is mostly followed and code length is concise, there are no comments to explain the vampire number logic, and magic numbers (10, 100, 999, 10000) reduce clarity. Reading flow is disrupted by the need to mentally map digits to variables. Overall, the code is understandable but not maintainable, and falls short of clear, self-documenting style.
Run 1
1. Code Structure: Logically organized as factor enumeration, digit extraction, comparison, and output, but all logic is embedded in main rather than separated into named helpers. 2. Nesting: Two loops and two conditional levels create moderately deep nesting. 3. Clarity of intent: The class name indicates the goal, but single-letter digit variables and lengthy permutation checks obscure how candidates are validated. The zero check is puzzling because a cannot be zero within the loop range. 4. Code length: Short overall, though repetitive digit extraction and comparisons make it more verbose than necessary. 5. Action granularity: Most lines contain one action, which helps readability; the inline conditional continue is a minor exception. 6. Reading flow: Execution proceeds naturally from generating candidates to printing matches, but inconsistent spacing and the dense Boolean expression interrupt scanning.
Run 2
Code Structure: Logically organized as candidate generation, digit extraction, matching, and output, but all logic resides in main. Nesting: Two loops and two conditional levels create moderately deep nesting. Clarity of intent: The class name conveys the goal, but single-letter digit variables and unexplained permutation checks obscure the matching logic. Code length: Compact overall, although repetitive comparisons could be replaced by a clearer digit-matching helper. Action granularity: Most lines perform one action; the inline conditional continue slightly compresses control flow. Reading flow: Execution proceeds naturally, but the long Boolean expression interrupts readability, and inconsistent spacing and indentation reduce polish.
Run 3
Code Structure: The search is logically organized, but all logic resides in main rather than named helper methods. Nesting: Two loops and two conditional levels create moderately deep nesting. Clarity of intent: The class name suggests the purpose, but single-letter digit variables and unexplained permutation checks obscure the matching logic; the zero check is also confusing. Code length: The program is compact, though repetitive digit comparisons make the central condition cumbersome. Action granularity: Most lines perform one action, with the inline conditional and continue being a minor exception. Reading flow: Execution proceeds naturally from candidate factors to product validation, digit extraction, matching, and output, but inconsistent spacing and the dense Boolean expression interrupt readability.