Sample
Schnappinger/argoUML/org.argouml.uml.diagram.activity.ui.FigSubactivityState
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 22.1Δ 22.8 |
| Scalabrino | 0.754 | 0–1; higher is more readable | 50.7Δ 5.8 |
| Dorn | 0.035 | 0–1; higher is more readable | 25.7Δ 19.1 |
| Mi | 0.576 | 0–1; higher is more readable | 53.5Δ 8.6 |
| LLOC | 112 | Logical lines; fewer is more readable | 21.8Δ 23.1 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 47.4Δ 2.5 |
| GPT-6.1 Sol | 15.67 | 0–20; mean of three runs | 32.3Δ 12.5 |
| BTTF | 0.205 | 0–1; higher is more readable | 11.2Δ 33.7 |
| Human | 3.83 | 1–4; original rating | 44.9 |
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. | 10233.124 | −337.693 |
| Source linesThe number of non-empty source lines. | 314 | +125.6 |
| 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.96 | −7.44 |
Intercept 8.87 + feature contributions = -210.663 (log-odds).
Score = sigmoid(-210.663) = 0.
| Score | 0.754 |
|---|
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. | 315 | −10.117 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 230 | +7.218 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 230 | −4.857 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 313.942 | +3.978 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 102.978 | +0.857 |
| 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. | 102.968 | −0.696 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.223 |
Intercept 0.07 + feature contributions = -3.323 (log-odds).
Score = sigmoid(-3.323) = 0.035.
| Score | 0.576 |
|---|
| Score | 112 |
|---|
Run 1
The code is well-structured with clear sections, imports, and constants. The class follows logical organization, with fields and methods grouped meaningfully. Nesting is minimal; no excessively deep conditional or loop constructs exist. Intent is mostly clear through method names like initFigs() and makeSubStatesIcon(), though some magic numbers (e.g., -22, +3) make the icon layout logic harder to understand without comments. Code length is reasonable but could be slightly shorter in repetitive getters/setters. Action granularity is mostly one action per line, improving readability. Reading flow is natural and easy to follow. However, the heavy use of hard-coded numbers and lack of explanatory comments for layout calculations reduces clarity in some areas.
Run 2
The code demonstrates strong readability with clear logical organization into small, purposeful methods. The file begins with copyright headers which, while typical, delay the actual code. The class structure is well-segmented, with constants, fields, constructors, and overrides grouped logically. Nesting is minimal, mostly limited to simple null checks and conditionals. Each method has a clear single responsibility, such as `makeSubStatesIcon` and `updateNameText`, and the action granularity is mostly one action per line, making lines easy to follow. Naming is descriptive and self-documenting. However, a few minor issues: some magic numbers are scattered in `setStandardBounds` and `makeSubStatesIcon`, which could benefit from named constants. Also, the `initFigs` method performs multiple setup actions but is still coherent. The comments are generally helpful, though some are verbose. Overall, the code is highly readable and maintainable, with only minor opportunities for improvement.
Run 3
The code is well-structured into logical methods with clear responsibilities, and the class has a single, focused purpose (displaying a UML subactivity state). Nesting is minimal—most methods are flat, with only shallow conditional checks. Intent is generally clear through descriptive method names like `makeSubStatesIcon`, `updateListeners`, and `updateNameText`. However, some magic numbers and coordinate arithmetic (especially in `setStandardBounds`) obscure the graphical layout logic and reduce clarity. Code length is reasonable, though the file contains several boilerplate getter/setter overrides that add length without much complexity. Action granularity is mostly one action per line, though some long conditional expressions and chained booleans reduce readability slightly. Reading flow is natural, starting with fields and constructors, then initialization, followed by public overrides and protected behavior methods. Overall, the code is readable but could be improved with named constants or helper methods for coordinate calculations.
Run 1
Code Structure: Well organized into focused methods for initialization, layout, styling, and model updates. Nesting: Mostly flat, with only shallow conditional nesting and an early return. Clarity of intent: Class documentation and descriptive method names establish the purpose, but terse identifiers such as s1, s2, s3, l, and mee, magic numbers, and dense coordinate calculations obscure details. Code length: Most methods are concise; lengthy headers, repetitive delegation methods, and boilerplate comments increase reading overhead. Action granularity: Statements generally perform one action per line, making execution easy to follow. Reading flow: Consistent formatting and logical method grouping support natural reading, although clone's dependence on figure ordering and inherited framework behavior require extra context.
Run 2
Code Structure: Well-organized class with focused methods separating initialization, layout, styling, and model updates. Nesting: Mostly flat, with early returns and only shallow conditional nesting. Clarity of intent: Class documentation and descriptive method names establish purpose, but terse identifiers such as s1, s2, s3, l, and mee, magic coordinates, and dense layout arithmetic obscure details. Code length: Methods are generally concise; lengthy license headers, repetitive delegation methods, and boilerplate comments increase scanning effort. Action granularity: Statements typically perform one action per line, although some coordinate expressions are complex. Reading flow: Consistent formatting and logical method grouping support natural reading, but cloning depends on implicit figure ordering, and rendering behavior requires familiarity with inherited methods and the graphics framework.
Run 3
Code Structure: Responsibilities are logically separated into initialization, geometry, styling, and model-event methods, though cloning depends on implicit figure ordering. Nesting: Mostly flat, with an early return and only shallow nested conditionals. Clarity of intent: Class documentation and descriptive method names establish purpose, but terse identifiers such as s1, s2, s3, l, and mee, magic numbers, and dense coordinate arithmetic obscure details. Code length: Methods are generally concise, while extensive headers, repetitive accessor documentation, and repeated styling calls add visual bulk. Action granularity: Statements generally perform one action per line; chained calls and geometry expressions occasionally increase cognitive load. Reading flow: Consistent formatting and sensible method grouping support navigation, but understanding layout and initialization requires tracking dependencies across methods and inherited behavior.