Sample
JetBrains/b15
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 6.8Δ 3.4 |
| Scalabrino | 0.331 | 0–1; higher is more readable | 16.1Δ 12.7 |
| Dorn | 0.402 | 0–1; higher is more readable | 30.5Δ 27.1 |
| Mi | 0.263 | 0–1; higher is more readable | 17.8Δ 14.4 |
| LLOC | 41 | Logical lines; fewer is more readable | 0.0Δ 3.4 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 32.2Δ 28.8 |
| GPT-6.1 Sol | 12.67 | 0–20; mean of three runs | 5.1Δ 1.7 |
| BTTF | 0.455 | 0–1; higher is more readable | 46.6Δ 43.2 |
| Human | 0.35 | 0–1; original rating | 3.4 |
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. | 1721.457 | −56.808 |
| Source linesThe number of non-empty source lines. | 44 | +17.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. | 2.925 | −4.387 |
Intercept 8.87 + feature contributions = -34.725 (log-odds).
Score = sigmoid(-34.725) = 0.
| Score | 0.331 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 44 | +0.785 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 44 | −0.589 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 44 | −0.522 |
| 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. | 76.955 | +0.406 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 42.744 | +0.188 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.09 | +0.069 |
Intercept 0.07 + feature contributions = -0.398 (log-odds).
Score = sigmoid(-0.398) = 0.402.
| Score | 0.263 |
|---|
| Score | 41 |
|---|
Run 1
The code is generally readable with clear structure and logical organization. It uses a straightforward switch statement for Brainfuck commands, keeping actions on single lines. However, nesting becomes deep within the bracket-handling cases, which hurts readability. The intent is clear overall, but the bracket loops could be extracted into helper methods to improve clarity and reduce nesting. Variable names are mostly concise but some (ptr, i) are terse. The main loop mixes command parsing with control flow in a way that works but could be cleaner. Action granularity is good for simple commands but the complex bracket logic packs multiple operations into dense blocks. Reading flow is mostly natural, though the jump-forward/backward logic interrupts the flow.
Run 2
The code is reasonably structured as a simple Brainfuck interpreter, with a clear main loop and switch statement. However, readability suffers from several issues: the bracket-handling logic is nested and repetitive, making intent harder to follow; the loop for matching brackets is inline, increasing nesting and reducing clarity; there is no validation for unmatched brackets or pointer bounds. Variable names like 'ptr' and 'c' are acceptable but not descriptive. The reading flow is flat overall, but the dense bracket logic interrupts it. Action granularity is mostly one per line, but the bracket cases combine multiple actions. Code length is concise overall, but the duplicated bracket-matching code could be extracted. With better helper methods and comments, it would be more readable.
Run 3
The code is a Brainfuck interpreter with a clear overall structure: setup, program loop, and a switch for eight commands. Nesting is moderate—two levels deep in the bracket-handling logic. Intent is fairly clear due to the straightforward mapping of Brainfuck commands to operations, but the bracket-jumping code is somewhat ambiguous and lacks comments. The length is reasonable for the task, but the bracket cases could be extracted into helper methods for clarity. Action granularity is mostly one action per line, though the bracket loops combine multiple actions on single lines. Reading flow is mostly natural, but the bracket-handling sections require more mental effort to follow than the simple commands. Overall, it is readable but could be improved with helper methods and comments for the bracket jump logic.
Run 1
Code Structure: The interpreter is logically organized around a switch, but bracket scanning is duplicated and all logic resides in main. Nesting: The program loop, instruction loop, switch, conditionals, and bracket-search loops create substantial nesting. Clarity of intent: Brainfuck operations are recognizable, but generic names such as array, ptr, and i require interpretation; the unused Scanner is distracting. Code length: Overall compact, though duplicated bracket handling and the unnecessary programs alias add avoidable code. Action granularity: Several cases combine an operation and break on one line, while bracket cases combine control structures, reducing scanability. Reading flow: Sequential instruction processing is natural, but inconsistent indentation and compressed case formatting interrupt the flow.
Run 2
Code Structure: Initialization and execution are logically organized, but all interpretation and bracket matching reside in main, with duplicated scanning logic. Nesting: The program loop, execution loop, switch, conditionals, and bracket-scanning loops create substantial nesting. Clarity of intent: The class name and command cases establish the purpose, but terse names such as ptr, i, and c and unexplained bracket traversal reduce clarity; the unused Scanner is distracting. Code length: Overall compact, although extracting bracket matching could reduce duplication and improve readability. Action granularity: Several case lines combine an operation and break, while bracket cases combine labels, conditionals, and closing control statements. Reading flow: Command order is natural, but inconsistent indentation and compressed case formatting interrupt scanning, especially around loop handling.
Run 3
Code Structure: The interpreter follows a logical sequence, but all execution and bracket matching reside in main; extracting helpers would improve organization. Nesting: The program loop, instruction loop, switch, conditionals, and bracket-scanning loops create substantial nesting. Clarity of intent: The class name and instruction cases communicate the purpose, but names such as array, ptr, and i require interpretation, and the unused Scanner is distracting. Code length: The implementation is compact, although forward and backward bracket matching duplicate similar logic. Action granularity: Several cases combine a label, operation, and break on one line, reducing visual separation. Reading flow: Sequential instruction processing is natural, but inconsistent indentation and densely formatted bracket cases interrupt scanning.