Sample
Schnappinger/aoi/artofillusion.view.FlatVertexShader
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 53.5Δ 1.9 |
| Scalabrino | 0.873 | 0–1; higher is more readable | 81.5Δ 26.1 |
| Dorn | 0.385 | 0–1; higher is more readable | 54.5Δ 1.0 |
| Mi | 0.46 | 0–1; higher is more readable | 29.0Δ 26.4 |
| LLOC | 25 | Logical lines; fewer is more readable | 53.0Δ 2.5 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 18.5 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 18.3 |
| BTTF | 0.542 | 0–1; higher is more readable | 48.5Δ 6.9 |
| Human | 3.91 | 1–4; original rating | 55.4 |
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. | 1974.554 | −65.16 |
| Source linesThe number of non-empty source lines. | 99 | +39.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.716 | −7.073 |
Intercept 8.87 + feature contributions = -23.764 (log-odds).
Score = sigmoid(-23.764) = 0.
| Score | 0.873 |
|---|
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. | 97 | −2.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 71 | +1.719 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 71 | −1.208 |
| 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.97 | −1.077 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 111.92 | +1.001 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 98.752 | +0.971 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.05 | +0.454 |
Intercept 0.07 + feature contributions = -0.469 (log-odds).
Score = sigmoid(-0.469) = 0.385.
| Score | 0.46 |
|---|
| Score | 25 |
|---|
Run 1
The code is highly readable with clear structure and organization. The class implements a single-purpose interface and uses consistent naming conventions. Methods are short, focused, and flat—there is no problematic nesting. The constructors have clear Javadoc comments explaining parameters, and the logic is straightforward. The only minor issue is a slightly long expression in the first constructor computing the mesh color across multiple lines, which could be extracted into a helper method for even better readability. Action granularity is good, with each line performing one logical operation. Reading flow is natural, proceeding from field declarations through constructors to method implementations. Overall, this is well-structured, maintainable code that clearly expresses its intent.
Run 2
The code is well-structured and readable. It follows a clear class layout with fields, constructors, and methods logically organized. Nesting is minimal, with no deep indentation or complex branching. Intent is clear through descriptive names (FlatVertexShader, getColor, viewDir, mesh) and helpful Javadoc comments. Code length is appropriate, avoiding unnecessary verbosity while still documenting each method's purpose. Action granularity is good: most lines perform one operation, such as setting colors or copying values, though the shader's color computation on one line is slightly dense. Reading flow is natural, moving from field declarations to constructors and then method implementations. Minor deductions are due to the constructor parameter list being somewhat long and the inline arithmetic in getColor being slightly less readable than if the value were computed in a separate variable.
Run 3
The code is well-structured with clear class organization, meaningful field names, and logical constructor overloads. It uses flat nesting with no deep blocks, and each method performs a single, focused action. Javadoc comments consistently explain intent and parameters. The color computation in getColor is concise but slightly dense due to a long formula on one line. Constructor duplication of setup logic is minimal and acceptable. Overall, the code is highly readable, with only minor density in a few expressions.
Run 1
Code Structure: A focused class with logically separated constructors and small shader methods. Nesting: Flat method bodies with no nested control flow make execution easy to follow. Clarity of intent: Descriptive names and useful Javadoc clearly explain responsibilities, though unexplained numeric constants in color blending and lighting slightly obscure intent. Code length: Implementation is concise; documentation adds length but remains useful. Action granularity: Each statement performs a distinct operation, with the RGB calculation sensibly split across lines. Reading flow: Consistent formatting and a natural progression from initialization to rendering and texture queries support smooth reading. Wildcard imports and tightly spaced arithmetic mildly reduce clarity.
Run 2
Code Structure: Logically organized into fields, constructors, and small interface methods with focused responsibilities. Nesting: Entirely flat, with no nested control flow. Clarity of intent: Descriptive names and useful Javadoc clearly explain flat shading and texture behavior; unexplained lighting constants and color-blending arithmetic slightly reduce clarity. Code length: Concise implementation, though constructor assignments and documentation introduce minor repetition. Action granularity: Each statement performs a single main action, and multiline color construction remains understandable. Reading flow: Consistent formatting and natural method ordering make the class easy to follow; wildcard imports and tightly spaced arithmetic are minor readability drawbacks.
Run 3
Code Structure: Fields, constructors, and interface methods are logically organized with clear separation of responsibilities. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive names and Javadoc explain the shader's purpose and parameters; however, unexplained lighting constants and compact arithmetic slightly obscure the shading formula. Code length: The implementation is concise, with short methods and little unnecessary code; documentation adds useful context. Action granularity: Statements generally perform one action per line, and the multiline color calculation remains a single coherent operation. Reading flow: Consistent formatting and a natural progression from initialization to shading and texture properties make the class easy to follow. Wildcard imports and inconsistent operator spacing are minor readability drawbacks.