Sample
Schnappinger/argoUML/org.argouml.uml.ui.ActionImportFromSources
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 36.1Δ 16.6 |
| Scalabrino | 0.753 | 0–1; higher is more readable | 50.0Δ 30.5 |
| Dorn | 0.291 | 0–1; higher is more readable | 47.2Δ 27.7 |
| Mi | 0.581 | 0–1; higher is more readable | 55.1Δ 35.6 |
| LLOC | 41 | Logical lines; fewer is more readable | 42.9Δ 23.4 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 41.3Δ 21.8 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 19.5 |
| BTTF | 0.541 | 0–1; higher is more readable | 48.2Δ 28.7 |
| Human | 2.87 | 1–4; original rating | 19.5 |
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. | 4228.151 | −139.529 |
| Source linesThe number of non-empty source lines. | 162 | +64.8 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.007 | −7.51 |
Intercept 8.87 + feature contributions = -73.369 (log-odds).
Score = sigmoid(-73.369) = 0.
| Score | 0.753 |
|---|
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. | 163 | −4.735 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 107 | +2.964 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 107 | −2.034 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.955 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 87.417 | +0.606 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.051 | +0.446 |
| 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.963 | −0.061 |
Intercept 0.07 + feature contributions = -0.891 (log-odds).
Score = sigmoid(-0.891) = 0.291.
| Score | 0.581 |
|---|
| Score | 41 |
|---|
Run 1
The code is generally readable with a clear class structure, logical method separation, and descriptive variable names. It benefits from flat nesting, minimal cyclomatic complexity, and one action per line in most places. The actionPerformed and doCommand methods have clear purposes, and logging messages aid understandability. However, several issues lower the score: the doCommand method is long and performs multiple responsibilities (parsing, validation, file handling, import execution) without helper methods. Some nested if statements create minor complexity. Import statements and logging are verbose, but not excessive. Inconsistent indentation in the actionPerformed method (mixed spaces/tabs) hurts visual flow. The comment block at the top is lengthy and detracts from immediate code comprehension. Overall, the code is approachable for a developer, but would benefit from refactoring doCommand into smaller methods and standardizing formatting to improve readability further.
Run 2
The code is generally well-structured and readable. It follows clear logical organization with separate methods for different concerns (constructor, action handling, command execution). The nesting is minimal, with the deepest level being 2-3 levels in the doCommand method. Intent is clearly expressed through descriptive method names and comments. Code length is appropriate for the functionality - not overly verbose. Action granularity is mostly one action per line, though some lines combine multiple operations. The reading flow is natural, progressing logically from class declaration through methods. Minor deductions for: the mixed indentation (tabs vs spaces) in some blocks, excessive copyright comments at the top that push code down, and the doCommand method could benefit from extracting validation logic into smaller helper methods. The error handling is repetitive with similar null/empty checks that could be consolidated. Overall, this is clean, maintainable code that would be easy for another developer to understand and modify.
Run 3
The code is generally readable but has some issues. Structure is logical with clear separation of methods, and the class follows a recognizable pattern. However, there are inconsistencies: mixed indentation (tabs vs spaces), excessive license headers, and inconsistent Javadoc formatting. Nesting is mostly flat, which is good. Intent is clear for most methods, though the doCommand method is somewhat long and performs multiple validation steps. Variable naming could be more descriptive (e.g., 'imp', 'ed', 'iss'). Action granularity is reasonable with one major operation per line. The reading flow is acceptable but interrupted by the inconsistent formatting and verbose logging statements. The code would benefit from cleaner separation of concerns in doCommand, perhaps extracting validation logic into helper methods.
Run 1
Code Structure: Clearly separated constructor, GUI action handler, singleton accessor, and command-line handler, although doCommand combines validation, importer setup, and execution. Nesting: Shallow conditionals and early returns make execution paths easy to follow. Clarity of intent: Descriptive class and method names, explicit error messages, and parameter documentation explain the purpose; abbreviations such as imp, ed, and iss reduce local clarity. Code length: Implementation is reasonably concise, but lengthy license headers and redundant comments add reading overhead. Action granularity: Statements generally perform one action per line, with clear separation between validation and setup. Reading flow: The command-line method progresses naturally from argument validation to import execution. Mixed indentation, inconsistent comment formatting, and constructor-triggered GUI behavior slightly disrupt readability.
Run 2
Code Structure: Clearly organized into initialization, UI handling, singleton access, and command-line importing, although UI and CLI responsibilities share one class. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive method names, logging, and argument documentation explain the purpose; abbreviations such as imp, ed, and iss reduce local clarity. Code length: Implementation is reasonably concise, but lengthy license headers and redundant comments add visual overhead. Action granularity: Statements generally perform one action per line, with readable wrapping of longer calls. Reading flow: Command-line validation proceeds naturally toward importing, but inconsistent indentation, a misaligned documentation delimiter, and raw Collection usage slightly interrupt readability.
Run 3
Code Structure: Clearly organized into initialization, GUI handling, singleton access, and command-line importing, although GUI and CLI responsibilities share one class. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Descriptive method names and specific error messages explain the import workflow; abbreviated variables such as imp, iss, and ed and an obscure constructor comment reduce clarity. Code length: Implementation is reasonably concise, but extensive license headers and redundant comments add reading overhead. Action granularity: Statements generally perform one action per line, with sensible wrapping of longer calls. Reading flow: Validation proceeds naturally from argument parsing through importer selection, file checking, and execution. Inconsistent indentation and a misaligned Javadoc closing delimiter slightly disrupt presentation.