Sample

int-a673a2b9265a-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines140

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.5350–1; higher is more readable
Dorn0.290–1; higher is more readable
Mi0.3270–1; higher is more readable
LLOC88Logical lines; fewer is more readable
DeepSeek V4 Pro7.670–20; mean of three runs
GPT-6.1 Sol140–20; mean of three runs
BTTF0.3310–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) { { int factorial = 1; for (int currentFactor = 2; currentFactor <= 4; currentFactor++) { factorial *= currentFactor; } } 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; 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() { 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.5597.408−184.714
Source linesThe number of non-empty source lines.140+56
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.657−6.986

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

Score0.535

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.141−3.956
Indentation frequencyHow rapidly indentation changes from line to line.128+3.69
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.128−2.516
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.139.892+1.546
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.100.943+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.95−0.611
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.091+0.059

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

Score0.327
Score88
Run 1

The code has a bizarre lone block in the constructor that appears accidental, containing unrelated factorial logic that harms readability and intent. Apart from that, structure and naming are generally clear, and methods are focused. However, macHash is long, mixes initialization, block processing, tail handling, and finalization without helper methods, reducing action granularity and reading flow. The switch statement is compact but uses fall-through intentionally, which requires effort to understand. Nesting is acceptable, but the method length and residual dead code lower clarity significantly. There are also minor inconsistencies (e.g., `offset += Long.BYTES` has an extra space). Overall it is maintainable but hindered by the stray block and long method.

Run 2

The code is essentially unreadable due to a malformed constructor containing a stray, unrelated block of code (a factorial calculation) inserted before the actual constructor logic, causing a structural break. The constructor itself is overly long, performing validation, key extraction, and state initialization in one block, which reduces clarity. While `macHash` is mostly linear, the switch-case fallthrough logic for packing the final bytes is confusing and error-prone to read. Comments are sparse and do not clarify the complex SipHash logic. Action granularity is inconsistent; `sipround()` mixes multiple operations per line. The code has several stylistic issues: inconsistent spacing in offset += `Long.BYTES` and the unrelated code block. Overall, the broken structure, deep fallthrough control flow, and lack of clear separation of concerns make it very difficult to follow.

Run 3

The code has clear intent with good documentation and well-named constants/variables. However, readability is significantly hurt by several issues. The constructor contains a stray, unrelated code block computing a factorial, which is confusing and disrupts structure. The switch statement uses fall-through cases without comments, making the tail-byte handling harder to follow. The macHash method is quite long and mixes multiple concerns (initialization, block processing, tail handling, finalization), reducing action granularity and reading flow. Nesting is moderate but acceptable. Variable names like v0-v3 and m are terse, though some are conventional for the algorithm. The code is mostly flat and concise, but the stray code block and fall-through logic are major readability problems. Overall, it is functional but could be improved with better organization, removal of dead code, and clearer tail-byte handling.

Run 1

Code Structure: Constants, initialization, hashing, and round operations are logically separated, but the unrelated factorial block disrupts the constructor. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: Descriptive configuration names, specification references, and comments explain the purpose; terse state variables, bit manipulation, and undocumented switch fall-through require algorithm knowledge. Code length: Generally appropriate for the algorithm, though the factorial computation is unnecessary and the hashing method is relatively long. Action granularity: Statements consistently perform one action per line, making state updates easy to follow. Reading flow: Initialization, block processing, remainder handling, and finalization follow a natural sequence, but inconsistent indentation in the inserted block and implicit fall-through interrupt readability.

Run 2

Code Structure: Constants, initialization, hashing, and round operations are logically separated, but an unrelated factorial block disrupts the constructor. Nesting: Mostly shallow, with manageable nested loops and conditionals. Clarity of intent: Descriptive configuration names, comments, and the SipHash reference help; terse state variables, unexplained switch fall-through, and ambiguous offset-versus-length handling require careful interpretation. Code length: Reasonably concise for the algorithm, although the unused factorial calculation adds unnecessary code. Action granularity: Statements generally perform one operation per line, making state transformations easy to follow. Reading flow: Initialization, compression, remainder processing, and finalization follow a natural sequence, but inconsistent indentation in the inserted block and insufficient explanation of byte packing interrupt comprehension.

Run 3

Code Structure: Constants, initialization, hashing, and round operations are logically separated, but the unrelated factorial block disrupts the constructor. Nesting: Generally shallow, with manageable loops and conditionals; the extra constructor block adds unnecessary nesting. Clarity of intent: Descriptive configuration names, constants, comments, and the specification link help, while terse state variables, unexplained switch fall-through, and mixed offset/length semantics require careful interpretation. Code length: Mostly appropriate for the algorithm, though the unused factorial calculation is needless. Action granularity: Statements generally perform one operation per line, making state transformations easy to trace. Reading flow: Initialization, compression, tail handling, and finalization follow a natural sequence, but inconsistent indentation in the inserted block and subtle byte-packing expressions interrupt comprehension.