Sample
Schnappinger/aoi/artofillusion.math.Mat4
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 12.0Δ 14.0 |
| Scalabrino | 0.823 | 0–1; higher is more readable | 68.5Δ 42.4 |
| Dorn | 0.005 | 0–1; higher is more readable | 15.8Δ 10.2 |
| Mi | 0.294 | 0–1; higher is more readable | 19.8Δ 6.3 |
| LLOC | 123 | Logical lines; fewer is more readable | 20.6Δ 5.4 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 34.8Δ 8.7 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 12.9 |
| BTTF | 0.311 | 0–1; higher is more readable | 21.8Δ 4.3 |
| Human | 3 | 1–4; original rating | 26.1 |
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. | 18868.801 | −622.67 |
| Source linesThe number of non-empty source lines. | 330 | +132 |
| 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.922 | −7.383 |
Intercept 8.87 + feature contributions = -489.184 (log-odds).
Score = sigmoid(-489.184) = 0.
| Score | 0.823 |
|---|
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. | 330 | −10.648 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 294 | +9.432 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 294 | −6.326 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 328.931 | +4.188 |
| 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. | 173.976 | −3.704 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 173.994 | +2.003 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.126 | −0.281 |
Intercept 0.07 + feature contributions = -5.265 (log-odds).
Score = sigmoid(-5.265) = 0.005.
| Score | 0.294 |
|---|
| Score | 123 |
|---|
Run 1
The code is well-structured and readable overall. It uses a clear class organization with logical method grouping and good Javadoc comments explaining intent. Names are descriptive (e.g., xrotation, viewTransform). Nesting is minimal—no deep conditionals or loops. Most lines perform one action, and matrix construction formatting is consistent, aiding readability. However, the times(Mat4) method is extremely long and repetitive, with 16 dense arithmetic expressions; it would benefit from helper methods or loops. Some long lines (toString, serialization) hurt scanning clarity. Constructor and serialization methods are concise but could be more compact. Overall, clear purpose and solid structure, but certain long methods reduce natural reading flow.
Run 2
The code is generally well-structured with clear method separation and helpful Javadoc comments. The matrix multiplication 'times' method is quite long and involves many repetitive, dense mathematical expressions, reducing readability. Nesting is minimal and flat. Action granularity in the constructor and serialization methods is good (one line per row), but the 'times' method packs multiple operations per line. Reading flow is mostly natural, but the alignment and formatting of matrix arguments are inconsistent in places (e.g., 'perspective' uses different indentation). Overall, the class is understandable for experienced developers but could benefit from helper methods or formatting improvements.
Run 3
The code is well-structured, with clear separation of concerns: fields, constructors, transformation methods, factory methods, and serialization. Nesting is minimal, and each method serves a single, clear purpose. The matrix multiplication method is long and repetitive, but this is inherent to 4x4 matrix math and is formatted consistently. Naming conventions are strong, and Javadoc comments explain intent. However, the code loses points for action granularity: many lines bundle two or four statements together (e.g., constructor assignments and serialization reads/writes), and the toString and equals methods are dense. Overall, readability is high for experienced Java developers, though a novice might find the domain-specific math intimidating.
Run 1
1. Code Structure: Cohesive matrix class with focused methods and sensible grouping of transformations, utilities, and serialization. 2. Nesting: Almost entirely flat, with only a simple guard in equals(), making control flow easy to follow. 3. Clarity of intent: Descriptive method names and documentation explain most operations; conventional matrix indices help, but terse intermediate variables and unexplained hash constants reduce clarity. 4. Code length: Most methods are concise; explicit matrix arithmetic and serialization introduce substantial repetition, though much reflects the fixed-size mathematical representation. 5. Action granularity: Constructors and serialization frequently place four assignments or calls on one line, reducing individual-action readability. 6. Reading flow: Consistent method patterns and matrix-row formatting support natural reading, but inconsistent indentation, dense expressions, and the very long toString() line interrupt it. Overall, readable and well documented, with formatting and repetition preventing a higher score.
Run 2
Code Structure: Cohesive matrix class with logically grouped operations, transformation factories, and serialization methods. Nesting: Almost entirely flat, with only a simple guard in equals(). Clarity of intent: Descriptive method names and documentation explain most operations; conventional matrix indices help, but terse intermediate names and unexplained hash constants reduce clarity. Code length: Methods are generally concise; explicit matrix arithmetic is appropriate but repetitive, and some documentation duplicates explanations. Action granularity: Constructors and serialization methods pack multiple assignments or calls onto each line, making individual actions harder to scan, though row grouping preserves matrix structure. Reading flow: Consistent method patterns and row-oriented layouts support natural reading, but uneven indentation, dense arithmetic, the lengthy toString() line, and inconsistent matrix formatting interrupt it.
Run 3
Code Structure: Cohesive matrix class with well-separated operations and logically grouped transformation factories. Nesting: Almost entirely flat, making control flow easy to follow. Clarity of intent: Descriptive method names and helpful documentation explain most operations; terse mathematical variables, undocumented axis assumptions, and unexplained hash constants reduce clarity. Code length: Most methods are concise, although repeated transformation formulas and explicitly expanded matrix operations make the class lengthy. Action granularity: Constructor assignments and serialization calls frequently place multiple actions on one line, reducing scanability, though row grouping reflects matrix structure. Reading flow: Consistent method patterns and matrix-shaped formatting support natural reading, but uneven indentation, dense arithmetic, the very long toString expression, and minor documentation errors interrupt it.