Sample
Schnappinger/argoUML/org.argouml.ui.ZoomSliderButton
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 25.4Δ 4.6 |
| Scalabrino | 0.805 | 0–1; higher is more readable | 64.0Δ 34.0 |
| Dorn | 0.037 | 0–1; higher is more readable | 26.4Δ 3.6 |
| Mi | 0.588 | 0–1; higher is more readable | 57.1Δ 27.1 |
| LLOC | 109 | Logical lines; fewer is more readable | 22.4Δ 7.6 |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs | 26.9Δ 3.1 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 8.9 |
| BTTF | 0.378 | 0–1; higher is more readable | 32.0Δ 2.0 |
| Human | 3.01 | 1–4; original rating | 30.0 |
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. | 9269.92 | −305.907 |
| Source linesThe number of non-empty source lines. | 369 | +147.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.794 | −7.19 |
Intercept 8.87 + feature contributions = -156.628 (log-odds).
Score = sigmoid(-156.628) = 0.
| Score | 0.805 |
|---|
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. | 370 | −12.064 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 275 | +8.775 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 275 | −5.89 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 368.976 | +4.748 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 78.395 | +0.46 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.408 |
| 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. | 80.954 | +0.236 |
Intercept 0.07 + feature contributions = -3.257 (log-odds).
Score = sigmoid(-3.257) = 0.037.
| Score | 0.588 |
|---|
| Score | 109 |
|---|
Run 1
The code has good structure with clear class organization, but readability is significantly hampered by several issues. The license headers occupy excessive space before the actual code, hurting reading flow. The constructor's anonymous AbstractAction contains a verbose comment explaining keyboard vs mouse event handling, which could be simplified. Methods like showPopup() and handleSliderValueChange() contain magic numbers and inline calculations without explanatory comments. The MyPopupMenuListener class has inconsistent indentation and extends AbstractAction unnecessarily for just one empty method. Several commented-out lines remain (e.g., '//if (!source.getValueIsAdjusting())'), adding confusion. The class has many instance variables with unclear state management between popupButtonIsActive, popupMenuIsShowing, and mouseIsOverPopupButton, making the control flow difficult to trace. Nesting is relatively flat, but some methods mix concerns. Overall, the code is functional but requires careful reading to understand the interactive popup behavior, reducing its readability score.
Run 2
The code is generally well-structured with clear separation of concerns across methods and inner classes. Naming is descriptive and the overall intent is understandable. However, readability is hindered by tight coupling between the popup button state logic and mouse events, scattered boolean flags, and some methods that perform multiple actions (e.g., showPopup manipulates slider, editor, and popup state). The presence of an empty actionPerformed method and commented-out code adds noise. Long class length and several boilerplate interface implementations further reduce clarity.
Run 3
The code is well-structured and readable. It uses clear naming conventions, constants, and Javadoc comments that explain purpose. The methods are logically organized, each performing a single responsibility (e.g. creating popup, handling slider, parsing text). Nesting is shallow, action granularity is strong, and reading flow is natural. Minor issues: some conditional formatting is slightly inconsistent (e.g. space before parenthesis in `if ( popupButtonIsActive )`), and a few listener methods are empty, which adds visual clutter. Overall, very maintainable and easy to follow.
Run 1
Code Structure: Responsibilities are separated into focused methods and listener classes, though popup state management is distributed across several handlers. Nesting: Mostly shallow conditionals and early returns keep control flow manageable; anonymous listeners add modest nesting. Clarity of intent: Descriptive constants, method names, and documentation explain zoom behavior well, but generic listener names, abbreviated locals, and interacting boolean flags obscure some details. Code length: Reasonable for a Swing component, although repetitive comments, empty listener methods, commented-out code, and verbose setup increase reading effort. Action granularity: Statements generally perform one action per line, making changes easy to follow. Reading flow: Construction, popup setup, updates, and event handling follow a logical sequence, but inconsistent indentation, brace placement, spacing, and line wrapping disrupt visual consistency.
Run 2
Code Structure: Responsibilities are sensibly divided among setup, zoom updates, text validation, and listener classes, though popup behavior spans several state flags and callbacks. Nesting: Mostly shallow, with guard clauses and short conditionals; anonymous listeners add modest nesting. Clarity of intent: Descriptive constants, method names, and documentation explain the zoom control well, but generic names such as ed, pm, and MyMouseListener weaken clarity. Code length: Functional methods are reasonably concise, but extensive boilerplate, repetitive comments, commented-out code, and a verbose boolean assignment add clutter. Action granularity: Statements generally perform one action per line, making changes easy to follow. Reading flow: The progression from construction through setup and event handling is logical, but inconsistent indentation, brace placement, and line wrapping interrupt it. Understanding popup activation requires tracing interactions across multiple listeners.
Run 3
Code Structure: Responsibilities are logically separated into initialization, zoom updates, text handling, and listener classes, though popup behavior depends on several interacting flags. Nesting: Mostly shallow, with guard clauses keeping event handlers easy to follow; anonymous listeners add some nesting. Clarity of intent: Descriptive constants, method names, and documentation clearly explain the zoom control, but abbreviated variables and generic listener names weaken clarity. Code length: Generally reasonable for a Swing component, although repetitive comments, verbose listener boilerplate, an unnecessary AbstractAction superclass, and commented-out code add clutter. Action granularity: Statements generally perform one action per line, making changes straightforward to trace. Reading flow: The progression from construction through setup to event handling is natural, but inconsistent indentation, brace placement, and line wrapping interrupt readability. Overall, the code is readable and well organized, with minor verbosity and formatting issues and moderately complex popup-state coordination.