Sample
Dorn/python/57
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.696 | 0–1; higher is more readable | 83.6Δ 5.0 |
| Scalabrino | 0.524 | 0–1; higher is more readable | 46.5Δ 32.0 |
| Dorn | 0.996 | 0–1; higher is more readable | 100.0Δ 21.4 |
| Mi | 0.837 | 0–1; higher is more readable | 99.4Δ 20.9 |
| LLOC | 6 | Logical lines; fewer is more readable | 72.8Δ 5.7 |
| DeepSeek V4 Pro | 12 | 0–20; mean of three runs | 53.6Δ 24.9 |
| GPT-6.1 Sol | 13.67 | 0–20; mean of three runs | 37.7Δ 40.8 |
| BTTF | 0.664 | 0–1; higher is more readable | 88.0Δ 9.5 |
| Human | 3.73 | 1–5; original rating | 78.6 |
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) |
|---|---|---|
| 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.497 | −6.746 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 160.54 | −5.298 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = 0.827 (log-odds).
Score = sigmoid(0.827) = 0.696.
| Score | 0.524 |
|---|
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. | 0 | +3.665 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 1 | +1.001 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0 | +0.942 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 81.909 | +0.517 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 0 | −0.41 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 5.481 (log-odds).
Score = sigmoid(5.481) = 0.996.
| Score | 0.837 |
|---|
| Score | 6 |
|---|
Run 1
The code is minimal but severely lacks context and meaningful naming. The module docstring is empty, providing no explanation of purpose. The function suite() is not clearly named, and its reliance on globals (DocutilsTestSupport, totest) obscures data flow. The variable 's' is cryptic and reused, while 'suite_settings' and 'generateTests' add some clarity but not enough. The code is concise and flat, but its brevity does not compensate for ambiguous intent and poor readability. It reads more like a scaffolding script than intended production logic. Overall, difficult to understand at a glance.
Run 2
The code is highly readable. It has a clear logical structure with a single function that sets up and returns a test suite. Nesting is minimal to none. The intent is straightforward—create a French language parser test suite. Code length is concise and not unnecessarily long. Each action is cleanly separated into single lines. The reading flow is natural, from function definition to setup, test generation, and return. The only minor deduction is the module-level `totest` dictionary defined after the function, which slightly disrupts conventional top-to-bottom reading order, but this is common in test-support patterns.
Run 3
The code is short and each action is on its own line, yielding good action granularity and reading flow. Nesting is minimal (just a function and dictionary), and the intent—to set up a test suite with French language settings—is fairly clear. However, readability suffers due to missing context: 'DocutilsTestSupport', 'totest', and 'suite_settings' are not defined in the snippet, making the logic ambiguous without external files. The empty module docstring and 'totest = {}' placed after the function also disrupt logical organization. Overall, the structure is straightforward but incomplete context limits clarity.
Run 1
Code Structure: The suite factory and test-data dictionary are logically separated, although defining totest before suite would make the dependency clearer. Nesting: Flat and easy to follow. Clarity of intent: ParserTestSuite and generateTests communicate the testing purpose, but s and totest are vague names. The leading, unclosed triple quote makes the snippet invalid as shown and obscures whether the following lines are intended as code or text. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs one clear action. Reading flow: Mostly natural, though the unexplained opening quote and reference to a later-defined dictionary interrupt comprehension.
Run 2
Code Structure: The intended organization is simple: import support, define a suite factory, and initialize test data. However, the opening triple quote is unclosed, making the snippet invalid Python as shown and obscuring whether it is code or documentation. Nesting: Only one indentation level, so it is easy to follow. Clarity of intent: The suite creation and test generation are understandable, but names such as 's' and 'totest' are vague, and the empty test dictionary provides little context. Code length: Concise, with no unnecessary logic. Action granularity: Each statement performs a single main action. Reading flow: Mostly natural, although defining 'totest' before the function would make its dependency easier to discover. More descriptive names and conventional spacing in the settings dictionary would improve readability.
Run 3
Code Structure: The intended import, suite factory, and test dictionary are logically organized, though the opening triple quote is unterminated and prevents parsing. Nesting: Only one function level, making the snippet easy to follow. Clarity of intent: Creating a French-language parser test suite is clear, but 's' and 'totest' are vague names, and the empty dictionary leaves test coverage unclear. Code length: Concise without unnecessary statements. Action granularity: Each statement performs one action. Reading flow: Mostly natural, though defining 'totest' before the function would make its dependency more immediately visible; inconsistent spacing and the stray triple quote reduce readability.