Sample

int-a5d112d93c8e-I13

Lower every eligible classic and enhanced for loop to a while loop

Matched original source

Lines149

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.5290–1; higher is more readable
Dorn0.2790–1; higher is more readable
Mi0.3050–1; higher is more readable
LLOC88Logical lines; fewer is more readable
DeepSeek V4 Pro14.670–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.3810–1; higher is more readable

Views

Source code

package io.netty.handler.codec.quic; import io.netty.util.internal.ObjectUtil; import java.nio.ByteBuffer; import java.nio.ByteOrder; /** * <a href="https://www.aumasson.jp/siphash/siphash.pdf">Siphash implementation</a>. */ final class SipHash { static final int SEED_LENGTH = 16; // Make this class allocation free as soon as its constructed. private final int compressionRounds; private final int finalizationRounds; // As specified in https://www.aumasson.jp/siphash/siphash.pdf private static final long INITIAL_STATE_V0 = 0x736f6d6570736575L; // "somepseu" private static final long INITIAL_STATE_V1 = 0x646f72616e646f6dL; // "dorandom" private static final long INITIAL_STATE_V2 = 0x6c7967656e657261L; // "lygenera" private static final long INITIAL_STATE_V3 = 0x7465646279746573L; // "tedbytes" private final long initialStateV0; private final long initialStateV1; private final long initialStateV2; private final long initialStateV3; private long v0; private long v1; private long v2; private long v3; SipHash(int compressionRounds, int finalizationRounds, byte[] seed) { if (seed.length != SEED_LENGTH) { throw new IllegalArgumentException("seed must be of length " + SEED_LENGTH); } this.compressionRounds = ObjectUtil.checkPositive(compressionRounds, "compressionRounds"); this.finalizationRounds = ObjectUtil.checkPositive(finalizationRounds, "finalizationRounds"); // Wrap the seed to extract two longs that will be used to generate the initial state. // Use little-endian as in the paper. ByteBuffer keyBuffer = ByteBuffer.wrap(seed).order(ByteOrder.LITTLE_ENDIAN); final long k0 = keyBuffer.getLong(); final long k1 = keyBuffer.getLong(); initialStateV0 = INITIAL_STATE_V0 ^ k0; initialStateV1 = INITIAL_STATE_V1 ^ k1; initialStateV2 = INITIAL_STATE_V2 ^ k0; initialStateV3 = INITIAL_STATE_V3 ^ k1; } long macHash(ByteBuffer input) { v0 = initialStateV0; v1 = initialStateV1; v2 = initialStateV2; v3 = initialStateV3; int remaining = input.remaining(); int position = input.position(); int len = remaining - (remaining % Long.BYTES); boolean needsReverse = input.order() == ByteOrder.BIG_ENDIAN; { int offset = position; while (offset < len) { long m = input.getLong(offset); if (needsReverse) { // We use little-endian as in the paper. m = Long.reverseBytes(m); } v3 ^= m; { int i = 0; while (i < compressionRounds) { sipround(); i++; } } v0 ^= m; offset += Long.BYTES; } } // Get last bits. final int left = remaining & (Long.BYTES - 1); long b = (long) remaining << 56; assert left < Long.BYTES; switch (left) { case 7: b |= (long) input.get(position + len + 6) << 48; case 6: b |= (long) input.get(position + len + 5) << 40; case 5: b |= (long) input.get(position + len + 4) << 32; case 4: b |= (long) input.get(position + len + 3) << 24; case 3: b |= (long) input.get(position + len + 2) << 16; case 2: b |= (long) input.get(position + len + 1) << 8; case 1: b |= input.get(position + len); break; case 0: break; default: throw new IllegalStateException("Unexpected value: " + left); } v3 ^= b; { int i = 0; while (i < compressionRounds) { sipround(); i++; } } v0 ^= b; v2 ^= 0xFF; { int i = 0; while (i < finalizationRounds) { sipround(); i++; } } return v0 ^ v1 ^ v2 ^ v3; } private void sipround() { v0 += v1; v2 += v3; v1 = Long.rotateLeft(v1, 13); v3 = Long.rotateLeft(v3, 16); v1 ^= v0; v3 ^= v2; v0 = Long.rotateLeft(v0, 32); v2 += v1; v0 += v3; v1 = Long.rotateLeft(v1, 17); v3 = Long.rotateLeft(v3, 21); v1 ^= v2; v3 ^= v0; v2 = Long.rotateLeft(v2, 32); } }

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.5429.995−179.19
Source linesThe number of non-empty source lines.149+59.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.4.544−6.816

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

Score0.529

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.150−4.275
Indentation frequencyHow rapidly indentation changes from line to line.137+4.002
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.137−2.723
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.148.922+1.672
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.100.947+0.824
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.100.98−0.612
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.087+0.094

Intercept 0.07 + feature contributions = -0.948 (log-odds).
Score = sigmoid(-0.948) = 0.279.

Score0.305
Score88
Run 1

The code follows a clear logical structure with constants, state, constructor, and methods, making the overall organization straightforward. The SipHash algorithm implementation is broken into digestible steps (initialize, process blocks, handle remainder, finalize), which aids comprehension. However, the use of unnecessary block scopes (while loops wrapped in braces) adds clutter and disrupts natural reading flow. Variable names like 'b', 'k0', and 'left' are somewhat cryptic despite contextual clues. The main processing loop is relatively flat, but the fall-through switch cases and repeated inlined compression/finalization loops increase cognitive load. Action granularity is generally good (one operation per line), but multiple operations in some lines (e.g., bitwise OR with shifts) require careful parsing. Overall, the code is readable for those familiar with cryptographic primitives but could be improved by extracting repeated round loops into a helper method and removing redundant block scopes.

Run 2

The code is generally clear and well-structured, with meaningful names and logical separation. The constructor validates inputs and initializes state cleanly. The SipHash algorithm is implemented in a straightforward way, with comments referencing the paper and explaining endianness. However, there are a few readability issues. The method macHash() uses awkward block scoping and manual loop unrolling for the case statements, which interrupts reading flow. Some blocks are used unnecessarily, and the loop counters could be for-loops instead of while loops. There are also magic numbers (like 0xFF) and hardcoded length checks that could be constants. The switch-based trailing byte handling is verbose and harder to follow than a loop would be. These factors reduce clarity and add noise without adding value.

Run 3

The code is generally well-structured with clear intent, but suffers from several readability issues. The class has a logical organization with clear constants and fields, and the constructor is straightforward. However, the macHash method contains unnecessary blocks with arbitrary braces around loops, creating visual clutter. The switch statement with fall-through cases for handling remaining bytes is efficient but somewhat confusing without comments explaining the intentional fall-through behavior. Nesting is mostly flat, but the arbitrary blocks add unnecessary depth. Variable names like 'm', 'b', 'v0-v3', and 'k0-k1' are too cryptic for complex cryptographic operations. The sipround method could be split into smaller helpers for better clarity. Overall, the code demonstrates good structure and flow but would benefit from eliminating unnecessary blocks, using more descriptive variable names, and adding comments to clarify the fall-through switch logic and bit manipulation operations.

Run 1

Code Structure: Constants, initialization, hashing, and the round operation are logically separated, though macHash contains several distinct phases. Nesting: Unnecessary scope blocks around while loops add indentation and visual clutter; nesting remains moderate. Clarity of intent: Descriptive configuration names, specification references, and endian comments help, but terse state variables, unexplained bit operations, and undocumented switch fall-through require algorithm knowledge. Code length: Reasonable for a cryptographic implementation, although repeated round loops could be simplified. Action granularity: Each statement generally performs one operation, making state transformations easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, but inconsistent indentation and extra blocks interrupt it. The relationship between position, offset, and len is also difficult to interpret confidently.

Run 2

Code Structure: Constants, initialization, hashing, and the round operation are logically separated, though macHash contains several distinct phases. Nesting: Unnecessary scope blocks around while loops increase nesting and visual clutter. Clarity of intent: Descriptive round-count names, specification references, and endian comments help, but terse state variables and an undocumented fall-through switch require algorithm knowledge. The offset < len comparison is confusing because offset is absolute while len is a relative length. Code length: Reasonably compact for a cryptographic implementation, but repeated loop scaffolding could be simplified with for loops. Action granularity: Almost every line performs one action, making state updates easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence; inconsistent indentation and extra braces interrupt that flow.

Run 3

Code Structure: Constants, initialization, hashing, and round operations are logically separated, though macHash contains several distinct phases. Nesting: Unnecessary scope blocks around while loops add indentation and visual clutter; conventional for loops would simplify this. Clarity of intent: Descriptive configuration names, specification references, and endian comments help, but terse state variables and unexplained switch fall-through require cryptographic familiarity. The distinction between absolute position and relative length also makes the main loop bound difficult to interpret. Code length: Mostly appropriate for the algorithm, although repeated round-loop boilerplate adds avoidable length. Action granularity: Each line generally performs one operation, making state transformations easy to follow. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, but inconsistent indentation and undocumented fall-through interrupt that flow.