Sample
Dorn/python/3
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 9.2Δ 53.2 |
| Scalabrino | 0.52 | 0–1; higher is more readable | 46.1Δ 16.3 |
| Dorn | 0.308 | 0–1; higher is more readable | 24.8Δ 37.6 |
| Mi | 0.262 | 0–1; higher is more readable | 25.3Δ 37.0 |
| LLOC | 34 | Logical lines; fewer is more readable | 5.4Δ 57.0 |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs | 51.4Δ 11.0 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 66.0Δ 3.6 |
| BTTF | 0.511 | 0–1; higher is more readable | 47.9Δ 14.5 |
| Human | 3.48 | 1–5; original rating | 62.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. | 2474.422 | −81.656 |
| Source linesThe number of non-empty source lines. | 50 | +20 |
| 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.445 | −6.667 |
Intercept 8.87 + feature contributions = -59.453 (log-odds).
Score = sigmoid(-59.453) = 0.
| Score | 0.52 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 49 | +0.958 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 50 | −0.727 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 47 | −0.628 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 49.463 | +0.282 |
| 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. | 80.961 | +0.236 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.117 | −0.194 |
Intercept 0.07 + feature contributions = -0.807 (log-odds).
Score = sigmoid(-0.807) = 0.308.
| Score | 0.262 |
|---|
| Score | 34 |
|---|
Run 1
The code has a logical structure with clear class and method organization, making it easy to follow the test scenarios. However, it suffers from excessive line breaks and indentation issues in lambda expressions and method calls, which disrupts the reading flow. Several statements are split across multiple lines unnecessarily (e.g., `self.assertDoUndoRedo(lambda: self.assertEqual(...))`), and some continuation lines are awkwardly indented. The nesting is moderate, but the formatting makes it feel more fragmented than it should be. Intent is mostly clear due to descriptive method names, but action granularity varies — some lines mix multiple actions while others are overly broken. Overall, readable but not polished.
Run 2
The code has several readability issues. Structure is reasonable but inconsistent indentation and spacing disrupt flow. Nesting is moderate but lambdas with multiple assertions are hard to follow. Intent is somewhat clear but ambiguous in parts, especially without command implementations. Length is acceptable but some lines are unnecessarily long or poorly wrapped. Action granularity varies - some lines contain multiple actions, others are well-separated. Reading flow suffers from inconsistent formatting and mixed abstraction levels. The dragAndDrop method has confusing parameter ordering and the test methods lack descriptive docstrings. Overall, the code is functional but needs better formatting consistency, clearer naming, and more focused action granularity to improve readability.
Run 3
The code is moderately readable but has several issues. Structure is logical with clear test classes and setup methods, but nesting is minimal and action granularity is mostly one action per line. Clarity of intent is good in method names like 'testCannotDropOnParent', but some lambdas and method calls obscure purpose slightly. Code length is concise but sometimes at the expense of readability, with lambda expressions spanning multiple lines awkwardly. Reading flow is natural overall but interrupted by inconsistent indentation and multi-line lambda formatting. The 'dragAndDrop' method signature is clear, but the call to 'DragAndDropCategoryCommand' mixes positional and keyword args. Some assertions use 'failIf' which is less common than 'assertFalse'. Overall, the code is functional but could benefit from cleaner lambda usage and more consistent formatting.
Run 1
Code Structure: Test classes, setup methods, and helpers logically group related behavior, though the excerpt starts mid-method and ends with setup only. Nesting: Flat methods and minimal control flow make the code easy to follow. Clarity of intent: Descriptive test names and parent/child/grandchild variables clearly communicate scenarios; assertDoUndoRedo lambdas require some interpretation. Code length: Short methods and a shared dragAndDrop helper keep the code concise, with reasonable repetition across distinct tests. Action granularity: Most lines perform one action, although chained command construction/execution and inline assertion lambdas compress multiple operations. Reading flow: Setup followed by scenario-specific tests is natural, but inconsistent continuation indentation, awkward lambda wrapping, and excess blank-space formatting interrupt scanning.
Run 2
Code Structure: Test classes and helper methods organize scenarios logically, though the excerpt starts mid-method and ends with an incomplete class. Nesting: Minimal nesting makes execution easy to follow. Clarity of intent: Descriptive test names and parent/child fixtures communicate expected behavior; lambdas and external assertion helpers require some contextual knowledge. Code length: Concise overall, with modest repetition that keeps individual tests explicit. Action granularity: Most lines perform one action, although command construction and execution are chained, and undo/redo assertions combine multiple checks in one call. Reading flow: Setup followed by focused tests is natural, but inconsistent continuation indentation, awkward lambda wrapping, and excess whitespace interrupt readability.
Run 3
Code Structure: Test classes, setup methods, and a reusable drag-and-drop helper provide logical organization, though the excerpt starts mid-method. Nesting: Minimal nesting makes individual tests easy to follow. Clarity of intent: Descriptive test names and parent/child fixtures communicate most scenarios clearly; testDropAsRootTask is confusing in category tests, and lambda-based undo/redo assertions require some interpretation. Code length: Short methods and shared helpers keep the code concise, with modest repetition across invalid-drop tests. Action granularity: Most lines perform one action, although chained command construction/execution and multiple inline callbacks pack operations together. Reading flow: Setup followed by action and assertion is natural, but inconsistent continuation indentation, awkward lambda wrapping, and excess blank lines interrupt scanning.