Sample
Dorn/java/147
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.733 | 0–1; higher is more readable | 84.4Δ 10.0 |
| Scalabrino | 0.85 | 0–1; higher is more readable | 91.5Δ 17.1 |
| Dorn | 0.85 | 0–1; higher is more readable | 85.5Δ 11.1 |
| Mi | 0.788 | 0–1; higher is more readable | 97.2Δ 22.8 |
| LLOC | 18 | Logical lines; fewer is more readable | 38.4Δ 35.9 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 87.9Δ 13.5 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 66.0Δ 8.4 |
| BTTF | 0.642 | 0–1; higher is more readable | 83.6Δ 9.2 |
| Human | 3.65 | 1–5; original rating | 74.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) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 640.247 | −21.128 |
| 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.487 | −6.731 |
Intercept 8.87 + feature contributions = 1.011 (log-odds).
Score = sigmoid(1.011) = 0.733.
| Score | 0.85 |
|---|
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. | 48 | −0.663 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 40 | +0.646 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.961 | +0.615 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.442 |
| 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. | 49.753 | +0.286 |
| 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. | 87.961 | −0.06 |
Intercept 0.07 + feature contributions = 1.733 (log-odds).
Score = sigmoid(1.733) = 0.85.
| Score | 0.788 |
|---|
| Score | 18 |
|---|
Run 1
The code is well-structured and generally readable. It has a clear class purpose, flat logical organization, and mostly one action per line. Methods are short and follow a natural flow, with clear getter/setter patterns for title and hint. The use of underscore-prefixed fields is conventions from older code but consistent here. There is minimal nesting; only one conditional exists and it is trivial. However, readability is slightly reduced by comments that are empty or boilerplate and by a minor naming inconsistency where a method like `setTitle` exists without an accompanying `setHint`. Additionally, the field `_myscrolledPanel` has a slightly awkward name, and some methods leave behavior implicit (e.g., `applyChanges` with null check) rather than documenting intention. Still, the code is concise, easy to scan, and logically coherent.
Run 2
The code is highly readable with clear structure and purpose. Class organization is logical, methods are well-named and follow a consistent pattern. Nesting is minimal with only one conditional statement. Intent is clear - this is a preferences tab wrapper for a scrollable panel with title and hint properties. Code length is appropriately concise. Each method performs a single action. The reading flow is natural: constructor, lifecycle methods, then getters/setters. Minor deductions: unused imports may exist, empty lifecycle methods could benefit from explanatory comments, and the field naming with underscore prefixes is slightly dated. The Javadoc comments on getters are incomplete but don't significantly impact readability. Overall, this is clean, maintainable code that effectively communicates its purpose without unnecessary complexity.
Run 3
The code is generally clear and well-structured, with a simple class implementing an interface. Each method performs a single action, and methods are concise. The use of protected fields and a constructor is logical. However, there are some readability issues: the Javadoc comments are stubs (non-Javadoc) and add little value, the field naming with underscores is inconsistent with common Java conventions, and the initialize/uninitialize methods are empty with 'Do Nothing' comments, which might confuse intent. The code could be improved by using standard naming conventions, removing unnecessary comments, and clarifying why certain methods are empty. The nesting is minimal and the reading flow is straightforward, which keeps the score above average.
Run 1
Code Structure: Fields, constructor, lifecycle methods, and accessors are logically grouped, though the snippet ends without the class's closing brace. Nesting: Very shallow, with only one simple conditional. Clarity of intent: The preferences-panel wrapper and change delegation are clear; abbreviated names such as _prefs and _myscrolledPanel are less descriptive. Code length: Mostly concise, but redundant null initializations and generated Javadoc comments add clutter. Action granularity: Each statement performs a single action, making operations easy to follow. Reading flow: Conventional formatting and straightforward methods support natural reading, although inconsistent field naming and the incomplete ending reduce polish.
Run 2
Code Structure: Fields, constructor, lifecycle methods, and accessors are logically organized. Nesting: Very shallow, with only one simple conditional. Clarity of intent: Class and method names communicate a preferences-panel wrapper, though abbreviated fields such as _prefs and the awkward _myscrolledPanel reduce clarity. Code length: Mostly concise, but explicit null initializers and generated Javadoc comments add unnecessary noise. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: Conventional ordering and consistent formatting support smooth reading, although extra whitespace and boilerplate comments interrupt it slightly. The provided snippet ends without the class-closing brace, making it appear incomplete.
Run 3
Code Structure: Fields, constructor, lifecycle methods, and accessors are logically organized. Nesting: Nearly flat, with only a simple null check. Clarity of intent: Class and method names communicate a preferences-panel wrapper, though abbreviated fields such as _prefs and _myscrolledPanel are less descriptive. Code length: Concise overall, but generated non-Javadoc comments and explicit null initializers add noise. Action granularity: Each statement performs one action, making individual operations easy to follow. Reading flow: Conventional Java layout supports natural reading, although inconsistent spacing and naming reduce polish. The excerpt ends without the class's closing brace, leaving its completeness unclear.