Sample
Schnappinger/aoi/artofillusion.object.ReferenceImage
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 30.1Δ 16.9 |
| Scalabrino | 0.774 | 0–1; higher is more readable | 56.5Δ 43.3 |
| Dorn | 0.137 | 0–1; higher is more readable | 36.0Δ 22.8 |
| Mi | 0.816 | 0–1; higher is more readable | 96.7Δ 83.5 |
| LLOC | 67 | Logical lines; fewer is more readable | 31.7Δ 18.5 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 60.7 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 42.1 |
| BTTF | 0.368 | 0–1; higher is more readable | 30.4Δ 17.2 |
| Human | 2.43 | 1–4; original rating | 13.2 |
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. | 5517.836 | −182.089 |
| Source linesThe number of non-empty source lines. | 175 | +70 |
| 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.92 | −7.381 |
Intercept 8.87 + feature contributions = -110.599 (log-odds).
Score = sigmoid(-110.599) = 0.
| Score | 0.774 |
|---|
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. | 176 | −5.195 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 151 | +4.486 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 151 | −3.044 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 174.771 | +2.033 |
| 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. | 116.966 | −1.289 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 116.977 | +1.083 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.095 | +0.017 |
Intercept 0.07 + feature contributions = -1.839 (log-odds).
Score = sigmoid(-1.839) = 0.137.
| Score | 0.816 |
|---|
| Score | 67 |
|---|
Run 1
The code is well-structured and generally readable. It follows standard Java conventions with clear class and method organization. Methods are concise and serve single purposes, aiding clarity. Nesting is minimal, with only one multi-line if/else block in writeToFile. The reading flow is natural: fields, constructors, simple getters/setters, then behavior methods. Most lines perform exactly one action. Minor drawbacks: the renderObject method has a somewhat lengthy single call for the image branch, and the serialization constructor could be slightly more segmented, but neither significantly harms readability. Comments are helpful and appropriately placed. Overall, the code demonstrates good style and maintainability.
Run 2
The code is highly readable with a clear, logical structure. It is well-organized into constructors, getters/setters, and overridden methods, each with a single responsibility. Nesting is minimal—only one level in conditional blocks—keeping the code flat and easy to follow. Intent is clearly expressed through method names and Javadoc comments on non-obvious behaviors (e.g., rendering only in ViewerCanvas). The code is concise, avoiding unnecessary repetition, though the long array initializations and the multi-argument renderImage call slightly reduce readability. Action granularity is mostly one action per line, but some lines combine array creation and multiple element initializations. Reading flow is natural, progressing from simple properties to complex serialization logic. Overall, the code is approachable for a developer familiar with the domain, with only minor verbosity in arrays and method calls preventing a perfect score.
Run 3
The code is well-structured and highly readable. It follows a logical class organization with clear method separation and consistent Javadoc comments for public methods, aiding comprehension. Nesting is minimal, with only one if-else block in renderObject and writeToFile, keeping the logic flat and easy to follow. Intent is unambiguous: each method has a single, obvious responsibility (e.g., duplicate, getBounds, renderObject). Code length is appropriate—not overly verbose, with concise expressions for calculations. Action granularity is mostly one action per line, though a few lines (e.g., array initializations, renderImage call) pack multiple values but still remain readable. Reading flow is natural, progressing from constructors to simple getters/setters, then to more complex methods. Minor deductions for slightly dense lines like the Vec3 array declaration and lack of comments on non-public methods, but overall the code is clear, maintainable, and easy to understand.
Run 1
Code Structure: Well-organized class with small, focused methods for geometry, rendering, copying, and serialization. Nesting: Minimal, with simple conditionals and only one shallow conversion block. Clarity of intent: Descriptive method names and useful documentation explain the object's purpose; abbreviated locals, unexplained numeric constants, empty overrides, and an empty exception message reduce clarity slightly. Code length: Generally concise, though repeated corner-coordinate calculations add duplication. Action granularity: Most lines perform one action, but array initializers and rendering calls pack several vector constructions together. Reading flow: Consistent formatting and straightforward control flow make the code easy to follow; long expressions, wildcard imports, and omitted braces on simple conditionals introduce minor friction.
Run 2
Code Structure: Well organized into short, focused methods covering image access, geometry, rendering, and serialization, though constructors are separated. Nesting: Very shallow, with straightforward conditionals and no complex loops. Clarity of intent: Class documentation and descriptive method names clearly establish purpose; abbreviated locals, unexplained numeric constants, and an empty exception message reduce clarity slightly. Code length: Mostly concise, with some repetitive corner-coordinate construction and generous whitespace. Action granularity: Statements generally perform one action per line, although dense array initializers and long rendering arguments require extra parsing. Reading flow: Consistent formatting and simple sequential logic make the code easy to follow; wildcard imports, older array declaration syntax, and omitted braces on conditionals slightly weaken readability.
Run 3
Code Structure: Well-organized class with small, focused methods separating image access, geometry, rendering, and persistence. Nesting: Minimal nesting; conditionals are simple and easy to follow. Clarity of intent: Descriptive method names and helpful documentation establish the purpose, though abbreviated variables, unexplained scaling constants, and an empty exception message reduce clarity. Code length: Mostly concise without unnecessary complexity; repeated rectangle-coordinate calculations add minor duplication. Action granularity: Statements generally perform one action per line, although dense vertex initializers and long rendering arguments require extra parsing. Reading flow: Consistent formatting and straightforward sequential logic support natural reading, but wildcard imports, omitted conditional braces, and placing the deserialization constructor near the end slightly weaken navigation and consistency.