Sample
Schnappinger/aoi/artofillusion.raytracer.RTTriangleLowMemory
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 10.7Δ 21.0 |
| Scalabrino | 0.668 | 0–1; higher is more readable | 31.2Δ 0.5 |
| Dorn | 0.006 | 0–1; higher is more readable | 17.5Δ 14.2 |
| Mi | 0.789 | 0–1; higher is more readable | 94.7Δ 63.0 |
| LLOC | 265 | Logical lines; fewer is more readable | 8.6Δ 23.1 |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs | 13.9Δ 17.8 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 16.2Δ 15.5 |
| BTTF | 0.193 | 0–1; higher is more readable | 10.2Δ 21.5 |
| Human | 3.06 | 1–4; original rating | 31.7 |
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. | 20872.069 | −688.778 |
| Source linesThe number of non-empty source lines. | 436 | +174.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.746 | −7.12 |
Intercept 8.87 + feature contributions = -512.628 (log-odds).
Score = sigmoid(-512.628) = 0.
| Score | 0.668 |
|---|
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. | 436 | −14.401 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 414 | +13.583 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 414 | −9.079 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 434.942 | +5.67 |
| 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.972 | −2.094 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 135.986 | +1.39 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.118 | −0.207 |
Intercept 0.07 + feature contributions = -5.07 (log-odds).
Score = sigmoid(-5.07) = 0.006.
| Score | 0.789 |
|---|
| Score | 265 |
|---|
Run 1
The code has a clear overall structure with well-organized classes and methods, but it suffers from significant readability issues. The checkIntersection method is excessively long (over 50 lines) and contains complex mathematical operations that lack explanatory comments. The switch statement for dropAxis cases duplicates similar logic, making it harder to follow. There's heavy use of single-letter variable names (v, w, u, t, v0, vd) that obscure meaning. The edgeIntersectsBox method has deeply nested conditional logic (3-4 levels) making the flow hard to track. The getBounds method contains repetitive min/max comparisons that could be extracted into helper methods. While the code follows consistent formatting and has good Javadoc documentation, the naming conventions and method lengths significantly reduce readability. The action granularity is mixed—some areas have one operation per line while others pack multiple operations. The reading flow is disrupted by the need to mentally track many temporary variables through complex geometric calculations.
Run 2
The code is organized and shows clear intent, but it suffers from several readability issues. The constructor mixes setup logic like normal direction checks and drop-axis selection in ways that require careful reading. Intersection testing is long and has duplicated math across a switch statement. The edge-box test and bounding box methods feature repeated code blocks and deep, similar-looking conditionals. Some lines are extremely long and combine multiple operations, reducing readability. Naming is generally meaningful, but the use of short variables like 'u', 'v', 'w', and 'rix' and abbreviations like 'tri' is not always self-explanatory. Comments exist but are sparse, with complex geometric logic lacking explanation. The class is not unnecessarily long, but the repetition and terse identifiers make it harder to follow. Overall, it’s functional but not highly readable without domain knowledge.
Run 3
The code is fairly readable in terms of structure and naming, but it suffers from long methods, mathematical complexity, and repetitive logic. Methods like checkIntersection and edgeIntersectsBox mix multiple responsibilities and use many intermediate variables, reducing clarity. Nesting is moderate but the bounding-box intersection code repeats nearly identical blocks four times, making it verbose. Intent is generally clear from method names and comments, but the numerical operations obscure the underlying geometric logic. Action granularity is adequate, though multiple expressions are packed into single lines in several places. Reading flow is natural in simple getters but becomes dense in the geometric core. Overall, the code is maintainable for domain experts but less approachable for general readers.
Run 1
1. Code Structure: Responsibilities are logically separated into intersection, bounding-box, mapping, and intersection-result methods, though several geometric routines could use smaller helpers. 2. Nesting: Mostly shallow, aided by early returns; edgeIntersectsBox has repetitive nested conditionals. 3. Clarity of intent: Method names, documentation, and explanatory comments establish purpose, but terse mathematical variables, bit flags, and dense expressions require domain knowledge. 4. Code length: Reasonable for its functionality, but repeated axis checks, bounding comparisons, and box-diagonal tests add avoidable length. 5. Action granularity: Most statements perform one action per line; combined declarations, chained assignments, and inline conditional increments reduce consistency. 6. Reading flow: Operations generally follow a natural geometric sequence, with useful comments marking phases. Inconsistent brace indentation, long lines, repeated field-access chains, and limited spacing around operators interrupt otherwise clear flow.
Run 2
Code Structure: Responsibilities are logically separated into intersection, bounds, box testing, and surface-property methods, with a cohesive inner intersection class. Nesting: Mostly shallow thanks to early returns, although edgeIntersectsBox contains repetitive, moderately nested branches. Clarity of intent: Method names and explanatory comments communicate geometric goals well; abbreviated variables, numeric axis identifiers, dense formulas, and long field-access chains obscure implementation details. Code length: Considerable duplication in bounds calculations, diagonal checks, and axis clipping makes several methods unnecessarily long. Action granularity: Most statements perform one action per line, but combined declarations, chained assignments, and inline conditional increments reduce clarity. Reading flow: The overall progression is natural, with useful comments and whitespace, but inconsistent brace indentation, sparse operator spacing, and long expressions interrupt scanning.
Run 3
1. Code Structure: Responsibilities are logically separated into intersection, bounds, box testing, and intersection-data methods, with a cohesive inner class. 2. Nesting: Most methods use early returns and shallow control flow, but edgeIntersectsBox has several nested conditionals. 3. Clarity of intent: Method names, documentation, and explanatory comments establish purpose; abbreviated variables and dense geometric formulas require careful interpretation. 4. Code length: Repeated axis checks, bounding calculations, and diagonal tests make the implementation longer than necessary and could benefit from helper methods. 5. Action granularity: Most statements perform one action per line, although combined declarations, chained assignments, and inline condition/increment statements reduce consistency. 6. Reading flow: Methods generally progress naturally from setup through checks to results. However, inconsistent brace indentation, tightly spaced arithmetic, long expressions, and repeated deep field access interrupt scanning.