Sample
Schnappinger/aoi/artofillusion.texture.FaceVertexParameterValue
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 23.7Δ 13.9 |
| Scalabrino | 0.781 | 0–1; higher is more readable | 58.6Δ 20.9 |
| Dorn | 0.088 | 0–1; higher is more readable | 32.0Δ 5.6 |
| Mi | 0.582 | 0–1; higher is more readable | 55.8Δ 18.2 |
| LLOC | 123 | Logical lines; fewer is more readable | 20.6Δ 17.0 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 29.9Δ 7.8 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 1.3 |
| BTTF | 0.266 | 0–1; higher is more readable | 18.2Δ 19.5 |
| Human | 3.31 | 1–4; original rating | 37.6 |
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. | 8334.881 | −275.051 |
| Source linesThe number of non-empty source lines. | 235 | +94 |
| 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.741 | −7.111 |
Intercept 8.87 + feature contributions = -179.292 (log-odds).
Score = sigmoid(-179.292) = 0.
| Score | 0.781 |
|---|
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. | 236 | −7.32 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 195 | +6.008 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 234.861 | +2.873 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 106.936 | +0.921 |
| 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. | 106.983 | −0.866 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.092 | +0.051 |
Intercept 0.07 + feature contributions = -2.34 (log-odds).
Score = sigmoid(-2.34) = 0.088.
| Score | 0.582 |
|---|
| Score | 123 |
|---|
Run 1
The code is generally readable with clear class purpose and method-level Javadoc. Structure is logical, and fields are named clearly. However, there are several readability issues: the constructor for FaceVertexParameterValue(FacetedMesh mesh, TextureParameter param) uses four nearly identical nested loops with repeated if-checks and index increments, making it verbose and error-prone. Nesting is moderate (two levels in loops), but action granularity is sometimes poor—multiple operations on one line (e.g., values[index++] = ...) reduce clarity. Some methods like equals() and writeToStream() are straightforward, but the duplicated loop patterns could be extracted for better intent. Reading flow is mostly natural, though repeated face/vertex loops feel monotonous. The class length is acceptable, but the constructor and setValue method are unnecessarily long. Overall, it's understandable but could be improved with helper methods and reduced repetition.
Run 2
The code is generally well-structured with clear class responsibilities, consistent naming, and good Javadoc documentation. It avoids deep nesting, keeps methods short, and maintains logical organization. However, readability suffers from repeated nested loops in the constructor — four nearly identical blocks for different parameter types — which could be extracted into a helper method. Array indexing via `faceStartIndex` and `values` is not immediately obvious and requires the reader to understand the internal storage layout. The `equals` method has a tedious pair of loops that could be simplified with `Arrays.equals`. Overall the intent is clear and the code is maintainable, but some duplication and storage-level details reduce clarity.
Run 3
The code is generally well-structured with clear class and method organization, and documentation is helpful. However, readability is hampered by repeated nested loops in the constructor, which could be consolidated. The repeated if-blocks for different parameter types create lengthy, repetitive code, and the constructor has multiple actions per line (e.g., `values[index++] = ...`). Deep nesting in the serialization constructor (if/else) and in the loops reduces flow. Variable names like `v`, `u`, `w` in getValue are vague without context. Overall, the intent is clear but the code is unnecessarily verbose and could be refactored for better flow and nesting.
Run 1
Code Structure: Clearly organized into constructors, accessors, copying, equality, and serialization, with focused methods. Nesting: Mostly shallow, although initialization and legacy deserialization use nested loops; omitted braces make their boundaries less explicit. Clarity of intent: Descriptive method names and useful documentation explain the face/vertex model, but the flattened storage invariant and serialization marker deserve explanation. Unused interpolation arguments and an empty exception message introduce ambiguity. Code length: Most methods are concise, but four nearly identical initialization branches add avoidable repetition. Action granularity: Generally one operation per line, with occasional combined indexing and incrementing. Reading flow: Consistent formatting and straightforward control flow make the class easy to follow; dense arithmetic spacing, abbreviated local names, and legacy-format handling slightly interrupt readability.
Run 2
Code Structure: The class is logically organized into constructors, accessors, copying, comparison, and serialization, with focused methods. Nesting: Most methods are shallow, though initialization and legacy deserialization use nested loops; omitted braces make their boundaries less explicit. Clarity of intent: Descriptive method names and useful documentation explain the face/vertex model. However, unused interpolation arguments, unexplained serialization marker -1, and an empty exception message introduce ambiguity. Code length: Generally concise, but four nearly identical initialization branches add avoidable repetition. Action granularity: Most statements perform one action, although index increments embedded in assignments slightly increase cognitive load. Reading flow: Consistent formatting and straightforward loops support natural reading, while dense arithmetic, abbreviated local names, and repeated branching occasionally interrupt it.
Run 3
Code Structure: Cohesive class with clearly separated initialization, access, copying, comparison, and serialization methods. Nesting: Mostly shallow, although unbraced conditionals containing nested loops require careful reading. Clarity of intent: Descriptive method names and useful documentation explain the face/vertex mapping; unused interpolation arguments, an unexplained serialization sentinel, and an empty exception message introduce ambiguity. Code length: Most methods are concise, but four nearly identical initialization branches add unnecessary repetition. Action granularity: Generally one action per line, with occasional embedded index increments combining assignment and state changes. Reading flow: Consistent formatting and straightforward method bodies support natural reading; dense arithmetic expressions, abbreviated local names, and legacy-format indexing make some sections harder to follow.