Sample
Schnappinger/aoi/artofillusion.translators.TextureImageExporter
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 19.4Δ 1.1 |
| Scalabrino | 0.585 | 0–1; higher is more readable | 19.9Δ 0.6 |
| Dorn | 0.069 | 0–1; higher is more readable | 29.7Δ 9.2 |
| Mi | 0.063 | 0–1; higher is more readable | 7.6Δ 12.9 |
| LLOC | 99 | Logical lines; fewer is more readable | 25.2Δ 4.8 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 34.8Δ 14.4 |
| GPT-6.1 Sol | 14.33 | 0–20; mean of three runs | 19.8Δ 0.7 |
| BTTF | 0.117 | 0–1; higher is more readable | 4.0Δ 16.5 |
| Human | 2.89 | 1–4; original rating | 20.5 |
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. | 10075.729 | −332.499 |
| Source linesThe number of non-empty source lines. | 195 | +78 |
| 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.826 | −7.24 |
Intercept 8.87 + feature contributions = -252.869 (log-odds).
Score = sigmoid(-252.869) = 0.
| Score | 0.585 |
|---|
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. | 196 | −5.903 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 176 | +5.351 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 176 | −3.618 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 194.871 | +2.314 |
| 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. | 138.964 | −2.221 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 138.995 | +1.438 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.1 | −0.027 |
Intercept 0.07 + feature contributions = -2.596 (log-odds).
Score = sigmoid(-2.596) = 0.069.
| Score | 0.063 |
|---|
| Score | 99 |
|---|
Run 1
The code is structured reasonably well with clear method separation and helpful comments. Javadoc documentations explain purpose well. However, the addObject method is overly long and contains deep nesting with complex conditional logic for handling different texture types. The UV coordinate range calculation has duplicated code in nested loops, reducing clarity. Some lines are excessively long (ternary expressions for filename assignment), making them difficult to read. Action granularity is mostly one action per line, but the conditional assignments pack too much logic into single statements. The reading flow is disrupted by the long if-else chains and nested loops within addObject. While the class has clear intent and good organization at the top level, the complexity in texture handling brings down readability. The use of magic numbers for array indices (output[1], output[5], etc.) also hurts clarity.
Run 2
The code is well-structured and highly readable. It has a clear class purpose, logical organization, and consistent naming conventions. Methods are mostly concise and focused, with one action per line in most cases. Deep nesting is limited, though the UV coordinate calculation loops introduce some nesting (2-3 levels) that slightly reduces flow. The intent of each method and conditional is generally clear, with sensible early returns. A few long lines with multiple conditional expressions (e.g., assigning filenames with nested ternaries) slightly hamper readability, but they remain understandable. Javadoc comments provide useful context. Overall, the code is well-factored and maintainable.
Run 3
The code has a clear class purpose and good documentation, but readability is hampered by several issues. The addObject method is overly long (around 60 lines) and handles too many responsibilities: texture registration, ImageMapTexture setup, ProceduralTexture2D setup, and UV coordinate bounds calculation. The deeply nested conditionals and repetitive bounds-checking loops increase cognitive load. Long ternary assignments on single lines (e.g., the filenames) violate action granularity and hurt readability. Ternary expressions for null checking are concise but reduce clarity. Duplicated min/max update logic appears twice for different coordinate types. The method would benefit from extraction into smaller, focused helper methods. The overall structure and naming are decent, but the density and nesting keep this from scoring higher.
Run 1
Code Structure: Clear class responsibility and sensible separation of filename generation, lookup, and image writing, but addObject combines texture registration with UV-bound calculation. Nesting: Most methods are shallow; addObject has nested type checks, loops, and conditionals that increase reading effort. Clarity of intent: Documentation, descriptive method names, and component constants communicate purpose well, while abbreviated variables, raw collections, casts, and unexplained procedural-output indices obscure details. Code length: Generally reasonable, but repeated filename checks and duplicated UV-bound updates could be extracted into helpers. Action granularity: Mostly one action per line, although chained assignments and filename generation with an increment combine operations. Reading flow: Methods follow a natural progression from collecting textures to exporting images; inconsistent brace indentation, long conditional expressions, and dense casting interrupt that flow.
Run 2
Code Structure: The class has a coherent responsibility and separates naming, lookup, and image writing, but addObject combines texture registration, component detection, and UV-bound calculation. Nesting: Most methods are shallow, while addObject contains several conditional levels and nested loops. Clarity of intent: Documentation, comments, and descriptive method names clarify the workflow; abbreviated variables, raw collections, casts, and unexplained output-array indices obscure details. Code length: Generally reasonable, but repeated component checks and duplicated coordinate-bound updates add avoidable length. Action granularity: Most statements perform one action, though chained assignments, grouped declarations, and an increment embedded in filename construction reduce explicitness. Reading flow: The progression from collecting texture information to exporting images is natural, but inconsistent brace placement, long conditional expressions, and dense formatting interrupt readability.
Run 3
Code Structure: The class has a clear responsibility and separates naming, lookup, and image writing into methods, but addObject combines texture registration and UV-range calculation. Nesting: Most methods are shallow, while addObject contains nested type checks, loops, and conditionals that increase reading effort. Clarity of intent: Documentation, component constants, and descriptive method names explain the purpose well; abbreviated variables and unexplained procedural-output indices obscure details. Code length: Generally reasonable, but repeated filename selection and UV-bound updates could be extracted into helpers. Action granularity: Most lines perform one action, although chained assignments and the increment embedded in filename creation combine operations. Reading flow: Registration, coordinate calculation, and export follow a logical sequence, but inconsistent brace placement, long conditional expressions, raw collections requiring casts, and dense formatting interrupt the flow.