Sample
Dorn/java/150
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 56.3Δ 14.8 |
| Scalabrino | 0.863 | 0–1; higher is more readable | 93.0Δ 22.0 |
| Dorn | 0.735 | 0–1; higher is more readable | 69.6Δ 1.4 |
| Mi | 0.458 | 0–1; higher is more readable | 47.4Δ 23.7 |
| LLOC | 25 | Logical lines; fewer is more readable | 21.4Δ 49.6 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 87.9Δ 16.9 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 66.0Δ 5.0 |
| BTTF | 0.674 | 0–1; higher is more readable | 89.4Δ 18.4 |
| Human | 3.61 | 1–5; original rating | 71.0 |
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. | 909.583 | −30.016 |
| 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.611 | −6.916 |
Intercept 8.87 + feature contributions = -8.063 (log-odds).
Score = sigmoid(-8.063) = 0.
| Score | 0.863 |
|---|
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. | 64.961 | +0.914 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 46 | +0.854 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 51 | −0.769 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 46 | −0.635 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 49.576 | +0.283 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 64.961 | +0.244 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.091 | +0.061 |
Intercept 0.07 + feature contributions = 1.022 (log-odds).
Score = sigmoid(1.022) = 0.735.
| Score | 0.458 |
|---|
| Score | 25 |
|---|
Run 1
The code is highly readable. It consists of simple getter methods with clear, descriptive names and consistent structure. The hashCode and equals methods follow standard Java patterns with proper use of @Override and Javadoc references. Nesting is minimal, with only a few conditional checks in equals that use early returns, which aids readability. Each line performs a single logical action, and the reading flow is natural: getters first, then object comparison methods. The only minor deductions are for slight inconsistency in formatting (e.g., tabs vs spaces in the getters) and the fact that the code fragment appears to start mid-class, lacking surrounding context. The equals method could be marginally shorter by combining conditions, but the current style is explicit and clear. Overall, intent is unambiguous and the structure is logical.
Run 2
The code is generally readable and well-structured. It consists of simple getter methods that are concise and clear, each returning a single field. The action granularity is appropriate—one action per line. The hashCode and equals methods are standard implementations with reasonable formatting and minimal nesting. The equals method has some level of nesting due to multiple conditional checks, but it remains flat and logical. The use of @Override annotations and Javadoc comments improves clarity of intent. However, the code snippet begins mid-class with a stray return statement, which slightly disrupts reading flow. Additionally, the equals method could be simplified or made more concise, but overall the code is maintainable and easy to follow. Score deducted for the incomplete context and slightly verbose equals method.
Run 3
The code consists of simple getters and standard equals/hashCode implementations. Structure is logical with clear separation of methods. Nesting is minimal, with only two simple conditional branches in equals. Intent for each method is immediately apparent from names. Code length is appropriately concise, though the equals method could be slightly simplified. Action granularity is good—one operation per line. Reading flow is natural. Minor deductions: inconsistent formatting/indentation between getters and later methods, and the equals method contains slightly redundant logic (checking simple name equality after already checking class equality).
Run 1
Code Structure: Getters and equality-related methods are logically grouped, though the snippet starts midway through a method and mixes formatting styles. Nesting: Minimal nesting and early returns keep control flow flat. Clarity of intent: Descriptive getter names and familiar equals/hashCode patterns make the purpose clear, although superclass dependencies and differing fields used by equals and hashCode require additional context. Code length: Concise overall, with repetitive getter boilerplate and a final conditional that could be simplified. Action granularity: Each statement performs a single action, making individual operations easy to follow. Reading flow: Predictable method boundaries and straightforward comparisons support natural reading, but inconsistent indentation, brace placement, and unbraced conditionals slightly reduce readability.
Run 2
Code Structure: Getters and equality methods are logically grouped, but the snippet starts mid-method and indentation styles vary. Nesting: Flat methods and early returns keep nesting minimal. Clarity of intent: Getter names and standard overrides communicate purpose clearly; however, hashCode uses _autoIncrement while equals compares getSimpleName(), making their relationship harder to understand without superclass context. Code length: Mostly concise, though equals could return the final comparison directly, and the @see comments add little information. Action granularity: Each line generally performs one action. Reading flow: Straightforward top-to-bottom flow, slightly weakened by inconsistent brace formatting and unbraced conditionals.
Run 3
Code Structure: Getters and equality-related methods are logically grouped, but the snippet starts mid-method and indentation is inconsistent. Nesting: Early returns keep equals flat and easy to scan. Clarity of intent: Getter names and standard overrides communicate purpose clearly, though the different fields used by equals and hashCode make their relationship unclear. Code length: Mostly concise, with repetitive boilerplate and a final conditional that could be a direct boolean return. Action granularity: Each statement performs one action, aiding readability. Reading flow: The sequence is natural, but mixed brace styles, unbraced conditionals, and the incomplete opening slightly disrupt it.