Source code
public class Main {
private static final String[] ones = {"", "one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "ten", "eleven", "twelve", "thirteen", "fourteen", "fifteen", "sixteen", "seventeen", "eighteen", "nineteen"};
private static final String[] tens = {"", "", "twenty", "thirty", "forty", "fifty", "sixty", "seventy", "eighty", "ninety"};
public static void main(String[] args) {
for (String arg : args) {
int num = Integer.parseInt(arg);
if (num == 0) {
System.out.println("zero");
} else {
System.out.println(convert(num));
}
}
}
private static String convert(int num) {
if (num < 20) {
return ones[num];
}
if (num < 100) {
return tens[num/10] + ((num % 10 != 0) ? " " : "") + ones[num%10];
}
if (num < 1000) {
return ones[num/100] + " hundred" + ((num % 100 != 0) ? " and " : "") + convert(num % 100);
}
return "one thousand";
}
}
Run 1
The code is generally well-structured and readable. It separates configuration arrays, main logic, and the recursive conversion method. Nesting is minimal: the main method uses one loop with a simple if-else, and the convert method uses a flat sequence of if statements rather than nested conditionals. Clarity of intent is mostly good, although magic numbers like 20, 100, and 1000 could be named constants. Code length is appropriate — not overly verbose or compressed. Action granularity is mostly reasonable, though the return statements in convert() pack multiple operations into single lines, making them slightly dense. Reading flow is natural: input parsing, zero check, conversion, and output follow a logical order. The ternary operators add some complexity but are acceptable. Overall, readability could be marginally improved with named constants and slightly more spacing in the trickier return statements.
Run 2
The code is highly readable due to its clear structure and logical organization. Constants for number words are separated at the top, and the main logic is split into small, focused methods. Nesting is minimal, with only one level in main and none in convert. Intent is evident: convert numeric arguments to their English words. The code is concise, avoiding unnecessary verbosity, and each line typically performs a single action. Reading flow is natural, progressing from input handling to conversion logic. Minor deductions: the ternary conditional in string concatenation slightly reduces clarity, and hardcoded 'one thousand' limits extensibility, but overall the code is well-structured and easy to follow.
Run 3
The code is generally well-structured and readable. It separates number-to-words conversion into a dedicated method, uses meaningful variable names, and avoids nesting with early returns. Each condition is flat and clear, and helper arrays (`ones`, `tens`) make intent obvious. Lines are concise, mostly one action per line, and the reading flow is natural from input handling to conversion logic. Minor deductions: the class name `Main` is generic, the number range is hardcoded (e.g., only up to 1000), and the nested ternaries slightly reduce clarity in the `convert` method. Overall, the code is concise, logically organized, and easy to follow.
Run 1
Code Structure: Lookup arrays, argument handling, and conversion logic are logically separated. Nesting: Shallow conditionals and early returns keep complexity low. Clarity of intent: Names and ascending numeric ranges clearly communicate number-to-word conversion, though the supported input range and unconditional 'one thousand' fallback are ambiguous. Code length: Compact without substantial redundancy, but long array declarations and return expressions reduce scanability. Action granularity: Most lines perform one action; conversion returns combine lookup, conditional spacing, concatenation, and recursion. Reading flow: Naturally progresses from input processing to increasingly large number ranges. Consistent operator spacing and breaking complex expressions into intermediate variables would improve readability.
Run 2
Code Structure: Lookup tables, argument processing, and number conversion are logically separated. Nesting: Shallow control flow and early returns keep the conversion method easy to follow. Clarity of intent: Method and variable names convey number-to-word conversion, though the supported range is undocumented and the final return obscures behavior for values above 1000. Code length: Compact without substantial duplication, although the long lookup-table declaration reduces scanability. Action granularity: Most lines perform one action; concatenations combine arithmetic, conditional spacing, and recursion, requiring extra attention. Reading flow: Execution proceeds naturally from input parsing to conversion, but inconsistent operator spacing and limited whitespace slightly weaken readability.
Run 3
Code Structure: Lookup arrays, argument processing, and conversion logic are cleanly separated. Nesting: Early returns keep conversion flat; the main loop has only a shallow conditional. Clarity of intent: Method and array names clearly suggest number-to-word conversion, though the supported input range is undocumented and the final fallback is misleading for values above 1000. Code length: Compact without substantial repetition, but long array declarations and return expressions reduce scanability. Action granularity: Most lines perform one action, although conversion expressions combine arithmetic, conditional spacing, concatenation, and recursion. Reading flow: Cases progress naturally from smaller to larger numbers; consistent operator spacing and additional whitespace between sections would improve readability.