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() {
{int lI0O_8e73afe4=0x7B99,lI0O_664fe694=~lI0O_8e73afe4;lI0O_8e73afe4=(lI0O_8e73afe4&lI0O_664fe694)|(lI0O_8e73afe4^lI0O_8e73afe4);lI0O_664fe694^=lI0O_664fe694;}
}
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) {
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 mostly readable, with a clear Javadoc and a straightforward method for returning default values. However, the obfuscated code inside the private constructor severely undermines clarity. It serves no purpose, obscures intent, and would confuse any reader. The if-else chain is flat but repetitive, and could be replaced with a switch or map for better structure. Action granularity is good, with one return per branch. Reading flow is natural aside from the constructor. Overall, the main logic is fine but the unexplained obfuscation lowers the score significantly.
Run 2
The code is generally readable with clear intent and good structure. The class has a single, well-documented purpose with Javadoc explaining the defaultValue method's behavior. The method uses a flat if-else chain for primitive type checking, which is straightforward but somewhat verbose. There's a minor issue in the private constructor containing an obfuscated, meaningless line that appears to be dead code, which hurts clarity. The static final constants are well-named, and the @SuppressWarnings annotations are appropriately documented. The code could be improved by using a switch statement or a map for type mappings to reduce length, but the current approach is acceptable for readability. Overall, the code is clear but has minor flaws.
Run 3
The code is largely unreadable due to several critical issues. The private constructor contains obfuscated, meaningless bitwise operations on local variables serving no purpose. This destroys clarity of intent and action granularity. The defaultValue method exhibits deep nesting through a chain of if-else statements, reducing readability. While constants and method documentation are clear, the method's repetitive casting and sequence of primitive type checks make the reading flow choppy and unnecessarily long. The overall structure is logical but undermined by the constructor's junk code and dense conditional chain. These issues severely compromise readability despite some good naming and Javadoc practices.
Run 1
Code Structure: The utility class is logically organized, with constants and a single focused public method, but the constructor contains unrelated, obfuscated calculations. Nesting: The method has only two conditional levels, making control flow easy to follow. Clarity of intent: Documentation, descriptive names, and explicit primitive-type checks clearly convey the main purpose; meaningless constructor variables and bitwise operations obscure intent locally. Code length: The type-dispatch chain is reasonably concise, although repetitive, while the constructor adds unnecessary code. Action granularity: Most statements perform one action per line, but the constructor compresses several declarations and assignments onto one line. Reading flow: The main method follows a natural check-and-return sequence; inconsistent constructor formatting and unexplained calculations interrupt otherwise smooth reading.
Run 2
Code Structure: The class is logically organized around a single utility method, but the constructor contains unrelated obfuscated operations. Nesting: The method has only two conditional levels, making branches easy to follow; the constructor adds an unnecessary block. Clarity of intent: Documentation, method names, and explicit primitive-type comparisons clearly explain the main purpose, while cryptic constructor variables and redundant bitwise operations obscure intent. Code length: The type-selection chain is reasonable for the supported types, but the constructor adds needless code. Action granularity: Most lines perform one clear action; the constructor compresses several declarations and assignments onto one line. Reading flow: The main method follows a predictable check-and-return sequence, but inconsistent constructor formatting and dense expressions interrupt otherwise natural reading.
Run 3
Code Structure: The class, constants, and default-value method are logically organized, but the constructor contains unrelated obfuscated operations. Nesting: The method has only two conditional levels and straightforward return branches; the constructor adds an unnecessary block. Clarity of intent: Documentation, method naming, and explicit primitive comparisons clearly explain the main behavior, while cryptic constructor variables and bitwise expressions obscure their purpose. Code length: The primitive dispatch is reasonably concise, but the constructor adds unnecessary code. Action granularity: Most statements occupy separate lines; the constructor compresses several declarations and assignments onto one line. Reading flow: The defaultValue method reads naturally and consistently, but the poorly formatted constructor abruptly interrupts that flow.