Sample
Schnappinger/argoUML/org.argouml.core.propertypanels.ui.UMLSignalComboBoxModel
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 38.8Δ 16.0 |
| Scalabrino | 0.736 | 0–1; higher is more readable | 45.2Δ 9.6 |
| Dorn | 0.215 | 0–1; higher is more readable | 42.2Δ 12.5 |
| Mi | 0.589 | 0–1; higher is more readable | 57.8Δ 3.0 |
| LLOC | 42 | Logical lines; fewer is more readable | 42.1Δ 12.7 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 41.3Δ 13.5 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 29.0 |
| BTTF | 0.381 | 0–1; higher is more readable | 32.7Δ 22.1 |
| Human | 3.91 | 1–4; original rating | 54.8 |
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. | 3957.055 | −130.583 |
| Source linesThe number of non-empty source lines. | 176 | +70.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.924 | −7.386 |
Intercept 8.87 + feature contributions = -58.699 (log-odds).
Score = sigmoid(-58.699) = 0.
| Score | 0.736 |
|---|
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. | 177 | −5.231 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 117 | +3.31 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 117 | −2.264 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 175.837 | +2.048 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.944 | +0.76 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.455 |
| 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. | 96.977 | −0.442 |
Intercept 0.07 + feature contributions = -1.294 (log-odds).
Score = sigmoid(-1.294) = 0.215.
| Score | 0.589 |
|---|
| Score | 42 |
|---|
Run 1
The code is generally clear and well-structured, with logical class organization and reasonable method separation. It avoids deep nesting and most actions are granular. However, several issues reduce readability: over 40 lines of license headers at the top obscure the actual code; method names like getAction() and getActions() are ambiguous and similar; the actionPerformed method has confusing variable reassignment (Object o is assigned three times) and unclear intent; inconsistent indentation (tabs vs spaces) appears in buildModelList and elsewhere; some methods lack Javadoc or have minimal comments; and the modelChanged method could be flatter. The overall reading flow is acceptable but not natural due to these issues.
Run 2
The code is generally well-structured and readable. It follows a logical organization, with clear method separation and consistent naming. Nesting is mostly flat, with only a few conditional blocks that stay shallow. Intent is mostly clear: the class models a combo box for UML signals and handles changes explicitly. Most methods are concise, and actions are generally one per line, especially in getActions() and actionPerformed(). The reading flow is natural—field declarations, constructor, model-building, validation, selection helper, event handling, and inner action class. Minor issues include a slightly confusing variable reassignment in actionPerformed() (Object o is assigned twice, reducing clarity) and a small amount of legacy/boilerplate code (copyright headers). Some duplicated model-facade calls could be extracted for clarity. Overall, it is readable but not perfect.
Run 3
The code is generally readable but has some issues. The class structure is logical with clear method separation, and most methods are concise with single actions per line. However, the 'modelChanged' method and 'actionPerformed' method introduce unnecessary nesting and slightly awkward flow. In 'actionPerformed', the repeated assignment to 'o' is confusing, and the intent could be clearer by directly assigning 'signal'. The 'buildModelList' method has a long condition that wraps across lines, making it harder to follow. The comments, especially the verbose license header, add noise. The method naming is clear, and the code avoids deep nesting overall, but the minor inconsistencies in handling ('modelChanged' directly removes elements rather than calling a helper) slightly reduce clarity. The class is not excessively long for its responsibility, but the 'SetAction' inner class could be simplified.
Run 1
Code Structure: Responsibilities are sensibly separated into short methods, with selection handling encapsulated in an inner action class. Nesting: Mostly shallow, although modelChanged has three nested conditionals. Clarity of intent: Class and method names convey the purpose, and the event-handling comment is useful; generic variables such as o, m, and p, stale constructor documentation, and a redundant overwritten assignment obscure details. Code length: Implementation is reasonably concise, but extensive license text, boilerplate comments, and unnecessary temporary variables add reading overhead. Action granularity: Statements generally perform one action per line, though chained model API calls require additional interpretation. Reading flow: Method organization is natural, but inconsistent indentation, excess blank lines, and a long conditional interrupt the flow.
Run 2
Code Structure: Responsibilities are organized into focused methods, with an inner class encapsulating the selection action. Nesting: Most methods are shallow, although modelChanged has three nested conditionals. Clarity of intent: Class and API names explain the signal-selection purpose, but generic variables such as o, m, and p, stale constructor comments, and a redundant target assignment reduce clarity. Code length: Functional code is reasonably concise; lengthy license headers, boilerplate comments, and unnecessary intermediate variables add visual overhead. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Method ordering is logical, but inconsistent indentation, excess blank lines, long conditions, and chained API calls interrupt the flow. Overall, the code is readable with modest cleanup needed.
Run 3
Code Structure: Well-organized class with focused methods and an inner action class separating selection behavior. Nesting: Generally shallow, although modelChanged has three nested conditional levels. Clarity of intent: Method names and domain APIs communicate the purpose, but generic variables such as o, m, and p, outdated constructor comments, and redundant reassignment in actionPerformed reduce clarity. Code length: Implementation is reasonably concise, though extensive license boilerplate, redundant variables, and unnecessary blank lines add reading overhead. Action granularity: Statements generally perform one action per line; chained API calls remain understandable. Reading flow: Methods follow a sensible progression from initialization through model management to actions, but inconsistent indentation, a long conditional line, and stale superclass references interrupt the flow.