Sample
Schnappinger/aoi/artofillusion.texture.UniformTexture
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 15.7Δ 7.4 |
| Scalabrino | 0.581 | 0–1; higher is more readable | 19.2Δ 3.9 |
| Dorn | 0.042 | 0–1; higher is more readable | 27.7Δ 4.6 |
| Mi | 0.678 | 0–1; higher is more readable | 78.5Δ 55.4 |
| LLOC | 155 | Logical lines; fewer is more readable | 17.3Δ 5.8 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 30.0 |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs | 30.7Δ 7.6 |
| BTTF | 0.26 | 0–1; higher is more readable | 17.5Δ 5.6 |
| Human | 2.99 | 1–4; original rating | 23.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. | 13356.201 | −440.755 |
| Source linesThe number of non-empty source lines. | 271 | +108.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. | 4.909 | −7.363 |
Intercept 8.87 + feature contributions = -330.848 (log-odds).
Score = sigmoid(-330.848) = 0.
| Score | 0.581 |
|---|
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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 258 | +8.187 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 258 | −5.499 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.905 | +3.363 |
| 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. | 135.974 | −2.094 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 135.989 | +1.39 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.096 | +0.006 |
Intercept 0.07 + feature contributions = -3.137 (log-odds).
Score = sigmoid(-3.137) = 0.042.
| Score | 0.678 |
|---|
| Score | 155 |
|---|
Run 1
The code is generally readable with clear structure, flat nesting, and well-separated actions. Methods are concise and follow logical organization, with good naming conventions and Javadoc comments. The constructor and serialization methods are straightforward. However, the `edit()` method is significantly longer and more complex than the rest, with nested anonymous classes and multiple responsibilities that reduce readability. It handles UI creation, event wiring, and state updates in one block, making it harder to follow. While overall flow is natural, this method could benefit from decomposition into smaller helper methods. No deeply nested control structures exist, and intent is mostly clear. The score reflects strong readability with minor weakness in the UI editing section.
Run 2
The code is well-structured, with clear separation of concerns across methods for initialization, data access, serialization, and UI. It maintains a mostly flat structure, with only one switch statement and no deeply nested logic. Method names and variable names clearly convey intent, and comments are helpful without being excessive. The code is concise overall, but the `edit` method is long and dense with UI setup, which slightly reduces readability. Action granularity is generally good—one operation per line—except within the UI setup where multiple controls are configured. Reading flow is natural for a typical listener-heavy UI pattern, though the repeated anonymous listener classes are verbose and add length. Overall, the code is highly readable, but the UI method's length and repetition prevent a perfect score.
Run 3
The code is well-structured with clear separation of concerns: field declarations, constructors, core methods, and UI editing logic are logically organized. Nesting is minimal, with only the expected switch-case and event listener nesting. Intent is generally clear from descriptive method and variable names, and Javadoc comments explain non-obvious methods. The code is concise for what it does, avoiding unnecessary verbosity. Action granularity is good—most lines perform a single logical operation, especially in the `getTextureSpec` calculations and `duplicate` method. Reading flow is natural, progressing from simple accessors to more complex serialization and UI methods. Minor deductions: the `edit` method is quite long but remains readable due to consistent patterns; the event listener anonymous classes add some repetition. Overall, this is highly readable, maintainable Java code.
Run 1
Code Structure: Mostly well-organized into focused methods for texture properties, duplication, editing, and serialization, but edit() mixes UI construction, event handling, and state updates. Nesting: Generally shallow; anonymous event-handler classes add moderate nesting without complex branching. Clarity of intent: Descriptive property and method names help, but abbreviated locals, reused frac, misleading UniformMaterial documentation, and material/texture terminology inconsistencies reduce clarity. Code length: Most methods are concise, while edit() is lengthy and repeats color-handler and property-assignment patterns. Action granularity: Statements generally perform one action per line, making changes easy to follow; grouped declarations and dense argument lists are less readable. Reading flow: Initialization, computation, and serialization proceed naturally, with useful spacing and comments. Long arithmetic expressions, parallel dialog arrays, and repetitive listener setup interrupt otherwise straightforward reading.
Run 2
Code Structure: Methods logically separate texture calculations, duplication, component checks, editing, and serialization, although edit mixes UI construction, event handling, and state updates. Nesting: Mostly shallow, with modest additional nesting in anonymous event handlers. Clarity of intent: Descriptive property and method names communicate purpose, but abbreviated locals such as frac and m, misleading material comments, and dense expressions reduce clarity. Code length: Most methods are concise; edit is lengthy and repeats similar color-picker handlers and property assignments. Action granularity: Statements generally perform one action per line, making updates easy to follow. Reading flow: Consistent formatting and straightforward sequential operations support natural reading, but long argument lists, parallel widget/label arrays, and embedded callbacks interrupt the flow.
Run 3
Code Structure: Most responsibilities are separated into focused methods, but edit() combines widget creation, event handling, preview updates, and committing changes. Nesting: Generally shallow; anonymous callback classes introduce moderate nesting without complex control flow. Clarity of intent: Descriptive property and method names make texture behavior understandable, though abbreviated variables, reused frac, and comments referring to UniformMaterial or material reduce precision. Code length: Most methods are concise, but edit() is lengthy and repeats similar color-picker handlers and property assignments. Action granularity: Statements generally perform one action per line, although some expressions and dialog-construction lines are dense. Reading flow: Initialization, texture calculations, duplication, editing, and serialization follow a logical sequence. Consistent formatting and straightforward early returns help, while long lines, positional widget/label arrays, and inconsistent switch indentation interrupt scanning.