Sample
Schnappinger/aoi/artofillusion.image.ImageOrColor
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 33.8Δ 54.3 |
| Scalabrino | 0.726 | 0–1; higher is more readable | 44.2Δ 43.9 |
| Dorn | 0.178 | 0–1; higher is more readable | 39.6Δ 48.5 |
| Mi | 0.696 | 0–1; higher is more readable | 83.2Δ 5.0 |
| LLOC | 64 | Logical lines; fewer is more readable | 34.0Δ 54.1 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 35.0 |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs | 48.0Δ 40.1 |
| BTTF | 0.488 | 0–1; higher is more readable | 43.6Δ 44.6 |
| Human | 3.99 | 1–4; original rating | 88.1 |
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. | 4747.422 | −156.665 |
| Source linesThe number of non-empty source lines. | 169 | +67.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.825 | −7.238 |
Intercept 8.87 + feature contributions = -87.433 (log-odds).
Score = sigmoid(-87.433) = 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. | 169 | −4.947 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 150 | +4.451 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 150 | −3.021 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 167.858 | +1.937 |
| 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. | 118.97 | −1.374 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 118.994 | +1.115 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.072 | +0.238 |
Intercept 0.07 + feature contributions = -1.531 (log-odds).
Score = sigmoid(-1.531) = 0.178.
| Score | 0.696 |
|---|
| Score | 64 |
|---|
Run 1
The code is generally readable with clear class-level documentation and logical method grouping. Methods are short and focused, with minimal nesting. However, the anonymous inner classes in getEditingPanel create moderate nesting and duplicate event-handler structures, reducing clarity. The getColor and getAverageColor methods have slightly awkward brace placement for the else blocks, which disrupts flow. Some methods (e.g., duplicate, copy) are concise and clear, while the event-handler code is verbose and could be extracted for better readability. Overall structure is sound but would benefit from refactoring repeated event logic.
Run 2
The code is generally well-structured and readable. It follows good object-oriented design with clear separation of concerns (data model, file I/O, UI editing). Naming is descriptive and Javadoc comments explain the purpose of public methods. The class is concise and methods are short, each performing a single logical action. Indentation and brace placement are consistent. However, the readability score is slightly lowered by the getEditingPanel method, which contains multiple nested anonymous inner classes with event handlers. This creates moderate nesting depth and makes the UI wiring code harder to follow at a glance. Additionally, the else blocks in getColor and getAverageColor use an older brace style with indentation that is slightly inconsistent with the rest of the code. Overall, the code demonstrates clear intent and good organization, with only minor issues in the event-handling section preventing a higher score.
Run 3
The code is well-structured with clear separation of concerns, logical method ordering, and helpful Javadoc comments explaining purpose and parameters. Nesting is minimal—only a few single-level conditionals. Intent is generally obvious from method and variable names. Code length is appropriate; no unnecessary verbosity. Action granularity is mostly good, with one primary action per line, though the getEditingPanel method contains some multi-step anonymous inner classes that slightly reduce readability. Reading flow is natural: constructors first, then getters, computational methods, serialization, and UI code. Minor deductions: inconsistent indentation (some braces use tabs/spaces oddly), and the anonymous event handler classes are somewhat verbose for modern Java. Overall, this is very readable legacy Java code.
Run 1
Code Structure: Well organized into constructors, accessors, color operations, serialization, and UI creation, though UI and data responsibilities share one class. Nesting: Mostly shallow; anonymous event handlers introduce moderate nesting in the editing panel. Clarity of intent: Descriptive method names and useful documentation make behavior clear, although generic names such as map and obj and overloaded getColor methods require some context. Code length: Most methods are short and focused; the editing-panel method is longer but cohesive. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Logical method ordering and straightforward control flow support natural reading. Inconsistent indentation, omitted braces on single-statement branches, wildcard imports, and inline anonymous handlers slightly reduce readability.
Run 2
Code Structure: Responsibilities are organized into small, distinct methods, though UI construction and event handling share the class with color logic and serialization. Nesting: Most methods are flat; anonymous event handlers introduce moderate nesting in getEditingPanel. Clarity of intent: Descriptive method names and useful documentation make behavior clear, although names such as map, obj, and theColor are less precise, and image component indices are unexplained. Code length: Generally concise, with a somewhat lengthy but cohesive editing-panel method. Action granularity: Statements consistently perform one action per line, making operations easy to follow. Reading flow: Methods follow a sensible progression from construction and access to sampling, copying, persistence, and editing. Inconsistent indentation, mixed brace styles, wildcard imports, and long signatures slightly hinder scanning.
Run 3
Code Structure: Methods are logically separated into construction, color sampling, copying, serialization, and editing, though UI responsibilities share the data class. Nesting: Most methods are flat, with simple conditionals; anonymous event handlers add modest nesting in the editing panel. Clarity of intent: Descriptive method names and useful documentation make behavior clear, although names such as map, obj, and theColor are somewhat generic. Code length: Most methods are concise; getEditingPanel is longer but remains focused, with some repeated event-notification logic. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: The progression is natural and related methods are grouped, but mixed tabs and spaces, inconsistent brace placement, wildcard imports, and long signatures slightly interrupt readability.