Sample
Schnappinger/aoi/artofillusion.procedural.RGBModule
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 42.5Δ 9.5 |
| Scalabrino | 0.536 | 0–1; higher is more readable | 12.0Δ 21.0 |
| Dorn | 0.383 | 0–1; higher is more readable | 54.1Δ 21.1 |
| Mi | 0.498 | 0–1; higher is more readable | 33.3Δ 0.3 |
| LLOC | 18 | Logical lines; fewer is more readable | 63.4Δ 30.4 |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs | 59.9Δ 26.9 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 22.3 |
| BTTF | 0.303 | 0–1; higher is more readable | 20.8Δ 12.2 |
| Human | 3.19 | 1–4; original rating | 33.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. | 2199.891 | −72.596 |
| Source linesThe number of non-empty source lines. | 60 | +24 |
| 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.065 | −7.597 |
Intercept 8.87 + feature contributions = -47.323 (log-odds).
Score = sigmoid(-47.323) = 0.
| Score | 0.536 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 114.951 | −1.204 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 61 | −1.123 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 114.918 | +1.05 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 51 | +1.027 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 51 | −0.749 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 59.698 | +0.425 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.094 | +0.027 |
Intercept 0.07 + feature contributions = -0.478 (log-odds).
Score = sigmoid(-0.478) = 0.383.
| Score | 0.498 |
|---|
| Score | 18 |
|---|
Run 1
The code is generally well-structured and readable. It has a logical organization with clear separation of methods, a flat structure with minimal nesting (only one if statement), and obvious intent from method names and comments. The code length is appropriate for the task, and action granularity is reasonable—though a few lines, like the constructor's IOPort array definitions and getColor's value assignments, contain multiple complex expressions that slightly reduce readability. Reading flow is natural, with clear initialization and calculation steps. Minor deductions are due to dense parameter lists and the somewhat redundant color caching logic, which could benefit from further simplification or comment clarification. Overall, the code is quite readable with only minor improvements needed.
Run 2
The code is highly readable with clear structure and logical organization. It follows standard Java conventions with proper package, imports, and class documentation. The constructor neatly declares input/output ports on separate lines, making the module's interface evident. The methods are concise with clear purposes: init resets caching, getColor calculates color. Nesting is minimal with a flat conditional structure. Action granularity is good—each line performs one logical operation. The caching logic and conditional expressions are understandable, though the ternary operations in getColor could be slightly verbose. Variable names are meaningful (colorOk, lastBlur). Comments are helpful but not excessive. The code demonstrates good separation of concerns and maintains a natural reading flow from initialization to calculation.
Run 3
The code is generally well-structured and readable. It has a clear class layout with fields, constructor, and methods, flat nesting, and good use of comments to explain purpose. The constructor is somewhat verbose due to inline IOPort array construction, which slightly affects readability but is acceptable for a UI-oriented class. The getColor method has a clear flow: cache check, computation, and assignment. However, there is some ambiguity around the caching logic (colorOk and lastBlur) and the long ternary lines for reading inputs reduce line-level clarity. Overall, the code is concise and follows consistent formatting, making it easy to follow for someone familiar with the domain.
Run 1
Code Structure: The class is logically organized into construction, cache invalidation, and color calculation. Nesting: Minimal nesting and an early return keep control flow simple. Clarity of intent: The class documentation, RGB variable names, and comments clearly explain its purpose; colorOk, c, and numeric input indices are less descriptive. Code length: The implementation is concise, though the constructor's inline port definitions and repeated channel expressions are visually dense. Action granularity: Statements generally perform one action per line, but constructor lines combine several object creations. Reading flow: The calculation naturally proceeds from cache checking to channel retrieval and color assignment. Long lines, unconventional brace indentation, and wildcard imports slightly reduce readability.
Run 2
Code Structure: The class is logically organized into construction, cache invalidation, and color calculation. Nesting: Control flow is shallow, with a single conditional and an early return. Clarity of intent: The class documentation, RGB variable names, and comments clearly explain its purpose; abbreviated parameters, implicit array-index mappings, and the name colorOk are less descriptive. Code length: The implementation is concise, though repeated channel expressions and the dense constructor add visual complexity. Action granularity: Most statements perform one action per line, but the constructor packs several nested object and array creations together. Reading flow: Methods follow a natural lifecycle, and getColor reads sequentially from cache checking to channel calculation and output copying. Long lines and unconventional brace indentation slightly hinder scanning.
Run 3
Code Structure: Clearly separated constructor, initialization, and color calculation methods provide logical organization. Nesting: Minimal nesting and an early return keep the main calculation flat. Clarity of intent: The class documentation, RGB variable names, and comments explain the purpose well, although colorOk, c, and numeric input indices require some interpretation. Code length: Compact and appropriate, with only minor repetition in component retrieval. Action granularity: Most lines perform one action, but the constructor packs several nested object and array constructions into dense lines. Reading flow: The progression from port setup to cache invalidation, cache checking, and RGB calculation is natural. Long constructor and ternary-expression lines, plus unconventional brace indentation, slightly reduce readability.