Sample
Scalabrio172
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.001 | 0–1; higher is more readable | 75.4Δ 22.4 |
| Scalabrino | 0.753 | 0–1; higher is more readable | 78.9Δ 25.9 |
| Dorn | 0.471 | 0–1; higher is more readable | 53.3Δ 0.3 |
| Mi | 0.263 | 0–1; higher is more readable | 53.8Δ 0.8 |
| LLOC | 18 | Logical lines; fewer is more readable | 31.2Δ 21.9 |
| DeepSeek V4 Pro | 9 | 0–20; mean of three runs | 14.6Δ 38.4 |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs | 1.5Δ 51.5 |
| BTTF | 0.634 | 0–1; higher is more readable | 77.9Δ 24.9 |
| Human | 3.67 | 1–5; original rating | 53.0 |
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. | 760.772 | −25.105 |
| Source linesThe number of non-empty source lines. | 38 | +15.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.164 | −6.247 |
Intercept 8.87 + feature contributions = -7.282 (log-odds).
Score = sigmoid(-7.282) = 0.001.
| Score | 0.753 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 108 | +0.938 |
| 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. | 107.974 | −0.908 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.064 | +0.324 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 38 | −0.309 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 18 | −0.115 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 36.706 | +0.103 |
Intercept 0.07 + feature contributions = -0.118 (log-odds).
Score = sigmoid(-0.118) = 0.471.
| Score | 0.263 |
|---|
| Score | 18 |
|---|
Run 1
The code has a clear overall structure with try/finally blocks and barrier synchronization, but readability is significantly reduced by large commented-out blocks that obscure the active logic. The method's intent is unclear due to unused variables (start, runs) and the commented-out loop that would use them. Nesting is minimal (two levels), which is good. Action granularity is inconsistent - some lines are clean single actions, others combine variable declaration and assignment. The reading flow is disrupted by the dead code block in the middle separating related operations. Code length is unnecessarily inflated by the commented section, which should be removed or extracted. Naming is clear for the most part (barrier, isTrace, warmup), though the title() method's purpose is ambiguous. The logic appears incomplete - runs is always 0, making the duration calculation meaningless, and queryItems() appears to be called unconditionally during what seems to be a warmup phase, raising questions about intent.
Run 2
The code has a logical structure with try/finally blocks and clear intent, but suffers from poor readability. The commented-out while loop dominates the method, obscuring the actual active logic and adding confusion. The 'runs' variable is declared and used in calculations but never incremented, making the logic appear incomplete or dead. Nesting is shallow, which is good, but the action granularity is inconsistent - multiple operations appear on single lines, while others are spread across multiple. The reading flow is interrupted by large comment blocks and inconsistent spacing. The method has a clear purpose, but the presence of dormant code and unused variables creates ambiguity about what actually executes. Overall, the code needs significant cleanup to be considered reliably readable.
Run 3
The code suffers from severe readability issues. It contains large blocks of commented-out code (around 20 lines) that clutter the main logic, making it difficult to follow. Dead code is a significant problem here. The 'runs' variable is declared and used in computation but never actually incremented (the commented-out increment exists), meaning the method always returns opsPerMS(duration, 0). This makes the intent highly ambiguous. The line wrapping for the trace call is awkward and splits arguments in unnatural places. The commented-out while loop makes the control flow confusing, leaving the reader unsure whether this was a hot loop, debug scaffolding, or unfinished feature. While the overall structure and nesting are decent, the excessive comments, dead code, and misleading variable usage create a very poor reading flow. Removing the commented-out blocks and clarifying the intended behavior would substantially improve readability. As written, it requires significant mental effort to determine what the code actually does versus what it was intended to do.
Run 1
1. Code Structure: Synchronization, timing, execution, and cleanup have a logical organization, but commented-out code obscures the active implementation. 2. Nesting: Shallow try/finally and conditional nesting is easy to follow, although inconsistent indentation and omitted conditional braces weaken visual clarity. 3. Clarity of intent: Barrier coordination and timing are clear, but runs remains zero, the execution loop is disabled, and the end-time log passes start, making the intended measurement ambiguous. 4. Code length: The active code is concise, but extensive obsolete comments add unnecessary bulk. 5. Action granularity: Each active statement performs one clear action; the wrapped logging call remains readable. 6. Reading flow: The overall sequence is natural, but commented-out blocks interrupt it and make queryItems() appear misleadingly nested.
Run 2
Code Structure: The synchronization, timing, query, and cleanup stages are logically organized, but a large commented-out loop obscures the active implementation. Nesting: Relatively shallow, with a try/finally and simple conditionals; missing braces slightly weaken visual clarity. Clarity of intent: Timing a synchronized execution is apparent, but runs remains zero, the query executes only once, and the end-time log prints start, making the intended measurement ambiguous. Code length: The active code is reasonably concise, but obsolete commented code adds substantial clutter. Action granularity: Each active statement generally performs one action per line. Reading flow: Execution proceeds naturally from waiting to timing to cleanup, but inconsistent indentation and interleaved commented statements interrupt that flow.
Run 3
Code Structure: The synchronization, timing, query, and cleanup phases are logically organized, but a large commented-out loop obscures the active implementation. Nesting: Shallow try/finally and conditional blocks are easy to follow, though inconsistent indentation and omitted braces weaken visual clarity. Clarity of intent: Logging and timing suggest a benchmark, but runs remains zero, and the end-time log prints start, making the intended measurement confusing. Code length: The active code is reasonably concise, but obsolete commented code adds substantial clutter. Action granularity: Statements generally perform one action per line. Reading flow: Execution proceeds naturally from barrier synchronization to measurement and final synchronization, but commented fragments interrupt that flow and make queryItems() appear nested within an inactive loop.