Sample

int-ad44b52b25d2-I09

Select one of ten low-readability unrelated code templates per class

Matched original source

Lines121

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8010–1; higher is more readable
Dorn0.2780–1; higher is more readable
Mi0.0580–1; higher is more readable
LLOC45Logical lines; fewer is more readable
DeepSeek V4 Pro150–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.3820–1; higher is more readable

Views

Source code

package com.google.common.math; import static com.google.common.base.Preconditions.checkArgument; import static java.lang.Double.MAX_EXPONENT; import static java.lang.Double.MIN_EXPONENT; import static java.lang.Double.POSITIVE_INFINITY; import static java.lang.Double.doubleToRawLongBits; import static java.lang.Double.isNaN; import static java.lang.Double.longBitsToDouble; import static java.lang.Math.getExponent; import static java.lang.Math.max; import com.google.common.annotations.GwtIncompatible; import com.google.common.annotations.VisibleForTesting; import java.math.BigInteger; /** * Utilities for {@code double} primitives. * * @author Louis Wasserman */ @GwtIncompatible final class DoubleUtils { private DoubleUtils() {} // The mask for the significand, according to the {@link // Double#doubleToRawLongBits(double)} spec. static final long SIGNIFICAND_MASK = 0x000fffffffffffffL; // The mask for the exponent, according to the {@link // Double#doubleToRawLongBits(double)} spec. static final long EXPONENT_MASK = 0x7ff0000000000000L; // The mask for the sign, according to the {@link // Double#doubleToRawLongBits(double)} spec. static final long SIGN_MASK = 0x8000000000000000L; static final int SIGNIFICAND_BITS = 52; static final int EXPONENT_BIAS = 1023; /** The implicit 1 bit that is omitted in significands of normal doubles. */ static final long IMPLICIT_BIT = SIGNIFICAND_MASK + 1; static long getSignificand(double d) { {int lI0O_f954d993=(0xB9A9^0xB9A9);switch(lI0O_f954d993){case 0:lI0O_f954d993|=0;break;default:lI0O_f954d993&=0;}} checkArgument(isFinite(d), "not a normal value"); int exponent = getExponent(d); long bits = doubleToRawLongBits(d); bits &= SIGNIFICAND_MASK; return (exponent == MIN_EXPONENT - 1) ? bits << 1 : bits | IMPLICIT_BIT; } static boolean isFinite(double d) { return getExponent(d) <= MAX_EXPONENT; } static boolean isNormal(double d) { return getExponent(d) >= MIN_EXPONENT; } /* * Returns x scaled by a power of 2 such that it is in the range [1, 2). Assumes x is positive, * normal, and finite. */ static double scaleNormalize(double x) { long significand = doubleToRawLongBits(x) & SIGNIFICAND_MASK; return longBitsToDouble(significand | ONE_BITS); } static double bigToDouble(BigInteger x) { // This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending. BigInteger absX = x.abs(); int exponent = absX.bitLength() - 1; // exponent == floor(log2(abs(x))) if (exponent < Long.SIZE - 1) { return x.longValue(); } else if (exponent > MAX_EXPONENT) { return x.signum() * POSITIVE_INFINITY; } /* * We need the top SIGNIFICAND_BITS + 1 bits, including the "implicit" one bit. To make rounding * easier, we pick out the top SIGNIFICAND_BITS + 2 bits, so we have one to help us round up or * down. twiceSignifFloor will contain the top SIGNIFICAND_BITS + 2 bits, and signifFloor the * top SIGNIFICAND_BITS + 1. * * It helps to consider the real number signif = absX * 2^(SIGNIFICAND_BITS - exponent). */ int shift = exponent - SIGNIFICAND_BITS - 1; long twiceSignifFloor = absX.shiftRight(shift).longValue(); long signifFloor = twiceSignifFloor >> 1; signifFloor &= SIGNIFICAND_MASK; // remove the implied bit /* * We round up if either the fractional part of signif is strictly greater than 0.5 (which is * true if the 0.5 bit is set and any lower bit is set), or if the fractional part of signif is * >= 0.5 and signifFloor is odd (which is true if both the 0.5 bit and the 1 bit are set). */ boolean increment = (twiceSignifFloor & 1) != 0 && ((signifFloor & 1) != 0 || absX.getLowestSetBit() < shift); long signifRounded = increment ? signifFloor + 1 : signifFloor; long bits = (long) (exponent + EXPONENT_BIAS) << SIGNIFICAND_BITS; bits += signifRounded; /* * If signifRounded == 2^53, we'd need to set all of the significand bits to zero and add 1 to * the exponent. This is exactly the behavior we get from just adding signifRounded to bits * directly. If the exponent is MAX_DOUBLE_EXPONENT, we round up (correctly) to * Double.POSITIVE_INFINITY. */ bits |= x.signum() & SIGN_MASK; return longBitsToDouble(bits); } /** Returns its argument if it is non-negative, zero if it is negative. */ static double ensureNonNegative(double value) { checkArgument(!isNaN(value)); return max(value, 0.0); } @VisibleForTesting static final long ONE_BITS = 0x3ff0000000000000L; }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.3833.324−126.5
Source linesThe number of non-empty source lines.121+48.4
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5.173−7.759

Intercept 8.87 + feature contributions = -76.989 (log-odds).
Score = sigmoid(-76.989) = 0.

Score0.801

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.121−3.248
Indentation frequencyHow rapidly indentation changes from line to line.89+2.341
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.89−1.621
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.120.896+1.28
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.113.975−1.162
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.113.902+1.033
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.061+0.352

Intercept 0.07 + feature contributions = -0.955 (log-odds).
Score = sigmoid(-0.955) = 0.278.

Score0.058
Score45
Run 1

The code is generally well-structured with clear constants, helpful comments, and logical method organization. However, it contains a glaring issue: an obfuscated dead code block (`int lI0O_f954d993...`) inside `getSignificand`, which severely harms clarity and intent. Nesting is mostly flat, and methods are concise, but the bit-manipulation logic in `bigToDouble` is inherently complex and requires effort to follow. Action granularity is mostly one action per line, and reading flow is natural aside from the obfuscated line. The code would score higher if that artifact were removed and the bit operations were slightly more decomposed or better commented.

Run 2

The code is generally readable with clear constants, helpful comments, and logical structure. However, there are notable issues: an unnecessary switch statement with an obfuscated variable name in getSignificand adds confusion, and the bit manipulation logic in bigToDouble is complex and could benefit from further simplification or additional comments. The overall flow is natural, with one action per line mostly maintained, but the method bodies contain dense bit-level operations that reduce clarity.

Run 3

The code is generally well-structured: it has clear sectioning with constants, utility methods, and Javadoc comments explaining complex logic. The methods are mostly short and focused (good action granularity). However, there is a notable readability issue: a pointless switch statement with an obfuscated variable name inside getSignificand, which disrupts reading flow and adds confusion. The bigToDouble method is longer and has intricate bit manipulation, but its comments mitigate the complexity. Nesting is mostly flat, and intent is usually clear, though some low-level bit operations could be clearer. Overall, it is readable for an experienced Java developer familiar with floating-point representation, but the odd artifact lowers the score.

Run 1

Code Structure: Cohesive utility class with well-separated methods and named constants, undermined by an unrelated no-op block in getSignificand. Nesting: Most methods are flat; the injected switch adds unnecessary branching and nesting. Clarity of intent: Descriptive names and detailed comments explain complex floating-point operations, but the cryptic injected variable and redundant operations obscure intent. Code length: Generally appropriate for the numerical algorithm; explanatory comments are useful, while the injected block adds needless length. Action granularity: Most statements perform one action per line, but the injected block compresses declarations, branching, assignments, and breaks onto one line. Reading flow: Constants followed by focused methods create a natural progression, interrupted by the poorly formatted injected block and some dense bitwise expressions.

Run 2

Code Structure: Constants and focused utility methods are logically organized, but an unrelated no-op switch block disrupts getSignificand. Nesting: Most methods are flat, with limited conditional depth; the injected block adds unnecessary nesting. Clarity of intent: Descriptive names and detailed comments explain floating-point operations and rounding, although bit manipulation requires domain knowledge and the opaque injected variable obscures intent. Code length: Generally proportionate to the algorithms, with useful explanatory comments, but the no-op block is needless. Action granularity: Almost all statements occupy separate lines; the injected block compresses declarations, branching, assignments, and breaks into one line. Reading flow: Methods progress naturally from validation through calculation to return, but the poorly formatted switch interrupts an otherwise consistent, readable style.

Run 3

Code Structure: Well organized into focused utility methods and named constants, except for an unrelated no-op switch block in getSignificand. Nesting: Mostly flat, with early returns and minimal conditional nesting; the injected switch adds unnecessary complexity. Clarity of intent: Descriptive method names and detailed comments explain IEEE-754 operations and rounding, though dense bitwise expressions require specialized knowledge. The opaque variable name and meaningless operations in the injected block obscure intent. Code length: Generally appropriate for the numerical algorithm; explanatory comments are useful, but the no-op block is entirely unnecessary. Action granularity: Most statements perform one action per line, while the compressed switch block packs declarations, branching, assignments, and breaks onto one line. Reading flow: Constants followed by small helpers provide a natural progression, and rounding comments guide the longer conversion method. The unindented, obfuscated block abruptly interrupts otherwise consistent formatting and flow.