Sample
int-a673a2b9265a-I08
Select one of ten high-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.535 | 0–1; higher is more readable |
| Dorn | 0.29 | 0–1; higher is more readable |
| Mi | 0.327 | 0–1; higher is more readable |
| LLOC | 88 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 7.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.331 | 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. | 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.
| Score | 0.535 |
|---|
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. | 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.
| Score | 0.327 |
|---|
| Score | 88 |
|---|
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.