Sample

int-9d9aa0e5d9d5-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines119

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7960–1; higher is more readable
Dorn0.3550–1; higher is more readable
Mi0.6110–1; higher is more readable
LLOC41Logical lines; fewer is more readable
DeepSeek V4 Pro13.670–20; mean of three runs
GPT-6.1 Sol130–20; mean of three runs
BTTF0.3550–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 get(double d) { checkArgument(is(d), "not a normal value"); int exp = getExponent(d); long bit = doubleToRawLongBits(d); bit &= SIGNIFICAND_MASK; return (exp == MIN_EXPONENT - 1) ? bit << 1 : bit | IMPLICIT_BIT; } static boolean is(double d) { return getExponent(d) <= MAX_EXPONENT; } static boolean is2(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 scale(double x) { long sig = doubleToRawLongBits(x) & SIGNIFICAND_MASK; return longBitsToDouble(sig | ONE_BITS); } static double big(BigInteger x) { // This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending. BigInteger abs2 = x.abs(); int exp2 = abs2.bitLength() - 1; // exponent == floor(log2(abs(x))) if (exp2 < Long.SIZE - 1) { return x.longValue(); } else if (exp2 > 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 shi = exp2 - SIGNIFICAND_BITS - 1; long twice = abs2.shiftRight(shi).longValue(); long signif = twice >> 1; signif &= 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 inc = (twice & 1) != 0 && ((signif & 1) != 0 || abs2.getLowestSetBit() < shi); long signif2 = inc ? signif + 1 : signif; long bit2 = (long) (exp2 + EXPONENT_BIAS) << SIGNIFICAND_BITS; bit2 += signif2; /* * 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. */ bit2 |= x.signum() & SIGN_MASK; return longBitsToDouble(bit2); } /** Returns its argument if it is non-negative, zero if it is negative. */ static double ensure(double val) { checkArgument(!isNaN(val)); return max(val, 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.3539.673−116.809
Source linesThe number of non-empty source lines.119+47.6
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.134−7.7

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

Score0.796

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.119−3.177
Indentation frequencyHow rapidly indentation changes from line to line.87+2.272
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.86−1.553
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.118.901+1.252
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.96.667+0.755
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.99.975−0.569
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.598 (log-odds).
Score = sigmoid(-0.598) = 0.355.

Score0.611
Score41
Run 1

The code is highly readable due to its clear logical organization, constants with descriptive names, and meaningful helper methods like get, is, scale, and big. Nesting is minimal, with only a couple of simple if/else branches in big(). Comments explain non-obvious bit-twiddling logic, enhancing clarity of intent. Code length is appropriate for the complexity, and each line generally performs one action. Reading flow is natural—constants first, then utility methods in a logical order. One minor downside is that method names like get, is, and big are terse and could be more descriptive, slightly obscuring intent without context; also the big() method is dense, requiring careful study. Overall, excellent structure and clarity despite advanced numerical operations.

Run 2

The code is generally well-structured and readable for a utility class dealing with low-level double representation. It uses clear, descriptive names and helpful comments, particularly in the `big` method. However, some methods have abbreviated names like `is`, `is2`, `get`, and `big`, which are ambiguous without context. The `big` method contains dense bit manipulation logic that, while commented, remains complex. The code is mostly flat with minimal nesting. Reading flow is natural, but the heavy use of bitwise operations and magic masks requires domain knowledge. Overall, it is readable for experienced developers familiar with IEEE 754 floating-point internals, but less approachable for general audiences.

Run 3

The code demonstrates clear organization through logical method grouping and helpful comments explaining complex algorithms. However, readability is significantly impacted by several factors: methods have cryptic names like 'get', 'is', 'is2', and 'ensure' that require reading the implementation to understand their purpose. The 'big' method is overly complex with multiple nested conditionals, bit manipulation operations, and lengthy inline comments that describe rather than clarify the algorithm. Magic numbers appear throughout (0x3ff0000000000000L, MAX_EXPONENT, etc.) with minimal contextual explanation. Variable names like 'bit', 'bit2', 'exp2', 'shi', and 'twice' lack descriptive clarity. While constants are well-documented with masks, the 'big' method's complexity makes it difficult to follow. The code attempts to explain complex double-precision operations, but overly terse naming and dense bit manipulation make it challenging to read.

Run 1

Code Structure: Constants and focused utility methods provide logical organization, although ONE_BITS is separated from related constants. Nesting: Mostly flat, with shallow conditionals and no nested loops. Clarity of intent: Descriptive constants and detailed mathematical comments help, but vague method names such as get, is, is2, and big and abbreviated variables obscure purpose. Several comments reference variable names absent from the implementation, and the 'normal value' message does not accurately describe the check. Code length: Methods are reasonably concise; extensive rounding comments are useful for complex bit manipulation, though somewhat verbose. Action granularity: Statements generally perform one action per line, with only a few dense compound expressions. Reading flow: Formatting and sequential calculations are consistent, but cryptic naming and mismatched comments force readers to reconstruct the algorithm.

Run 2

Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS is separated from related constants. Nesting: Mostly flat, with early returns and only a shallow conditional chain. Clarity of intent: Descriptive constants and explanatory comments help, but vague method names such as get, is, is2, and big, plus abbreviated variables, obscure meaning. Several comments reference names absent from the implementation, increasing confusion. Code length: The implementation is reasonably concise for specialized floating-point operations; lengthy comments mostly explain necessary complexity. Action granularity: Most statements perform one action per line, although packed bitwise expressions require careful interpretation. Reading flow: Consistent formatting and sequential calculations support reading, but dense rounding logic, weak naming, and mismatched comments interrupt the flow.

Run 3

Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS is separated from related constants. Nesting: Mostly flat, with simple conditionals and early returns. Clarity of intent: Descriptive constants and detailed mathematical comments help, but vague method names such as get, is, is2, and big obscure purpose. Abbreviated variables and comments referencing different variable names further impede understanding. Code length: The implementation is reasonably concise; extensive comments are justified by the numerical complexity, although some are inconsistent with the code. Action granularity: Most lines perform one action, but dense bitwise and rounding expressions require careful parsing. Reading flow: Consistent formatting and localized operations support sequential reading, while ambiguous naming and mismatched commentary interrupt it.