Source code
Official dataset source · Dorn/java/190
Sample
Dorn/java/190
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 1 | 0–1; higher is more readable | 99.2Δ 19.8 |
| Dorn | 0.915 | 0–1; higher is more readable | 95.5Δ 16.2 |
| Mi | 0.604 | 0–1; higher is more readable | 63.5Δ 15.9 |
| LLOC | 1 | Logical lines; fewer is more readable | 97.9Δ 18.5 |
| DeepSeek V4 Pro | 9.67 | 0–20; mean of three runs | 39.4Δ 40.0 |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs | 58.6Δ 20.8 |
| BTTF | 0.846 | 0–1; higher is more readable | 98.1Δ 18.7 |
| Human | 3.73 | 1–5; original rating | 79.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) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 30 | +12 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.021 | −7.531 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 86.37 | −2.85 |
Intercept 8.87 + feature contributions = 10.489 (log-odds).
Score = sigmoid(10.489) = 1.
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. | 1 | +1.001 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.011 | +0.84 |
| 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. | 79.968 | +0.486 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| 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 | +0.277 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 29.951 | +0.009 |
Intercept 0.07 + feature contributions = 2.377 (log-odds).
Score = sigmoid(2.377) = 0.915.
| Score | 0.604 |
|---|
| Score | 1 |
|---|
Run 1
The code is a license header followed by two clean imports. It is logically organized with a clear separation between documentation and code. The header is verbose and contains minor errors (e.g., 'Foobar' instead of 'sqsc-isqlj'), but this does not affect code readability. Imports are specific and concise. There is no nesting or complex logic, so nesting and action granularity are optimal. The reading flow is natural: header, then imports. The only deductions are for the overly long license block and the typo, which slightly reduce clarity and conciseness.
Run 2
The code consists solely of a license header and two import statements. There is no executable code, class definition, or logic to evaluate against most criteria (structure, nesting, clarity of intent, action granularity, reading flow). The header is bloated and contains factual errors (references to 'Foobar' instead of the actual project name), which reduces clarity. The code length is unnecessary for what little content exists. Without substantive code, readability cannot be meaningfully assessed beyond noting the poor organization and misleading documentation.
Run 3
The code consists entirely of a license/header comment and two import statements. Structure is straightforward but there is no substantive logic to evaluate. The comment block is excessively long and contains errors ('Foobar' instead of 'sqsc-isqlj', inconsistent formatting), which hurts clarity and readability. Import ordering is logical but trivial. Nesting is absent. Overall, while the actual code is simple, the bloated and flawed header undermines readability and professionalism.
Run 1
Code Structure: A header followed by two imports is logically organized, though there is no implementation to assess. Nesting: No nesting makes the snippet easy to scan. Clarity of intent: The description and import names suggest a SquirrelSQL plugin, but the inconsistent reference to 'Foobar' creates ambiguity. Code length: The lengthy, HTML-heavy license header overwhelms the minimal code. Action granularity: Each import occupies its own line. Reading flow: The imports are straightforward, but repeated HTML tags and blank-line markup interrupt the header's flow.
Run 2
Code Structure: A header followed by two imports is logically organized, though the HTML-heavy comment adds clutter. Nesting: There is no executable nesting. Clarity of intent: The header identifies the plugin and licensing, but inconsistent references to 'Foobar' introduce ambiguity; no implementation is present to reveal behavior. Code length: The lengthy header dominates this tiny snippet, with redundant HTML breaks and formatting. Action granularity: Each import occupies its own line, and there are no combined actions. Reading flow: The imports are straightforward, but the verbose header delays reaching meaningful code. Overall, the snippet is easy to scan structurally but provides limited functional context.
Run 3
Code Structure: The header followed by imports is logically organized, although there is no implementation to assess. Nesting: There is no nesting, making the snippet easy to scan. Clarity of intent: The project description and explicit imports provide context, but the inconsistent 'Foobar' references introduce ambiguity. Code length: The lengthy, HTML-heavy license header overwhelms the two substantive lines. Action granularity: Each import occupies its own line; no actions are combined. Reading flow: The sequence is natural, but repeated HTML tags and blank comment lines create visual clutter.