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() {}
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 a(Class<T> a) {
checkNotNull(a);
if (a.isPrimitive()) {
if (a == boolean.class) {
return (T) Boolean.FALSE;
} else if (a == char.class) {
return (T) Character.valueOf('\0');
} else if (a == byte.class) {
return (T) Byte.valueOf((byte) 0);
} else if (a == short.class) {
return (T) Short.valueOf((short) 0);
} else if (a == int.class) {
return (T) Integer.valueOf(0);
} else if (a == long.class) {
return (T) Long.valueOf(0L);
} else if (a == float.class) {
return (T) FLOAT_DEFAULT;
} else if (a == double.class) {
return (T) DOUBLE_DEFAULT;
}
}
return null;
}
}
Run 1
The code has clear structure with a private constructor, constants, and a focused method. Naming is generally poor: the method 'a' and parameter 'a' are meaningless, severely hurting clarity of intent. The parameter name 'a' requires reading the implementation to understand it represents a Class object. The comments and documentation are helpful and explain the JLS default values. The if-else chain is flat but verbose; a switch statement or map lookup would be more concise. Each line performs one action, improving readability. The reading flow is natural: validate input, check primitive, return defaults, fall through to null. Overall the code is logically organized but undermined by opaque naming and slightly verbose branching.
Run 2
The code structure is logical but readability suffers due to poor naming: the generic method `a(Class<T> a)` has meaningless parameter and method names, obscuring intent. The long if-else chain checking primitive types is flat but repetitive and verbose, reducing clarity. Action granularity is mostly one action per line, and the flow is straightforward, but the misleading names require extra mental effort. The Javadoc is helpful, but the method signature contradicts it. Overall, the code is maintainable only after renaming; otherwise, it is difficult to follow at a glance.
Run 3
The code is well-structured and readable overall. It has clear package/import declarations, a class-level Javadoc, a private constructor, and a single public method with a documented purpose. Nesting is shallow: only one if-else chain within an outer if, which is acceptable. Intent is clear — return JLS-defined default values for primitive types. However, readability is hurt by poor naming: the method is named `a` and the parameter `a`, obscuring intent despite the Javadoc. Action granularity is mostly one action per line, and reading flow is logical. Code length is concise but the if-else chain could be replaced by a switch or map for improved clarity. The `@SuppressWarnings` annotation with inline comment is helpful, though the `BooleanLiteral` suppression reason is slightly cryptic. Overall, it is readable but falls short of excellent mainly due to vague identifier naming.
Run 1
Code Structure: A focused utility class with logically organized constants and a single method. Nesting: Only two levels, although the long conditional chain adds repetition. Clarity of intent: Documentation clearly explains the behavior, but naming both the method and parameter 'a' obscures their purpose; the documented parameter name 'type' also mismatches the code. Code length: Reasonably concise for explicit handling of eight primitive types. Action granularity: Each check and return occupies its own line, making individual operations easy to follow. Reading flow: Consistent formatting and predictable branches support natural reading, with minor friction from generic casts, abbreviated names, and the repetitive conditional chain.
Run 2
Code Structure: A focused utility class with logically organized constants and a single method. Nesting: Only two levels, keeping the conditional chain easy to follow. Clarity of intent: Documentation clearly explains default-value behavior, but naming both the method and parameter 'a' obscures their purpose; the documentation also references 'type' rather than the actual parameter. Code length: Reasonably concise, though primitive handling requires a repetitive conditional chain. Action granularity: Each statement performs one clear action, with no crowded multi-action lines. Reading flow: Validation, primitive checks, and the final null fallback form a natural sequence. Consistent formatting helps readability, while generic casts and annotation details add modest visual complexity.
Run 3
Code Structure: The utility class is logically organized, with constants and a single focused method. Nesting: Only two levels are used, though the outer primitive check adds some indentation. Clarity of intent: Documentation and explicit type comparisons clearly explain the behavior, but naming both the method and parameter 'a' substantially weakens readability; the documentation also refers to 'type' rather than the actual parameter. Code length: Reasonably concise, although the repetitive conditional chain is somewhat lengthy. Action granularity: Each statement performs one action, and return cases are clearly separated. Reading flow: The sequential primitive-type checks are easy to follow, with a straightforward null fallback. Minor formatting issues, such as missing separation between the package declaration and imports, slightly reduce polish.