Sample

int-d794ad8dd7a8-I06

Invert eligible conditions and exchange their branches

Matched original source

Lines133

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.4980–1; higher is more readable
Dorn0.3020–1; higher is more readable
Mi0.3190–1; higher is more readable
LLOC84Logical lines; fewer is more readable
DeepSeek V4 Pro11.330–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.3750–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))) {} else { 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; for (int offset = position; offset < len; offset += Long.BYTES) { long m = input.getLong(offset); if (!((needsReverse))) {} else { // 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() { 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.5502.941−181.597
Source linesThe number of non-empty source lines.133+53.2
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.654−6.98

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

Score0.498

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.134−3.708
Indentation frequencyHow rapidly indentation changes from line to line.121+3.448
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.121−2.356
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.132.892+1.448
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.100.948+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.985−0.612
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.092+0.048

Intercept 0.07 + feature contributions = -0.838 (log-odds).
Score = sigmoid(-0.838) = 0.302.

Score0.319
Score84
Run 1

The code is moderately readable. It has clear structure with separate constants, fields, and methods. The SipHash algorithm is logically organized, and comments explain non-obvious details. However, several issues reduce clarity: the inverted if-else statements like `if (!((seed.length != SEED_LENGTH))) {} else { throw ... }` and `if (!((needsReverse))) {} else { ... }` are unnecessarily convoluted. The constructor's empty if-block and the double negation make control flow confusing. Similarly, the empty true-branch in the needsReverse check obscures intent. The fall-through switch for tail bytes is compact but requires careful reading; some comments could improve it. Variable names are generally descriptive, and sipround() is well-factored. The code length is reasonable for the algorithm. Overall, it's readable for domain experts but could be improved with clearer conditionals and control flow.

Run 2

The code has clear class structure and constants, but several readability issues undermine its score. The conditional checks using `if (!condition) {} else {...}` are needlessly inverted and obscure intent. The fall-through switch in the tail-processing section, while intentional, requires deep knowledge of SipHash and reduces clarity. Variable names like `v0`–`v3` and `k0`/`k1` are terse, matching the paper but not self-documenting. Multiple operations per line in `sipround()` make the algorithm harder to follow. The long `macHash` method mixes state initialization, block processing, tail handling, and finalization without separation, hurting action granularity and logical organization. The validation logic (`if (!(...)) {} else throw`) is awkward and reduces trust in correctness. Overall, the code is difficult to read without external documentation.

Run 3

The code is generally well-structured with clear field grouping and a straightforward macHash method, but it has several readability issues. The most jarring is the use of inverted boolean checks like 'if (!((condition))) {} else { ... }' and 'if (!((seed.length != SEED_LENGTH))) {} else { ... }', which are confusing and should be direct positive expressions. The switch statement with intentional fall-through (case 7 through case 1) is efficient but not immediately obvious without comments. Long decimal literals like 0x736f6d6570736575L are hard to parse visually despite comments. The macHash method mixes offset calculations, loop logic, and bit manipulation in a way that requires careful reading. Naming is mostly clear (sipround, compressionRounds, etc.), and the code avoids deep nesting, but the convoluted conditionals and dense bit operations reduce clarity. Overall, it's functional but not as readable as it could be.

Run 1

Code Structure: Constants, initialization, hashing, and round operations are logically separated into focused methods. Nesting: Mostly shallow, with manageable nested loops and a switch. Clarity of intent: Descriptive configuration names and specification references help, but cryptographic state names, unexplained rotation values, and undocumented switch fall-through require specialist knowledge. The negated conditions with empty branches obscure simple checks. Code length: Reasonably concise for the algorithm, although repetitive tail-byte handling adds visual bulk. Action granularity: Nearly all lines perform one operation; the empty if/else constructs are notable exceptions. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence, aided by spacing. However, awkward conditionals and the relationship between position, len, and the loop bound interrupt comprehension.

Run 2

Code Structure: Constants, initialization, hashing, and round operations are logically separated. Nesting: Generally shallow, with manageable nested compression loops, but empty if branches and redundant negation unnecessarily complicate conditions. Clarity of intent: Descriptive round-count names, comments, and the algorithm reference help; terse state names, unexplained switch fall-through, and bit manipulation require specialist knowledge. Code length: Mostly appropriate for the algorithm, though repeated round loops and verbose conditionals add some overhead. Action granularity: Nearly every line performs one operation, making state changes easy to trace. Reading flow: Initialization, block processing, tail handling, and finalization follow a natural sequence. However, the unusual conditional style interrupts that flow, and inconsistent position-relative indexing makes the block-processing boundary harder to understand.

Run 3

Code Structure: Constants, initialization, hashing, and round operations are logically separated, though mutable shared state makes tracking execution harder. Nesting: Mostly shallow, with modest loop nesting; empty branches and negated conditions add needless complexity. Clarity of intent: Descriptive configuration names, comments, and the specification link help, but terse state names, unexplained switch fall-through, and cryptographic literals require domain knowledge. Code length: Reasonably concise for the algorithm, although repeated round loops and verbose conditionals introduce some redundancy. Action granularity: Nearly every line performs one operation, making state changes easy to follow. Reading flow: Initialization, compression, and finalization proceed naturally, but double-negated if/else constructs interrupt reading, and mixing absolute positions with a relative length in the loop bound makes indexing difficult to reason about.