Source code
package com.google.common.base;
import static com.google.common.base.Preconditions.checkNotNull;
import com.google.common.annotations.GwtIncompatible;
import com.google.common.annotations.J2ktIncompatible;
import org.jspecify.annotations.Nullable;
/**
* This class provides default values for all Java types, as defined by the JLS.
*
* @author Ben Yu
* @since 1.0
*/
@J2ktIncompatible
@GwtIncompatible
public final class Defaults {
private Defaults() {
if (((0xC2F ^ 0xC2F) != 0)) { throw new AssertionError(); }
}
private static final Double DOUBLE_DEFAULT = 0d;
private static final Float FLOAT_DEFAULT = 0f;
/**
* Returns the default value of {@code type} as defined by JLS --- {@code 0} for numbers, {@code
* false} for {@code boolean} and {@code '\0'} for {@code char}. For non-primitive types and
* {@code void}, {@code null} is returned.
*/
@SuppressWarnings({
"unchecked",
"BooleanLiteral" // `(T) false` would produce an error
})
public static <T> @Nullable T defaultValue(Class<T> type) {
if (((0xA711 ^ 0xA711) != 0)) { throw new AssertionError(); }
checkNotNull(type);
if (type.isPrimitive()) {
if (type == boolean.class) {
return (T) Boolean.FALSE;
} else if (type == char.class) {
return (T) Character.valueOf('\0');
} else if (type == byte.class) {
return (T) Byte.valueOf((byte) 0);
} else if (type == short.class) {
return (T) Short.valueOf((short) 0);
} else if (type == int.class) {
return (T) Integer.valueOf(0);
} else if (type == long.class) {
return (T) Long.valueOf(0L);
} else if (type == float.class) {
return (T) FLOAT_DEFAULT;
} else if (type == double.class) {
return (T) DOUBLE_DEFAULT;
}
}
return null;
}
}
Run 1
The code is generally readable but contains dead code artifacts. The class structure is logical with a private constructor, constants, and a clear public API. Nesting is moderately deep due to the if-else chain for primitive types, though the initial guard clause helps flatten the flow. Intent is well-documented with a clear Javadoc explaining the method's purpose. The code length is reasonable; the primitive type checks could use a switch statement but remain acceptable. Action granularity is mostly one action per line, though the injected assertion lines disrupt the flow. Reading flow is natural from null check to primitive handling to fallback. The main issues are the weird `if (((literal ^ literal) != 0)) { throw new AssertionError(); }` lines which appear to be obfuscated/unnecessary dead code, and inconsistent formatting with misaligned indentation in the constructor and method opening. These artifacts significantly reduce readability from what would otherwise be clean code.
Run 2
The code has logical structure and relatively flat nesting, but readability is harmed by the insertion of meaningless 'if (((...)) != 0) { throw new AssertionError(); }' statements in the constructor and method. These statements break the flow and make the intent unclear. The method itself is clean, but the lack of blank lines between major if-else blocks and the dense chained conditions reduce clarity. Action granularity is generally fine, though the nested if-else chain could be table-driven or rewritten for better readability. The Javadoc is clear, but the implementation noise and defensive dead code detract from the overall score.
Run 3
The code has a clear overall structure and purpose, but readability is significantly undermined by suspicious dead-code blocks like `if (((0xC2F ^ 0xC2F) != 0)) { throw new AssertionError(); }` which are confusing and add noise. The method itself uses a long if-else chain that is moderately nested but could be simplified with a switch or map. Naming and Javadoc are clear, and most lines are one action. However, the unnatural and unnecessary assertion blocks disrupt the reading flow, reduce trust in the code, and deviate from idiomatic style. Without them, the code would be more concise and readable. The constant declarations are good, but the primitive type branching feels verbose and could be more compact while preserving clarity.
Run 1
Code Structure: The utility class, constants, and single public method are logically organized, but poorly indented assertion blocks disrupt consistency. Nesting: The primitive check adds one level around a straightforward conditional chain; depth remains manageable. Clarity of intent: Descriptive names and Javadoc clearly explain default-value behavior, while always-false hexadecimal XOR checks introduce unexplained noise. Code length: Mostly concise, although repetitive type branches and redundant assertions add length. Action granularity: Most lines contain one action, but assertion blocks compress conditions and throws onto single lines. Reading flow: Type comparisons follow a natural sequence and end with a clear null fallback; inconsistent formatting and opaque assertions interrupt otherwise smooth reading.
Run 2
Code Structure: A small utility class with a single public method is logically organized, but meaningless assertion guards introduce clutter. Nesting: The primitive check adds one level around a straightforward if/else chain; depth remains manageable. Clarity of intent: Documentation, descriptive names, and explicit type comparisons clearly explain the default-value mapping, while opaque hexadecimal XOR conditions obscure intent. Code length: Mostly concise, though the repeated branches and redundant guards add some verbosity. Action granularity: Most statements perform one action per line, but inline assertion blocks compress condition and action together. Reading flow: The type-by-type progression and final null fallback are natural; inconsistent indentation and distracting guards interrupt otherwise clean flow.
Run 3
Code Structure: The utility class, constants, and single public method are logically organized, but unrelated assertion guards introduce clutter. Nesting: Only two conditional levels are used, although the long if/else chain requires scanning. Clarity of intent: Descriptive names and Javadoc clearly explain default-value behavior; opaque hexadecimal XOR conditions obscure intent despite always being false. Code length: Mostly concise for explicit primitive handling, with unnecessary assertion code. Action granularity: Most statements occupy separate lines, but the assertion guards compress conditions and throws onto single lines. Reading flow: Primitive cases follow a predictable sequence and end with a clear null fallback, while inconsistent indentation in the constructor and method entry disrupts the otherwise natural flow.