Sample
Schnappinger/aoi/artofillusion.raytracer.RTEllipsoid
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 11.4Δ 12.4 |
| Scalabrino | 0.578 | 0–1; higher is more readable | 18.5Δ 5.3 |
| Dorn | 0.008 | 0–1; higher is more readable | 19.1Δ 4.6 |
| Mi | 0.499 | 0–1; higher is more readable | 33.7Δ 9.9 |
| LLOC | 249 | Logical lines; fewer is more readable | 10.6Δ 13.2 |
| DeepSeek V4 Pro | 10.67 | 0–20; mean of three runs | 10.6Δ 13.2 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 16.2Δ 7.6 |
| BTTF | 0.136 | 0–1; higher is more readable | 5.0Δ 18.8 |
| Human | 2.99 | 1–4; original rating | 23.8 |
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. | 20245.905 | −668.115 |
| Source linesThe number of non-empty source lines. | 422 | +168.8 |
| 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.68 | −7.021 |
Intercept 8.87 + feature contributions = -497.465 (log-odds).
Score = sigmoid(-497.465) = 0.
| Score | 0.578 |
|---|
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. | 422 | −13.905 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 402 | +13.168 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 402 | −8.804 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 420.938 | +5.474 |
| 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. | 128.981 | −1.798 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 128.986 | +1.277 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.126 | −0.278 |
Intercept 0.07 + feature contributions = -4.797 (log-odds).
Score = sigmoid(-4.797) = 0.008.
| Score | 0.499 |
|---|
| Score | 249 |
|---|
Run 1
The code has a clear class structure and some methods are straightforward, but overall readability suffers from several factors. The constructor contains a deeply nested chain of conditionals (up to 3 levels) with repetitive axis-swapping logic that could be simplified. Variable names like rx, ry, rz, rx2, ry2, rz2, sy, sz, and temp1/temp2 are cryptic and lack clear intent. The checkIntersection method is long and mixes several operations (setup, branching based on ray origin position, distance calculation, projection) without helper methods, making the flow hard to follow. Some lines contain multiple actions (e.g., setting multiple variables). Mathematical operations are compact but sometimes dense, with little explanation. The intersectsBox method repeats nearly identical code 8 times for box corners, which could be looped. Comments exist but are sparse. Overall, the code is functional but falls below good readability standards.
Run 2
The code exhibits moderate readability. It has clear class and method organization with descriptive names, but suffers from several readability issues. The constructor contains a lengthy conditional block for axis alignment detection with repetitive nested if-else statements and magic number comparisons. The checkIntersection method has three similar branches that could be consolidated, with multiple blank lines fragmenting the logic. Variable names like 'sy' and 'sz' are cryptic, while 'temp1' and 'temp2' lack clear intent. The intersectsBox method is repetitive with eight nearly identical bounding box corner checks. Action granularity is generally good with one operation per line, but the mathematical expressions are dense. The code mixes coordinate transformations with intersection logic, making the flow harder to follow. Some methods are well-structured, but the overall complexity of spatial transformations and repeated patterns reduces clarity.
Run 3
The code is generally structured but suffers from several readability issues. The constructor contains deeply nested conditionals (up to 3-4 levels) for axis alignment detection, making it hard to follow. Variable names like 'rx2', 'sy', 'sz', 'v1', 'v2', 'temp1', 'temp2' are terse and non-descriptive. The checkIntersection method has complex branching logic and mixes multiple actions per line (e.g., 'v1.set(cx-orig.x, cy-orig.y, cz-orig.z)'), reducing clarity. Several methods like intersectsBox have repetitive blocks (8 nearly identical corner checks) that could be looped. However, the code has good organization with clear method separation, appropriate use of inner class, helpful comments explaining ray-origin cases and box-intersection logic, and consistent formatting. The use of boolean flags like 'transform' and 'uniform' is clear. Mathematical operations are compact but reduce readability for those unfamiliar with the geometry. Overall structure is logical but implementation details and naming could be more expressive.
Run 1
1. Code Structure: Responsibilities are logically separated into geometry, mapping, and an intersection class, though the constructor mixes initialization with repetitive transformation optimization. 2. Nesting: Generally shallow, with early returns simplifying flow; constructor branches and bump-mapping logic add moderate nesting. 3. Clarity of intent: Method names and explanatory comments establish purpose, but abbreviated fields, generic temporaries, and undocumented mathematical formulas require careful interpretation. 4. Code length: Mostly purposeful, but repeated axis permutations, quadratic calculations, and eight explicit corner checks make it longer than necessary. 5. Action granularity: Most executable lines perform one action; grouped declarations and chained assignments slightly reduce scanability. 6. Reading flow: Methods follow coherent sequences, supported by comments and whitespace, but inconsistent brace indentation, dense arithmetic, and reused mutable vectors interrupt otherwise natural reading.
Run 2
Code Structure: Responsibilities are logically separated into geometry methods and an intersection helper class, though the constructor contains repetitive transformation cases. Nesting: Generally shallow, with early returns keeping intersection and bounding-box checks manageable; constructor branches add moderate nesting. Clarity of intent: Method names and explanatory comments communicate purpose, but abbreviated fields, generic temporary variables, and dense mathematical expressions require careful interpretation. Code length: Reasonable for the functionality, but repeated axis permutations, quadratic calculations, and eight explicit corner checks increase length unnecessarily. Action granularity: Most statements perform one action per line, although grouped declarations and chained assignments obscure individual values. Reading flow: Methods follow coherent procedural sequences, and comments explain geometric cases; inconsistent brace indentation, tightly spaced arithmetic, and switching between local and world coordinates interrupt smooth reading.
Run 3
Code Structure: Responsibilities are logically separated into geometry, mapping access, and an intersection helper class, though the constructor and intersection calculations are lengthy. Nesting: Mostly shallow, with manageable two-level conditional branches and useful early returns. Clarity of intent: Method names and explanatory comments communicate purpose, but abbreviated fields, generic temporaries, and undocumented mathematical formulas require careful interpretation. Code length: Repeated axis-permutation branches, quadratic calculations, and eight explicit corner checks add avoidable repetition. Action granularity: Most statements perform one action per line, although grouped declarations and chained assignments reduce scanability. Reading flow: Methods generally follow a natural sequence, and comments identify important geometric cases; inconsistent brace indentation, dense arithmetic formatting, mutable temporary-vector reuse, and transitions between coordinate systems interrupt that flow. Overall, readable for someone familiar with ray tracing, but clearer naming and factoring repeated logic would improve accessibility.