Sample
Scalabrio200
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 13.1Δ 14.3 |
| Scalabrino | 0.096 | 0–1; higher is more readable | 6.5Δ 20.9 |
| Dorn | 0.41 | 0–1; higher is more readable | 46.2Δ 18.8 |
| Mi | 0.695 | 0–1; higher is more readable | 91.5Δ 64.1 |
| LLOC | 33 | Logical lines; fewer is more readable | 2.0Δ 25.4 |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs | 35.2Δ 7.8 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 19.6Δ 7.8 |
| BTTF | 0.51 | 0–1; higher is more readable | 42.2Δ 14.8 |
| Human | 3.22 | 1–5; original rating | 27.4 |
Views
Select the downloaded ZIP or its extracted folder. Files stay in your browser.
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. | 1642.064 | −54.188 |
| Source linesThe number of non-empty source lines. | 41 | +16.4 |
| 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.525 | −6.787 |
Intercept 8.87 + feature contributions = -35.705 (log-odds).
Score = sigmoid(-35.705) = 0.
| Score | 0.096 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 32.927 | +2.271 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.233 | −1.322 |
| 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. | 1 | −0.703 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 41 | −0.415 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 39.559 | +0.143 |
Intercept 0.07 + feature contributions = -0.362 (log-odds).
Score = sigmoid(-0.362) = 0.41.
| Score | 0.695 |
|---|
| Score | 33 |
|---|
Run 1
The code has a flat structure and is organized in logical entity cleanup sections, which is good. Variable names (b, c, d, e, f, g) are concise but lack clarity, making intent ambiguous without external context. Each line mostly performs one action, but some lines combine multiple actions (e.g., chaining remove() calls). Grouping session operations after entity cleanup improves reading flow, though repetitive merge/delete lines add length without much explanation. Overall, it is readable to someone familiar with the domain, but unclear naming and lack of comments reduce clarity.
Run 2
The code demonstrates a clear, linear structure with one action per line, contributing to readability. Variable names (b, c, d, e, f, g) and collection getter methods make the graph relationships somewhat inferable but remain ambiguous in purpose without domain context. While nesting is minimal, the repetitive removal and nulling patterns make the code feel somewhat verbose and could be extracted into helper methods. The transaction cleanup section is well-sequenced and readable, but the overall intent relies on implicit conventions (e.g., knowing what 'cleanup' entails). Seven single-letter variable names significantly reduce clarity. Overall, it's understandable but not inherently self-documenting.
Run 3
The code is logically organized in two phases: clearing in-memory references and persisting deletions, which aids intent clarity. However, the heavy use of single-letter variable names (b, c, d, e, f, g) makes it highly ambiguous and hard to follow without external context. Nesting is flat and action granularity is generally good, with one action per line. Reading flow is improved by blank-line separation between phases, but the terse naming and repetitive accessor removal calls make it dense. Code length is moderate but could be clearer with descriptive names or helper methods. The session block is straightforward, yet merging and deleting with generic names obscures relationships between entities. Overall, it is not tangled but suffers from poor naming and assumed domain knowledge, reducing readability.
Run 1
Code Structure: Relationship cleanup is logically grouped by entity, followed by session setup, merging, deletion, and transaction completion. Nesting: The method is flat and easy to scan. Clarity of intent: The cleanup name and @After annotation establish the purpose, but single-letter entity and session names obscure domain meaning; the relationship updates and deletion order are unexplained. Code length: Reasonably concise, although repeated merge and delete statements add some verbosity. Action granularity: Each line contains one primary operation, making individual steps easy to follow. Reading flow: Blank lines separate entity cleanup blocks effectively, and transaction operations follow a natural sequence, but the change in entity order during deletion interrupts the otherwise consistent flow.
Run 2
Code Structure: Relationship cleanup is grouped by entity, followed by a distinct persistence phase, providing logical organization. Nesting: The method is entirely flat and easy to scan. Clarity of intent: The @After annotation and cleanup name convey teardown, but single-letter entity and session names obscure domain meaning; the relationship operations and deletion order are unexplained. Code length: Reasonably concise for the work performed, though repetitive merge and delete statements add visual bulk. Action granularity: Each statement performs one primary action, making individual changes easy to follow. Reading flow: Blank lines separate entity groups, and execution progresses naturally from unlinking relationships to merging, deleting, committing, and closing. However, understanding dependencies requires tracing associations across several groups.
Run 3
Code Structure: Cleanup is logically organized into relationship removal, entity merging, and deletion, with blank lines grouping related entities. Nesting: The method is entirely flat and easy to scan. Clarity of intent: @After and cleanup() establish the purpose, but single-letter entity and session names obscure domain meaning; the relationship changes and deletion order lack explanation. Code length: Reasonably concise for explicit cleanup, although repetitive merge and delete calls add length. Action granularity: Each statement performs one clear action, making individual operations easy to follow. Reading flow: Execution proceeds naturally from unlinking relationships to persisting changes and deleting entities, but the transition into session handling and the differing deletion order slightly interrupt the flow.