Sample
Scalabrio11
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.004 | 0–1; higher is more readable | 80.4Δ 7.0 |
| Scalabrino | 0.712 | 0–1; higher is more readable | 72.9Δ 0.5 |
| Dorn | 0.807 | 0–1; higher is more readable | 91.5Δ 18.1 |
| Mi | 0.268 | 0–1; higher is more readable | 54.8Δ 18.6 |
| LLOC | 7 | Logical lines; fewer is more readable | 81.7Δ 8.3 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 43.2Δ 30.2 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 58.5Δ 14.8 |
| BTTF | 0.649 | 0–1; higher is more readable | 83.4Δ 10.1 |
| Human | 4 | 1–5; original rating | 73.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. | 405 | −13.365 |
| 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.4 | −6.6 |
| Source linesThe number of non-empty source lines. | 14 | +5.6 |
Intercept 8.87 + feature contributions = -5.495 (log-odds).
Score = sigmoid(-5.495) = 0.004.
| Score | 0.712 |
|---|
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. | 13 | +0.576 |
| 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 | +0.446 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76 | +0.422 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 11 | −0.357 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 12.662 | −0.233 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.086 | +0.109 |
Intercept 0.07 + feature contributions = 1.431 (log-odds).
Score = sigmoid(1.431) = 0.807.
| Score | 0.268 |
|---|
| Score | 7 |
|---|
Run 1
The code has a clear overall purpose but suffers from readability issues. There is a commented-out line that creates ambiguity and should be removed. The method name 'propertyChange' is somewhat generic, though the property name check clarifies intent. The code uses a single level of nesting which is acceptable, but multiple actions are performed inside the nested block, reducing clarity. The method mixes concerns: updating title, setting critiquing root, and updating targets all occur in one block without separation. Line breaks are inconsistent - the chained method call is awkwardly split across lines. The null check is good defensive programming but adds nesting. Magic strings are avoided through constants. Overall, the code is functional but could benefit from extracting the inner block into a well-named private method and removing dead code.
Run 2
The code is reasonably readable but has several issues. The structure is logical, checking a property name and then processing a project, but it suffers from moderate nesting (two levels of if statements) that could be flattened using early returns or guard clauses. Clarity of intent is mixed—the conditional string comparison is clear, but magic strings and commented-out code reduce clarity. The commented-out line should be removed entirely. Code length is appropriate for the task, though the chained method call on evt.getPropertyName() slightly reduces readability. Action granularity is generally good, with one main action per line, but the line calling TargetManager combines multiple operations (getting instance, setting target, getting initial target) on one line. Reading flow is mostly natural, but the nested if structure forces readers to track multiple conditions. Overall, it's functional and understandable but could be more streamlined and cleaner.
Run 3
The code is generally clear and well-structured, with a logical guard-clause pattern that keeps nesting shallow. The intent—reacting to a project change event—is evident from the method name and the check against a named property constant. Each meaningful action sits on its own line, improving readability. However, readability is slightly reduced by the presence of commented-out code, which adds noise without value. The method could be clearer if the nested 'project not null' check were inverted for an early return, though the current structure is acceptable. Overall, the code is concise, maintains good action granularity, and flows naturally from condition check to subsequent updates.
Run 1
Code Structure: Logically organized around a project-change event and its resulting updates. Nesting: Two conditional levels are shallow and easy to follow. Clarity of intent: Constants and method names communicate purpose, though the variable name 'p', unexplained null argument, and commented-out code reduce clarity. Code length: Concise, with little unnecessary content beyond the obsolete commented-out statement. Action granularity: Each active statement performs one distinct action. Reading flow: The sequence from event filtering to project extraction, validation, and updates is natural; the split condition and inconsistent comment relevance introduce minor distractions.
Run 2
Code Structure: Logically organized around checking the changed property and handling the new project. Nesting: Two conditional levels are easy to follow, though guard clauses could flatten the method. Clarity of intent: Descriptive API names and comments explain the project-change response, but the variable name 'p' is terse and the commented-out statement adds noise. Code length: Concise, with little unnecessary code beyond the disabled statement. Action granularity: Each active statement performs one clear operation. Reading flow: The sequence from event filtering to project extraction, null checking, and UI/state updates is natural; the split property-name comparison slightly interrupts scanning.
Run 3
Code Structure: Logically organized around handling a current-project change. Nesting: Two shallow conditional levels are easy to follow, though guard clauses could flatten them. Clarity of intent: Descriptive method calls and the property constant clarify the purpose, but the variable name 'p' is terse and the commented-out statement adds noise. Code length: Compact and appropriate for the task. Action granularity: Each active statement performs one clear action. Reading flow: Actions follow a natural sequence from retrieving the project to updating the title, critiquing root, and target; the split condition and obsolete comment slightly interrupt readability.