Sample
int-17883390bee2-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.495 | 0–1; higher is more readable |
| Dorn | 0.29 | 0–1; higher is more readable |
| Mi | 0.305 | 0–1; higher is more readable |
| LLOC | 90 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.304 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.495 |
|---|
Feature contributions
| Feature | Value | Contribution (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.
| Score | 0.305 |
|---|
| Score | 90 |
|---|
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.