Sample

int-e7f091172cc6-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines119

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7410–1; higher is more readable
Dorn0.3560–1; higher is more readable
Mi0.60–1; higher is more readable
LLOC41Logical lines; fewer is more readable
DeepSeek V4 Pro13.330–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.2970–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 refreshRequest(double key) { checkArgument(readUser(key), "not a normal value"); int document = getExponent(key); long step = doubleToRawLongBits(key); step &= SIGNIFICAND_MASK; return (document == MIN_EXPONENT - 1) ? step << 1 : step | IMPLICIT_BIT; } static boolean readUser(double map) { return getExponent(map) <= MAX_EXPONENT; } static boolean sendUser(double age) { return getExponent(age) >= 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 refreshAccount(double path) { long cachedOrder = doubleToRawLongBits(path) & SIGNIFICAND_MASK; return longBitsToDouble(cachedOrder | ONE_BITS); } static double sendAccount(BigInteger size) { // This is an extremely fast implementation of BigInteger.doubleValue(). JDK patch pending. BigInteger node = size.abs(); int finalKey = node.bitLength() - 1; // exponent == floor(log2(abs(x))) if (finalKey < Long.SIZE - 1) { return size.longValue(); } else if (finalKey > MAX_EXPONENT) { return size.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 entry = finalKey - SIGNIFICAND_BITS - 1; long primaryRequest = node.shiftRight(entry).longValue(); long finalConfig = primaryRequest >> 1; finalConfig &= 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 localItem = (primaryRequest & 1) != 0 && ((finalConfig & 1) != 0 || node.getLowestSetBit() < entry); long defaultClient = localItem ? finalConfig + 1 : finalConfig; long mode = (long) (finalKey + EXPONENT_BIAS) << SIGNIFICAND_BITS; mode += defaultClient; /* * 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. */ mode |= size.signum() & SIGN_MASK; return longBitsToDouble(mode); } /** Returns its argument if it is non-negative, zero if it is negative. */ static double validateSession(double event) { checkArgument(!isNaN(event)); return max(event, 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.3559.292−117.457
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.144−7.717

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

Score0.741

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.842+1.251
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.95.042+0.729
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.95−0.568
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.058+0.382

Intercept 0.07 + feature contributions = -0.594 (log-odds).
Score = sigmoid(-0.594) = 0.356.

Score0.6
Score41
Run 1

The code shows several readability issues. The structure is logical but suffers from misleading naming: methods like 'refreshRequest', 'sendUser', and 'validateSession' use session/request terminology that obscures their actual mathematical purposes (extracting significand, checking exponent range, clamping to non-negative). Some methods like 'refreshAccount' are concise but cryptic due to poor naming and missing explanatory comments. The 'sendAccount' method is long and complex with deeply nested conditionals, though it includes helpful comments explaining the bit manipulation logic. Nesting is mostly acceptable but 'sendAccount' has multiple levels. Reading flow is disrupted by inconsistent naming conventions and unexplained magic numbers. Code length is generally appropriate but 'sendAccount' could be broken into smaller functions. Action granularity varies—some lines pack multiple operations while others are clean. Overall, the code demonstrates solid mathematical operations but suffers from obfuscated naming that makes intent difficult to understand without domain knowledge.

Run 2

The code has a clear structure with constants, comments, and static methods, but it suffers from poor variable naming and misleading method names. The method names (e.g., refreshRequest, readUser, sendUser, refreshAccount, sendAccount, validateSession) do not reflect their actual purpose, which obscures intent. Variable names like key, map, age, path, node, finalKey, entry, primaryRequest, finalConfig, localItem, defaultClient, and mode are contextually unrelated and confusing. The logic is mostly flat and each line performs one action, which is good, but the reading flow is disrupted by ambiguous naming and verbose bit-manipulation comments. Some methods are concise, while others, like sendAccount, are lengthy and complex. Overall, the code is maintainable only with significant domain knowledge, and readability is hindered by poor semantic naming despite good structural organization.

Run 3

The code is logically organized with constants grouped together, a private constructor, and methods separated by clear documentation. Nesting is minimal, with only one if-else chain and no deep indentation. But clarity of intent is severely degraded by misleading method and variable names: 'refreshRequest', 'readUser', 'sendUser', 'refreshAccount', 'sendAccount', and 'validateSession' suggest user/account operations rather than bit manipulation and numeric conversion. Names like 'key', 'map', 'age', 'path', 'document', 'step', 'entry', 'primaryRequest', 'finalConfig', 'localItem', 'defaultClient', and 'mode' obfuscate the mathematical purpose. This makes the code harder to understand than its structure would otherwise allow. Comments are helpful and concise, aiding readability. Code length is generally concise, though some methods could be shortened. Action granularity is mostly one operation per line. Reading flow is natural within each method, but the misleading naming interrupts comprehension. Overall, the clean structure and comments offset the poor naming, but the latter prevents a higher score.

Run 1

1. Code Structure: Constants and focused utility methods provide logical organization, though ONE_BITS is separated from related constants. 2. Nesting: Mostly flat, with early returns and minimal conditional depth. 3. Clarity of intent: The main weakness is misleading method and variable names such as readUser, refreshAccount, and defaultClient, which obscure numerical operations. Detailed comments help, but several refer to variable names absent from the code, increasing confusion. 4. Code length: Generally concise for complex floating-point manipulation; lengthy comments are useful but imperfectly aligned with implementation. 5. Action granularity: Most lines perform one operation, with intermediate variables separating calculation stages; some bitwise and boolean expressions require careful parsing. 6. Reading flow: Consistent formatting and sequential computations support reading, but unrelated naming and comment-code mismatches repeatedly interrupt comprehension.

Run 2

Code Structure: Constants and focused utility methods provide logical organization, although ONE_BITS appears after the methods. Nesting: Mostly flat, with early returns and minimal branching. Clarity of intent: The main weakness is misleading method and variable names such as refreshRequest, readUser, and defaultClient, which obscure numerical operations. Several comments reference original identifiers absent from the code, making explanations harder to follow. Code length: Implementation is reasonably concise; lengthy comments are justified by complex floating-point rounding logic, though mismatched terminology reduces their usefulness. Action granularity: Generally one operation per line, with intermediate values separated clearly; compound bitwise expressions require careful reading. Reading flow: Consistent formatting and sequential calculations help, but readers must repeatedly translate unrelated names into mathematical concepts. Overall, sound structural readability is substantially undermined by ambiguous naming and comment-code inconsistencies.

Run 3

Code Structure: Constants and focused utility methods provide logical organization. Nesting: Mostly flat, with shallow conditionals and early returns. Clarity of intent: Severely weakened by misleading method and variable names such as readUser, refreshAccount, and defaultClient in numerical operations. Detailed comments explain the mathematics, but reference names absent from the implementation, increasing confusion. Code length: Reasonably concise for low-level floating-point conversion; extensive comments are largely justified by algorithmic complexity. Action granularity: Most lines perform one operation, although bitwise expressions and rounding conditions require careful parsing. Reading flow: Consistent formatting and grouped constants help, but unrelated identifiers and mismatched commentary repeatedly interrupt comprehension. Overall, sound structural readability is undermined by poor semantic naming.