Sample
Schnappinger/aoi/artofillusion.view.TexturedVertexShader
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 22.4Δ 15.1 |
| Scalabrino | 0.703 | 0–1; higher is more readable | 39.4Δ 32.1 |
| Dorn | 0.017 | 0–1; higher is more readable | 22.8Δ 15.5 |
| Mi | 0.515 | 0–1; higher is more readable | 36.6Δ 29.4 |
| LLOC | 103 | Logical lines; fewer is more readable | 24.1Δ 16.8 |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs | 38.0Δ 30.7 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 18.5 |
| BTTF | 0.222 | 0–1; higher is more readable | 13.5Δ 6.3 |
| Human | 2.06 | 1–4; original rating | 7.3 |
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. | 9217.355 | −304.173 |
| Source linesThe number of non-empty source lines. | 240 | +96 |
| 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.673 | −7.009 |
Intercept 8.87 + feature contributions = -206.312 (log-odds).
Score = sigmoid(-206.312) = 0.
| Score | 0.703 |
|---|
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. | 241 | −7.497 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 204 | +6.319 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 204 | −4.26 |
| 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. | 174.983 | −3.746 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 239.881 | +2.943 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 174.988 | +2.019 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.089 | +0.081 |
Intercept 0.07 + feature contributions = -4.071 (log-odds).
Score = sigmoid(-4.071) = 0.017.
| Score | 0.515 |
|---|
| Score | 103 |
|---|
Run 1
The code demonstrates good readability with clear structure and organization. The class has a single responsibility and methods are logically grouped. Nesting is reasonable - the main complexity lies in the switch statements with caching logic, which create some depth but remain manageable. Intent is clearly documented through Javadoc comments and inline comments explaining non-obvious decisions like the caching strategy. The code is somewhat verbose in the getColor method where the switch cases repeat similar patterns, but this repetition is for performance optimization which is justified. Action granularity is generally good with one major operation per line, though the texture spec calculations could be broken down further. Reading flow is natural with clear sectioning and descriptive variable names. Minor deductions for the lengthy getColor method that could benefit from extraction, and the duplicate code between cache/non-cache paths reduces elegance slightly. Overall the code is maintainable and clearly written for other developers to understand.
Run 2
The code has clear structure with logical organization into methods and good Javadoc comments explaining purpose. However, readability suffers from significant issues. The getColor() method is excessively long (~70 lines) with a deeply nested switch statement and duplicated code blocks for each vertex case - this could be refactored into a helper method. The caching logic creates multiple levels of nesting and repetitive code. While most lines represent single actions and the reading flow is generally natural, the heavy duplication in both cached and non-cached paths, along with the three nearly identical switch cases, makes the code harder to follow than necessary. Magic numbers (0.1, 0.01, 128.0) lack clear explanation. Overall, the code is maintainable but would benefit from extracting helper methods and reducing duplication.
Run 3
The code is generally well-structured and readable, with clear Javadoc comments, logical organization, and descriptive variable names. It avoids deep nesting and maintains a reasonable flow. However, there are issues: the switch statements in getColor() are repetitive, with near-identical blocks for each vertex case, which increases length and reduces maintainability. The constructor's early return inside a loop is slightly awkward. The optimize() method mixes concerns (uniform mapping optimization vs caching logic), making the method lengthy. Some conditional blocks could be extracted for clarity. The code is not unreadable, but repetitive sections and occasional mixing of logic prevent a higher score.
Run 1
Code Structure: Clearly separated constructor, optimization, shading, and query methods, but getColor combines cache management, texture sampling, and lighting. Nesting: Mostly moderate, with deeper nesting inside cached vertex selection and shader reuse. Clarity of intent: Documentation, comments, and descriptive method names explain the purpose well; abbreviated variables, unexplained numeric constants, and dense lighting expressions reduce clarity. Code length: Reasonable overall, though repeated switch branches and cache assignments unnecessarily lengthen getColor. Action granularity: Statements generally perform one action per line, although grouped declarations and complex expressions require extra parsing. Reading flow: Initialization, optimization, sampling, and final color calculation follow a logical progression; duplicated cached and uncached paths interrupt that flow. Extracting sampling/cache helpers and naming lighting constants would improve readability.
Run 2
Code Structure: The class is logically organized into construction, optimization, shading, queries, and cache cleanup, but getColor combines cache management, texture sampling, and lighting. Nesting: Mostly moderate, with deeper nesting in the cached switch branches and shader reuse checks. Clarity of intent: Javadoc, comments, and descriptive method names explain the purpose well; abbreviated locals, unexplained numeric constants, and dense lighting expressions reduce clarity. Code length: Reasonable overall, but repeated texture sampling and cache assignments across vertex cases unnecessarily lengthen getColor. Action granularity: Statements generally perform one action per line, although grouped declarations and complex expressions add density. Reading flow: Consistent formatting and clear cached versus uncached branches support natural reading, but duplicated switch logic and the long central method interrupt the flow.
Run 3
Code Structure: Methods separate initialization, optimization, shading, and cache management logically, but getColor combines several responsibilities. Nesting: Mostly moderate, with deeper conditional nesting inside the cached vertex switch. Clarity of intent: Documentation, descriptive method names, and explanatory comments make the shader's purpose clear; abbreviated variables, parallel cache arrays, and unexplained numeric constants reduce clarity. Code length: Reasonable overall, but repeated texture sampling and cache population across three switch cases unnecessarily lengthen getColor. Action granularity: Statements generally perform one action per line, though grouped declarations and dense mathematical expressions require extra attention. Reading flow: Consistent formatting and clear cached/noncached branches support natural reading, but duplicated branches and long expressions interrupt the flow.