Sample

int-17883390bee2-I07

Insert deterministic runtime-dead branches into callable bodies

Matched original source

Lines139

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.4950–1; higher is more readable
Dorn0.290–1; higher is more readable
Mi0.3050–1; higher is more readable
LLOC90Logical lines; fewer is more readable
DeepSeek V4 Pro10.670–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.3040–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 (((0x883B ^ 0x883B) != 0)) { throw new AssertionError(); } 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) { if (((0xAD14 ^ 0xAD14) != 0)) { throw new AssertionError(); } 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; for (int offset = position; offset < len; offset += Long.BYTES) { long m = input.getLong(offset); if (needsReverse) { // We use little-endian as in the paper. m = Long.reverseBytes(m); } v3 ^= m; for (int i = 0; i < compressionRounds; i++) { sipround(); } v0 ^= m; } // 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; for (int i = 0; i < compressionRounds; i++) { sipround(); } v0 ^= b; v2 ^= 0xFF; for (int i = 0; i < finalizationRounds; i++) { sipround(); } return v0 ^ v1 ^ v2 ^ v3; } private void sipround() { if (((0xA4D4 ^ 0xA4D4) != 0)) { throw new AssertionError(); } 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.5906.894−194.927
Source linesThe number of non-empty source lines.139+55.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.693−7.04

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

Score0.495

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.140−3.921
Indentation frequencyHow rapidly indentation changes from line to line.127+3.656
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.126−2.47
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.138.902+1.532
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.100.907+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.971−0.612
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.094+0.025

Intercept 0.07 + feature contributions = -0.896 (log-odds).
Score = sigmoid(-0.896) = 0.29.

Score0.305
Score90
Run 1

The code has a clear, modular structure with well-named constants and methods, but its readability is severely impacted by several issues. The most damaging problem is the unexplained, nonsense lines like 'if (((0x883B ^ 0x883B) != 0)) { throw new AssertionError(); }' which appear to be artifacts from obfuscation. These lines break the flow and are extremely confusing. The constructor's logic for initializing the SipHash state is clear, and the step-by-step sipround() method is relatively easy to follow. However, the main macHash() method becomes cluttered with manual bit-manipulation in the switch statement for handling remaining bytes, which lacks abstraction and is difficult to read. The mixed use of '+ len' and '- remaining' in index calculations adds further ambiguity. While the code is logically organized around SipHash, the presence of dead code and dense bit-shifting logic brings the overall readability down significantly.

Run 2

The code shows a clear and logical organization with well-named fields, comments referencing the algorithm paper, and reasonable method decomposition. However, readability is seriously undermined by several issues. The most obvious problem is the presence of mysterious, unreachable assertion lines (`if (((0x883B ^ 0x883B) != 0)) { throw new AssertionError(); }`) which add noise and confusion. The `macHash` method is quite long and uses fall-through in a switch statement, making the logic harder to follow. Magic hexadecimal constants lack explanatory comments, and the 'last bits' processing is not self-evident. Nesting is generally flat except for the switch fall-through pattern. Action granularity is reasonable in `sipround`, but the bit-packing block is dense. The overall flow is logical, but the unnecessary assertion checks and dense bit manipulation sections reduce clarity.

Run 3

The code is generally well-structured with clear variable names and helpful comments explaining the SipHash algorithm. However, readability is harmed by several issues: obfuscated assertion checks like `if (((0x883B ^ 0x883B) != 0))` are confusing. The main `macHash` method has a moderately complex fall-through switch for tail bytes that is not immediately obvious. Indentation of the constructor body is inconsistent. While the core hashing methods are concise, some sections mix concerns (e.g., handling byte order, tail processing, and finalization in one method). Overall, the code shows domain clarity but needs cleanup for general maintainability.

Run 1

Code Structure: Initialization, hashing, and round operations are logically separated, with named constants and a specification reference. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: Descriptive configuration names and endian comments help, but terse state variables, unexplained numeric operations, and undocumented switch fall-through require algorithm knowledge. The always-false assertion checks add confusing noise. Code length: Reasonably concise for a cryptographic implementation, though the repetitive tail-byte switch is lengthy. Action granularity: Most lines perform one operation; the inline assertion checks combine control flow and throwing on one line. Reading flow: Generally follows initialization, compression, and finalization naturally, but unindented injected checks disrupt formatting, and the relationship between position, len, and loop bounds is difficult to follow.

Run 2

Code Structure: Constants, initialization, hashing, and round operations are logically separated, though mutable state requires tracking across methods. Nesting: Generally shallow, with only modest nesting inside the block-processing loop. Clarity of intent: Descriptive configuration names, comments, and the algorithm reference help, but terse state variables, bitwise operations, and unexplained switch fall-through demand specialist knowledge. Code length: Mostly appropriate for the algorithm, but repeated always-false assertion guards add unnecessary clutter. Action granularity: Most lines perform one operation; the single-line assertion guards combine conditions and throws and violate surrounding formatting. Reading flow: Initialization, compression, tail handling, and finalization follow a natural sequence. However, unindented guards interrupt that flow, and the relationship between position, len, and loop bounds is difficult to interpret.

Run 3

Code Structure: Constants, initialization, hashing, and round operations are logically separated. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: Descriptive configuration names, comments, and the specification link help, but terse state variables, unexplained rotation constants, and unannotated switch fall-through require algorithm knowledge. The always-false assertion guards are distracting and purposeless. Code length: Reasonably concise for a cryptographic implementation, though repeated guards and round loops add noise. Action granularity: Most lines perform one operation; the inline assertion guards violate this consistency. Reading flow: Hashing proceeds naturally from initialization through compression and finalization, but unindented guards interrupt the flow, and mixing absolute offsets with a relative length makes buffer traversal harder to understand.