Source code
Official dataset source · Dorn/java/185
Sample
Dorn/java/185
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.451 | 0–1; higher is more readable | 80.8Δ 31.2 |
| Dorn | 0.482 | 0–1; higher is more readable | 40.9Δ 8.6 |
| Mi | 0.724 | 0–1; higher is more readable | 88.6Δ 39.0 |
| LLOC | 4 | Logical lines; fewer is more readable | 82.7Δ 33.1 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 84.5Δ 35.0 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 93.5Δ 43.9 |
| BTTF | 0.564 | 0–1; higher is more readable | 64.3Δ 14.8 |
| Human | 3.34 | 1–5; original rating | 49.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.527 | −6.79 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 190.165 | −6.275 |
| Source linesThe number of non-empty source lines. | 10 | +4 |
Intercept 8.87 + feature contributions = -0.196 (log-odds).
Score = sigmoid(-0.196) = 0.451.
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. | 57.727 | +1.22 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 9 | +0.718 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 1 | −0.703 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.169 | −0.697 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 9.814 | −0.273 |
Intercept 0.07 + feature contributions = -0.071 (log-odds).
Score = sigmoid(-0.071) = 0.482.
| Score | 0.724 |
|---|
| Score | 4 |
|---|
Run 1
The code is highly readable. It has a clear, linear structure with no unnecessary nesting or branching. The intent is immediately obvious: retrieve a NAT puncher and use it. Each action is on its own line, improving clarity. The only minor deductions are for slightly redundant blank lines and the unnecessary wrapping of return values in parentheses, but these are trivial style preferences that do not impact readability.
Run 2
The code is fairly readable due to its flat structure, clear intent (obtaining a NAT puncher and invoking punch), and concise length. It uses one action per line and has natural reading flow. However, it loses points for stylistic inconsistencies: unnecessary blank lines, non-standard `return( ... )` parentheses, and a somewhat abrupt null-check pattern. The logic is straightforward and easy to follow, but could be improved with cleaner formatting and more idiomatic style.
Run 3
The code is highly readable with clear structure and purpose. It uses a flat nesting structure with only one conditional level. The intent is obvious: retrieve a DHT NAT puncher and use it to punch a tunnel. The method names are descriptive ('getNATPuncher', 'punch'), and the action granularity is good, with one logical operation per line. However, the code is slightly verbose: unnecessary blank lines and parentheses around return values reduce conciseness and interrupt the natural reading flow. Removing these stylistic artifacts would improve readability further. Overall, the logic is straightforward and easy to follow.
Run 1
Code Structure: Logically organized into retrieval, a null guard, and the final operation. Nesting: Minimal; the early return avoids deeper nesting. Clarity of intent: The NAT-punching purpose is apparent from the names, though the meaning of "Tunnel" and the two null arguments is not explained. Code length: Concise, with no unnecessary logic; extra blank lines add slight visual bulk. Action granularity: Each statement performs one clear action. Reading flow: Natural and sequential, with the missing-puncher case handled before use. Unconventional spacing and parenthesized return expressions slightly reduce readability.
Run 2
Code Structure: logically organized into retrieval, a null guard, and the final operation. Nesting: shallow, with an early return avoiding further nesting. Clarity of intent: obtaining a NAT puncher and initiating a tunnel punch is clear, though the two null arguments and missing method signature leave some context unspecified. Code length: concise, with no unnecessary logic. Action granularity: each statement performs one main action. Reading flow: natural and sequential; extra blank lines and unconventional spacing around parentheses slightly reduce polish.
Run 3
Code Structure: Logically organized into retrieval, a null guard, and the final operation. Nesting: Shallow; the early return avoids unnecessary branching. Clarity of intent: The NAT-punching purpose is apparent, although the meaning of "Tunnel" and the two null arguments is not explained. Code length: Concise, with slightly excessive blank lines. Action granularity: Each statement performs one primary action. Reading flow: Natural and sequential, though unconventional spacing and parenthesized return expressions add minor visual clutter.