Sample
Schnappinger/argoUML/org.argouml.uml.ui.behavior.state_machines.PopupMenuNewEvent
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 41.5Δ 32.2 |
| Scalabrino | 0.852 | 0–1; higher is more readable | 76.0Δ 66.8 |
| Dorn | 0.418 | 0–1; higher is more readable | 56.4Δ 47.2 |
| Mi | 0.543 | 0–1; higher is more readable | 40.3Δ 31.0 |
| LLOC | 34 | Logical lines; fewer is more readable | 47.9Δ 38.6 |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs | 13.9Δ 4.6 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 16.5 |
| BTTF | 0.56 | 0–1; higher is more readable | 51.5Δ 42.2 |
| Human | 2.12 | 1–4; original rating | 9.2 |
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. | 3070.698 | −101.333 |
| Source linesThe number of non-empty source lines. | 126 | +50.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. | 5.106 | −7.659 |
Intercept 8.87 + feature contributions = -49.722 (log-odds).
Score = sigmoid(-49.722) = 0.
| Score | 0.852 |
|---|
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. | 127 | −3.46 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 72 | +1.753 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 125.963 | +1.351 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 72 | −1.231 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.48 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 76.283 | +0.426 |
| 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. | 79.929 | +0.28 |
Intercept 0.07 + feature contributions = -0.331 (log-odds).
Score = sigmoid(-0.331) = 0.418.
| Score | 0.543 |
|---|
| Score | 34 |
|---|
Run 1
The code structure is logical but contains significant noise: excessive license headers, commented-out code, and redundant operations that obscure intent. Nesting is shallow, which helps readability, but clarity of intent suffers due to repeated action setup without helper methods and commented-out alternative approaches. Action granularity is generally one action per line, but some lines combine multiple operations. Reading flow is interrupted by long boilerplate and inconsistent patterns (e.g., mixing JMenuItem creation and direct action addition). Overall, the code is functional but lacks clean abstraction and conciseness.
Run 2
The code is moderately readable. Structure is logical with a clear constructor and static buildMenu method, but the method body mixes UI construction with state-setting actions, reducing clarity. Nesting is shallow (one if/else-if), which is good. Intent is somewhat clear but obscured by commented-out code and repetitive singleton state updates. Code length is fairly concise but verbose due to repeated setTarget/putValue call pairs. Action granularity: mostly one action per line, but some lines combine variable declaration with initialization and method calls. Reading flow is natural at a high level but interrupted by inconsistent usage (e.g., using JMenuItem vs directly adding an Action) and commented-out code. The deprecated class and redundant comments hurt clarity. Overall, readable enough for Java Swing code but could be improved by extracting repeated setup logic and removing dead code.
Run 3
The code is generally readable, with clear structure and mostly flat nesting. The class and method have clear purposes, and actions are mostly one per line. However, several issues reduce readability: the redundant commented-out lines, the long license header that obscures actual code, and the inconsistent handling of menu items (some created explicitly, others added directly). The serialVersionUID is placed at the end rather than near other fields, disrupting the reading flow. Naming is clear, and the buildMenu method has a logical flow. The deprecated annotation and related comments provide good context. Overall, it is organized but could be improved by removing dead code and consolidating repeated action configuration patterns.
Run 1
Code Structure: The constructor delegates menu construction to a single method, logically grouping selection, creation, and deletion actions. Nesting: Limited to two conditional levels, making control flow easy to follow. Clarity of intent: Descriptive class and action names reveal the purpose, although shared singleton mutation and the generic target parameter require external context. Code length: Repeated singleton retrieval and configuration make the creation section unnecessarily verbose; commented-out statements add clutter. Action granularity: Statements generally perform one operation per line, with readable wrapping of longer calls. Reading flow: Menu construction proceeds naturally from selection to creation to deletion, but inconsistent ordering of action configuration versus insertion interrupts the pattern. Overall, the code is understandable and reasonably organized, with repetition, stale comments, and implicit shared state reducing readability.
Run 2
Code Structure: The constructor delegates to a focused menu-building method, with clear sections for selection, creation, and deletion. Nesting: Only two conditional levels, making branches easy to follow. Clarity of intent: Descriptive class and action names explain the purpose, although generic target typing, string-based roles, and singleton mutations require external context. Code length: Repeated singleton lookups and nearly identical event setup blocks add verbosity; commented-out statements and extensive header text create visual clutter. Action granularity: Statements generally perform one action per line, with readable wrapping for longer calls. Reading flow: Menu construction proceeds naturally from selection to creation to deletion, but repeated configuration calls and inconsistent handling of selection actions slightly interrupt the flow.
Run 3
Code Structure: The constructor delegates menu construction to a dedicated method, with logically grouped selection, creation, and deletion sections; repeated action setup could be extracted. Nesting: Conditional nesting is shallow and manageable. Clarity of intent: Descriptive class and action names make the purpose clear, although the abbreviated pmenu parameter and mutable singleton configuration require extra interpretation. Code length: The implementation is reasonably compact, but repetitive singleton calls, commented-out statements, and extensive header text add reading overhead. Action granularity: Most lines perform a single operation, making individual steps easy to follow. Reading flow: Menu construction proceeds naturally from selection to creation to deletion, though inconsistent action setup order and repeated configuration interrupt the flow.