Sample
Dorn/java/184
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 1 | 0–1; higher is more readable | 99.4Δ 15.9 |
| Scalabrino | 0.94 | 0–1; higher is more readable | 98.4Δ 14.9 |
| Dorn | 0.796 | 0–1; higher is more readable | 77.4Δ 6.1 |
| Mi | 0.469 | 0–1; higher is more readable | 49.3Δ 34.3 |
| LLOC | 6 | Logical lines; fewer is more readable | 72.8Δ 10.7 |
| DeepSeek V4 Pro | 12.67 | 0–20; mean of three runs | 57.5Δ 26.0 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 73.8Δ 9.7 |
| BTTF | 0.687 | 0–1; higher is more readable | 90.5Δ 7.0 |
| Human | 3.8 | 1–5; original rating | 83.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) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 50 | +20 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 344.917 | −11.382 |
| 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.398 | −6.598 |
Intercept 8.87 + feature contributions = 10.89 (log-odds).
Score = sigmoid(10.89) = 1.
| Score | 0.94 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.017 | +0.777 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 46 | −0.592 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 73.549 | +0.382 |
| 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. | 78 | +0.361 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 12 | −0.322 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 49.772 | +0.286 |
Intercept 0.07 + feature contributions = 1.36 (log-odds).
Score = sigmoid(1.36) = 0.796.
| Score | 0.469 |
|---|
| Score | 6 |
|---|
Run 1
The code is a clean interface definition with clear method names and Javadoc comments. Structure is logical and flat with no nesting. Intent is well-documented for each method. However, there are minor inconsistencies: mixed indentation (tabs vs spaces) for method declarations, a typo in the Javadoc ('statge' instead of 'stage'), and the first method signature shown lacks its Javadoc opening (the comment starts mid-block). These reduce clarity slightly but do not significantly harm readability. Overall the code is concise, follows a natural reading flow, and has appropriate granularity—one clear action per method declaration.
Run 2
The code is an interface definition with clear Javadoc comments for each method, explaining purpose, parameters, and exceptions. The structure is logical and the intent is unambiguous. There is minimal nesting, and each method signature is concise, with one action per conceptual line. The reading flow follows a natural order: initialization, algorithm name, size, update operations, and finalization. However, minor inconsistencies in indentation (e.g., tabs vs spaces before method signatures) and the incomplete opening comment block slightly reduce readability. Overall, it is highly readable for an API definition.
Run 3
This is an interface fragment (likely from a MAC/crypto library) with Javadoc comments, but it is poorly formatted and incomplete. The code structure lacks context—there is no interface declaration or class header, making it hard to evaluate logically. Nesting is minimal (flat), and intent is somewhat clear due to descriptive comments, but the comments contain typos ('statge') and inconsistent indentation. Code length is concise, but action granularity is fine—one method per line. Reading flow is disrupted by mixed tabs/spaces and missing surrounding context. The biggest issues are formatting inconsistency and the absence of enclosing structure, reducing clarity and professionalism. Overall readability is below average despite clear method names.
Run 1
Code Structure: Method declarations are logically organized from initialization through metadata, updates, and finalization. Nesting: The snippet is flat, with no nested control flow. Clarity of intent: Descriptive method names and Javadoc make the MAC API understandable, but getMacSize is misleadingly documented as a cipher block size, and doFinal lacks return-value documentation. Code length: Declarations are concise, though some comments repeat obvious information. Action granularity: Each declaration describes one operation, with exception clauses cleanly separated. Reading flow: The lifecycle ordering is natural, but inconsistent tab/space indentation, the opening orphaned comment terminator, and the typo 'statge' reduce polish. The missing surrounding interface context also makes the fragment slightly harder to interpret.
Run 2
Code Structure: Method declarations are logically organized from initialization and metadata to input updates and finalization. Nesting: There is no nesting, making the interface easy to scan. Clarity of intent: Descriptive method names and Javadoc explain most operations, although getMacSize is misleadingly documented as a cipher block size, the array update lacks a summary, and 'statge' is a typo. Code length: Declarations are concise, though documentation repeats some information. Action granularity: Each declaration represents one operation, with exception clauses clearly separated. Reading flow: The lifecycle ordering is natural, but inconsistent tab/space indentation and the opening orphaned comment terminator reduce polish and make the excerpt appear incomplete.
Run 3
Code Structure: Method declarations are logically organized from initialization and metadata to input updates and finalization. Nesting: The code is flat, with no nested control flow. Clarity of intent: Descriptive method names and Javadoc explain most operations, though getMacSize is misleadingly documented as a cipher block size, the array update lacks a summary, and 'statge' is misspelled. Code length: Declarations are concise; documentation is somewhat repetitive but useful. Action granularity: Each declaration represents one operation, with exception lists clearly separated. Reading flow: The lifecycle ordering is natural, but mixed tabs and spaces and the opening orphaned comment terminator make the fragment less polished.