Sample
Schnappinger/aoi/artofillusion.ui.ToolPalette
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 18.7Δ 4.2 |
| Scalabrino | 0.726 | 0–1; higher is more readable | 43.8Δ 29.3 |
| Dorn | 0.051 | 0–1; higher is more readable | 29.0Δ 14.5 |
| Mi | 0.551 | 0–1; higher is more readable | 41.9Δ 27.4 |
| LLOC | 165 | Logical lines; fewer is more readable | 16.2Δ 1.7 |
| DeepSeek V4 Pro | 15.33 | 0–20; mean of three runs | 41.3Δ 26.7 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 24.4 |
| BTTF | 0.309 | 0–1; higher is more readable | 21.5Δ 6.9 |
| Human | 2.49 | 1–4; original rating | 14.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. | 11404.755 | −376.357 |
| Source linesThe number of non-empty source lines. | 294 | +117.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.8 | −7.2 |
Intercept 8.87 + feature contributions = -257.087 (log-odds).
Score = sigmoid(-257.087) = 0.
| Score | 0.726 |
|---|
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. | 294 | −9.373 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 278 | +8.879 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 278 | −5.958 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 292.85 | +3.684 |
| 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. | 111.983 | −1.078 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.966 | +1.002 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.113 | −0.152 |
Intercept 0.07 + feature contributions = -2.927 (log-odds).
Score = sigmoid(-2.927) = 0.051.
| Score | 0.551 |
|---|
| Score | 165 |
|---|
Run 1
The code has clear class-level documentation and generally descriptive method names, aiding intent. However, it suffers from several readability issues. The `addTool` method is overly long, combining array resizing, element shifting, size calculation, and UI updates with multiple nested loops and conditionals. Action granularity is mixed; some methods follow one-action-per-line, while others pack multiple statements per line. Nesting is moderate but becomes dense in `paint` and `addTool`. The reading flow is disrupted by deep, multi-purpose loops and comments that explain 'what' rather than 'why'. Code structure is acceptable, but methods like `mousePressed`, `mouseEntered`, and `mouseMoved` duplicate logic, indicating a lack of abstraction. Overall, the code is understandable but requires effort due to verbose methods and scattered responsibilities.
Run 2
The code has clear structure with logical method grouping and Javadoc comments. It is mostly flat with minimal nesting and follows a natural reading flow. However, there are several places where action granularity could be improved: multiple operations are chained on single lines (e.g., chained method calls like `tool[i].getButton().setPosition()`), and some lines exceed comfortable length (e.g., the `fillRoundRect` call and `getPreferredSize` return). The variable naming is concise but sometimes cryptic (`r`, `t`, `ev`), and the three-pass paint logic with inline comments is somewhat repetitive. The `selectToolInternal` method has an unnecessary `if` check and missing early return, adding a minor nesting level. Overall, the code is quite readable and maintainable, but would benefit from slight refactoring for line lengths and granularity.
Run 3
The code has good structure with clear separation of methods, each handling a specific event or query. Nesting is generally shallow, though the paint method uses three sequential loops for drawing order, which is reasonable. Intent is mostly clear, with descriptive method names and comments explaining non-obvious logic like drawing order. Code length is moderate but some methods like addTool and paint could be split further. Action granularity is good—most lines perform one action, especially in event handlers. Reading flow is natural, matching typical UI component patterns. Minor issues: magic numbers in paint (8, 8 for corner radius), some duplicated logic in mouseEntered and mouseMoved, and slightly inconsistent use of comments in selectToolInternal. Overall, readable code that would be easy to maintain.
Run 1
Code Structure: Well organized into focused methods for tool management, rendering, sizing, and event handling, although selection and highlighting logic is duplicated. Nesting: Generally shallow, with simple loops and conditionals; omitted braces slightly hinder scanning. Clarity of intent: Descriptive method names and useful comments explain most behavior, but abbreviated variables, grouped fields, and the selected/lastSelected relationship require extra attention. Code length: Mostly concise, though repeated button access, rendering loops, and mouse handlers add verbosity. Action granularity: Usually one operation per line, with chained assignments and grouped declarations as exceptions. Reading flow: Predictable formatting and small methods support natural reading, but inconsistent indentation, tightly spaced arithmetic, long expressions, and string-based event registration reduce ease of navigation.
Run 2
Code Structure: Well-organized into focused methods for tool management, rendering, selection, and event handling, though selection and highlighting logic are duplicated. Nesting: Mostly shallow, with straightforward loops and conditionals; omitted braces slightly reduce scanability. Clarity of intent: Descriptive method names and documentation explain the palette's behavior, but abbreviated variables, grouped fields, and subtle selected/lastSelected interactions require extra attention. Code length: Generally concise for its functionality, although repeated button access, highlighting handlers, and selection updates could be consolidated. Action granularity: Most lines perform one action; chained assignments such as selected = lastSelected = i are minor exceptions. Reading flow: Initialization, accessors, and handlers follow a reasonably natural progression, but inconsistent indentation, dense arithmetic expressions, and placement of selection methods after mouse handlers interrupt the flow slightly.
Run 3
Code Structure: Well organized into focused methods for tool management, rendering, selection, and event handling, though selection and highlighting logic are duplicated. Nesting: Generally shallow, with straightforward loops and conditionals; omitted braces slightly hinder scanning. Clarity of intent: Descriptive method names and useful documentation explain the palette's purpose and rendering order. Short variable names, grouped fields, and subtle selected/lastSelected state transitions reduce clarity. Code length: Mostly concise, but repeated button access, rendering loops, and identical mouse-enter/move handlers add avoidable repetition. Action granularity: Most lines perform one action, although chained assignments combine state updates and some expressions pack substantial layout calculations into one line. Reading flow: Methods are easy to follow locally, but inconsistent indentation, tight operator spacing, long expressions, and scattered selection updates interrupt an otherwise natural flow.