Sample
Schnappinger/argoUML/org.argouml.uml.reveng.ui.ImportStatusScreen
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 26.1Δ 51.0 |
| Scalabrino | 0.825 | 0–1; higher is more readable | 68.8Δ 8.2 |
| Dorn | 0.038 | 0–1; higher is more readable | 26.7Δ 50.3 |
| Mi | 0.56 | 0–1; higher is more readable | 45.5Δ 31.5 |
| LLOC | 102 | Logical lines; fewer is more readable | 24.6Δ 52.5 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 26.9Δ 50.2 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 51.3 |
| BTTF | 0.428 | 0–1; higher is more readable | 37.0Δ 40.1 |
| Human | 3.96 | 1–4; original rating | 77.1 |
Views
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. | 7905.735 | −260.889 |
| Source linesThe number of non-empty source lines. | 281 | +112.4 |
| 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.891 | −7.337 |
Intercept 8.87 + feature contributions = -146.956 (log-odds).
Score = sigmoid(-146.956) = 0.
| Score | 0.825 |
|---|
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. | 282 | −8.948 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 209 | +6.492 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 209 | −4.375 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 280.952 | +3.517 |
| 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. | 122.989 | −1.544 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 122.979 | +1.18 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.059 | +0.368 |
Intercept 0.07 + feature contributions = -3.241 (log-odds).
Score = sigmoid(-3.241) = 0.038.
| Score | 0.56 |
|---|
| Score | 102 |
|---|
Run 1
The code has a clear, logical class structure and reasonably flat nesting, with method names indicating intent. However, it suffers from verbose Swing layout code, redundant threading wrappers, and inconsistent formatting. The constructor is long and mixes multiple concerns. Some logic (e.g., isComplete checking progress values) is fragile. Action granularity is mostly one per line, but notification message concatenation is cramped. Reading flow is impaired by scattered comments, unused parameters, and dead code. Overall, it is maintainable but not highly readable.
Run 2
The code is moderately readable. It has clear structure with separated UI setup, action listeners, and method implementations. However, several issues reduce readability: the constructor is quite long with many GridBagConstraints manipulations, which is inherently difficult to follow. There are commented-out lines that add noise. Some methods like notifyMessage concatenate strings without spacing, making intent less clear. Threading via SwingUtilities.invokeLater adds nesting. WindowListener methods are empty (noise) and could be handled differently. The double license header is excessive and distracting. Variable naming is generally clear, but the empty interface implementations and boolean flag toggling ('hasMessages') obscure control flow. Reading flow is logical but interrupted by boilerplate. The code would benefit from extracting UI setup into helper methods and cleaning up comments.
Run 3
The code has reasonable structure with clear separation of UI components and methods, but suffers from several readability issues. The constructor is long and mixes layout logic with component setup, making it harder to follow. GridBagConstraints setup is verbose and repetitive, with commented-out code adding noise. The nesting level is moderate but acceptable. Intent is generally clear through method names like 'updateProgress' and 'notifyMessage', though the class name 'ImportStatusScreen' could be more specific about its dual progress/dialog role. Action granularity is mostly good, but some lines like the messageArea.setText concatenation are unnecessarily dense. The reading flow is disrupted by excessive copyright headers (over 40 lines), unused WindowListener methods, and a serialVersionUID placed mid-class. The code follows Java conventions but would benefit from extracting layout setup into helper methods, removing dead code, and reducing header noise.
Run 1
Code Structure: Clearly scoped class with separate progress, messaging, cancellation, and window-handling methods, but the constructor combines extensive layout setup and event wiring. Nesting: Generally shallow; anonymous Runnable classes and nested completion checks add moderate depth. Clarity of intent: Descriptive method and field names explain most behavior, though generic parameters, an unused iconName, stale TODOs, and a threading guarantee contradicted by notifyMessage reduce clarity. Code length: Swing boilerplate, repeated invokeLater wrappers, empty listener methods, and redundant comments make the class longer than necessary. Action granularity: Most statements perform one action, with layout assignments easy to inspect individually. Reading flow: Initialization proceeds naturally from labels to progress bar, messages, and buttons, followed by operational methods. However, mutable layout constraints, the mid-class serialVersionUID declaration, commented-out code, and repetitive documentation interrupt the flow.
Run 2
Code Structure: Cohesive dialog class with clearly separated progress, messaging, and window-handling methods, though the constructor mixes layout setup and event behavior. Nesting: Mostly shallow; anonymous Runnable classes and nested completion checks add moderate indentation. Clarity of intent: Descriptive method and field names make the purpose clear, but generic variables, an unused iconName parameter, and documentation contradicting actual threading and close behavior reduce clarity. Code length: Verbose Swing setup and repeated invokeLater wrappers increase length; commented-out code and stale comments add noise. Action granularity: Generally one operation per line, with compact empty callbacks as minor exceptions. Reading flow: UI construction follows a natural sequence, and short methods are easy to scan, but repeated boilerplate and the serialVersionUID declaration among methods interrupt the flow.
Run 3
Code Structure: Fields and focused methods are logically organized, but the constructor mixes layout, event handling, and window configuration. Nesting: Mostly shallow; anonymous Runnable classes and nested completion checks add moderate depth. Clarity of intent: Descriptive names and familiar Swing patterns communicate purpose, though generic parameters, an unused iconName, and documentation inconsistent with actual thread handling reduce clarity. Code length: Repeated invokeLater wrappers, verbose layout setup, and boilerplate listeners make the class longer than necessary. Action granularity: Statements generally perform one action per line, with readable separation between UI setup steps. Reading flow: Construction proceeds naturally into progress updates and lifecycle methods, but stale TODOs, commented-out code, and inconsistent documentation interrupt the flow.