Sample
int-d794ad8dd7a8-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.498 | 0–1; higher is more readable |
| Dorn | 0.302 | 0–1; higher is more readable |
| Mi | 0.319 | 0–1; higher is more readable |
| LLOC | 84 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 11.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.375 | 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. | 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.
| Score | 0.498 |
|---|
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. | 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.
| Score | 0.319 |
|---|
| Score | 84 |
|---|
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.