Sample
Schnappinger/aoi/artofillusion.spmanager.SPManagerUtils
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 17.7Δ 12.4 |
| Scalabrino | 0.797 | 0–1; higher is more readable | 61.6Δ 56.4 |
| Dorn | 0.011 | 0–1; higher is more readable | 20.5Δ 15.2 |
| Mi | 0.341 | 0–1; higher is more readable | 21.1Δ 15.8 |
| LLOC | 178 | Logical lines; fewer is more readable | 15.3Δ 10.1 |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs | 7.8Δ 2.5 |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs | 3.3Δ 2.0 |
| BTTF | 0.352 | 0–1; higher is more readable | 27.7Δ 22.4 |
| Human | 2.01 | 1–4; original rating | 5.3 |
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. | 13700.5 | −452.117 |
| Source linesThe number of non-empty source lines. | 412 | +164.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.405 | −6.608 |
Intercept 8.87 + feature contributions = -285.054 (log-odds).
Score = sigmoid(-285.054) = 0.
| Score | 0.797 |
|---|
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. | 413 | −13.587 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 328 | +10.608 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 328 | −7.106 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 411.862 | +5.347 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 107.988 | +0.938 |
| 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. | 107.971 | −0.908 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.086 | +0.108 |
Intercept 0.07 + feature contributions = -4.529 (log-odds).
Score = sigmoid(-4.529) = 0.011.
| Score | 0.341 |
|---|
| Score | 178 |
|---|
Run 1
The code has some structural organization with methods separated by comments, but suffers from multiple readability issues. Public mutable static fields (factory, builder) are a code smell. Methods like getJarFileContent have deep nesting (5+ levels) and duplicated logic. There are leftover debug System.out.println statements, commented-out code, and meaningless variable names (c, n, nl). Inconsistent indentation (tabs vs spaces) and brace styles reduce readability. The parseDouble method has confusing logic with poor naming (frac as multiplier), redundant comments, and a stray debug print inside a loop. Method signatures like getNodeFromNodeList with unaligned parameters are awkward. The empty catch block (Throwable t) hides errors. Overall, the code lacks clean separation of concerns and has unclear intent in several places, making maintenance difficult.
Run 2
The code is moderately readable but has several issues. Structure is logical with utility methods, but many are overly long (getJarFileContent has deep nesting and repeated logic). Nesting reaches 4-5 levels in file/zip handling, hurting comprehension. Intent is often unclear due to placeholder comments like 'Description of the Method' and vague parameter names. Code length is excessive - the two getJarFileContent overloads duplicate significant logic. Action granularity is inconsistent: some lines combine multiple operations while others are appropriately granular. Reading flow is disrupted by debug System.out.println statements left in parseDouble, unused variables (int i in deleteIntArrayElement), and inconsistent indentation (mixed tabs/spaces). Some methods like parseInt/parseDouble have complex logic without sufficient comments explaining edge cases. Static mutable fields (factory, builder) lack encapsulation. Positive aspects include separate concerns, reasonable method decomposition, and Javadoc presence, though content is often unhelpful.
Run 3
The code has a basic logical structure with related methods grouped in a utility class, but several factors reduce readability. Nesting is moderate to deep, especially in getJarFileContent and parseDouble. Javadocs are present but mostly useless placeholders ('Description of the Method'), while some non-obvious methods lack meaningful comments. Length is verbose for simple array operations. Action granularity is mixed—setDialogLocation is clear one-action-per-line, but parseDouble crams multiple operations into dense loops. Reading flow is disrupted by inconsistent brace style (K&R vs Allman), inconsistent indentation (tabs/spaces), and debug System.out.println calls left in code. The class-level static mutable fields factory/builder are also a design concern. The intent is generally discernible, but the inconsistent formatting and dead code significantly impede readability.
Run 1
Code Structure: Separate utility methods provide reasonable organization, but unrelated responsibilities share one class and ZIP-reading logic is duplicated. Nesting: Simple helpers are shallow, while archive lookup and double parsing contain deeply nested branches. Clarity of intent: Most method names convey purpose, but placeholder documentation, abbreviated variables, opaque parser state, and silent exception handling obscure details. Code length: Several helpers are concise; redundant branches, boilerplate comments, duplicated implementations, and debug output add unnecessary length. Action granularity: Most statements occupy separate lines, but inline conditionals, combined declarations, and decrementing an index within a condition compress distinct actions. Reading flow: Method boundaries help navigation, but inconsistent indentation, brace usage, spacing, and parameter alignment interrupt scanning. Overall, the code is understandable with effort, with archive extraction and numeric parsing notably harder to follow.
Run 2
Code Structure: Separate utility methods provide reasonable organization, but unrelated responsibilities and duplicated ZIP-reading logic weaken cohesion. Nesting: Most helpers are shallow, while ZIP extraction and numeric parsing contain substantial nesting. Clarity of intent: Method names generally communicate purpose, but placeholder documentation, abbreviated variables, undocumented index semantics, and complex parser state obscure details. Code length: Several helpers are concise, but duplicated implementations, boilerplate comments, redundant branches, and an unused declaration add unnecessary length. Action granularity: Most statements perform one action per line; inline conditionals, combined declarations, and decrementing an index within a condition reduce clarity. Reading flow: Method boundaries are clear, but inconsistent indentation, brace placement, tabs, and parameter alignment interrupt scanning. Silent exception handling and leftover debug output also make execution flow harder to interpret.
Run 3
Code Structure: Separate utility methods provide reasonable organization, but unrelated responsibilities and duplicated ZIP-reading logic weaken cohesion. Nesting: Most helpers are shallow, while ZIP extraction and double parsing contain substantial nesting. Clarity of intent: Method names generally communicate purpose, but placeholder documentation, abbreviated variables, undocumented index semantics, and intricate parsing state obscure details. Code length: Several helpers are concise; redundant branches, repeated implementations, boilerplate comments, and debugging output add unnecessary length. Action granularity: Most statements perform one action per line, but inline conditionals, combined declarations, and decrementing an index inside a condition reduce clarity. Reading flow: Methods are individually approachable, but inconsistent indentation, brace styles, awkward parameter alignment, empty exception handling, and debug prints disrupt the overall flow.