Sample
Schnappinger/aoi/artofillusion.animation.ActorEditorWindow
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 9.7Δ 9.4 |
| Scalabrino | 0.631 | 0–1; higher is more readable | 26.7Δ 7.6 |
| Dorn | 0.002 | 0–1; higher is more readable | 12.2Δ 6.9 |
| Mi | 0.299 | 0–1; higher is more readable | 20.5Δ 1.3 |
| LLOC | 263 | Logical lines; fewer is more readable | 8.9Δ 10.2 |
| DeepSeek V4 Pro | 11.67 | 0–20; mean of three runs | 13.9Δ 5.3 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 6.6 |
| BTTF | 0.121 | 0–1; higher is more readable | 4.3Δ 14.9 |
| Human | 2.85 | 1–4; original rating | 19.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. | 25224.084 | −832.395 |
| Source linesThe number of non-empty source lines. | 479 | +191.6 |
| 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.936 | −7.404 |
Intercept 8.87 + feature contributions = -639.329 (log-odds).
Score = sigmoid(-639.329) = 0.
| Score | 0.631 |
|---|
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. | 480 | −15.959 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 455 | +15.001 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 455 | −10.02 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 478.983 | +6.285 |
| 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.981 | −3.704 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 173.992 | +2.003 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.105 | −0.082 |
Intercept 0.07 + feature contributions = -6.406 (log-odds).
Score = sigmoid(-6.406) = 0.002.
| Score | 0.299 |
|---|
| Score | 263 |
|---|
Run 1
The code has clear, purposeful methods with descriptive names and good separation of concerns, but it suffers from excessive length and dense UI construction. The constructor is very long, packing many layout and component setup steps together, making it hard to follow. Nesting is moderate but some methods like doDelete and the inner EditCallback have multiple concerns and loops that reduce clarity. Action granularity is inconsistent: some lines perform multiple related operations while others are spread out. The overall structure is logical and the code is not tangled, but readability suffers due to verbose UI code, repetitive patterns (e.g., button enabling), and some methods mixing logic with UI updates. The copyright header and comments are helpful, but the class is overloaded with responsibilities (UI setup, event handling, business logic, inner classes for table model/renderer/editor), which adds cognitive load.
Run 2
The code has a clear overall structure with logical method separation, but readability suffers from several issues. The constructor is extremely long and contains the entire UI setup inline, making it difficult to comprehend. There's unnecessary nesting in the constructor, particularly with anonymous inner classes and event handling. Mixing UI code, validation logic, and business logic in methods like doDelete makes intent unclear. Variable names like 'id' and 'which' are ambiguous. Several methods contain multiple actions per line, reducing the ability to follow the flow. The anonymous inner classes (e.g., in ValueEditor) add complexity without clear benefits. Magic numbers (0, 1, 2 in layout coordinates) lack context. Some comments are helpful but don't compensate for the overall density. The code would benefit from extracting UI setup into separate methods, reducing nesting in event handlers, and using more descriptive variable names. While not completely unreadable, it requires careful study to understand.
Run 3
The code demonstrates generally clear structure with logical grouping of methods and UI setup, and follows a consistent naming convention. However, several factors reduce readability: the constructor is very long and mixes UI layout with initialization logic; there are deeply nested inner classes and event handlers; some methods perform multiple actions or have unclear intent (e.g., doAdd, doRemove); and there are confusing patterns like reusing variable names ('i', 'which') with subtle side effects. The use of raw types and mixed Java/Swing APIs adds complexity, while comments are sparse. The code is not unreadable but requires careful navigation and is unnecessarily verbose in places.
Run 1
Code Structure: Cohesive event-handler methods and dedicated inner classes organize responsibilities well, although the constructor mixes extensive layout, initialization, and event wiring. Nesting: Most methods are shallow, but skeleton synchronization and anonymous event callbacks introduce deeper nesting. Clarity of intent: Descriptive method names and useful comments explain most operations; generic variables such as which, s, olds, and news, string-based event links, and an empty-body search loop require extra interpretation. Code length: Individual handlers are generally concise, but the lengthy constructor and repeated dialog and component-update patterns could be extracted into helpers. Action granularity: Most lines perform one action, though assignments embedded in component-add calls combine initialization and registration. Reading flow: Consistent formatting, sectional comments, and logical method grouping support natural reading; long expressions, omitted braces, wildcard imports, and nested anonymous classes occasionally interrupt it.
Run 2
Code Structure: Clearly separated event handlers and dedicated inner classes organize responsibilities, though the large constructor mixes initialization, layout, and event wiring. Nesting: Most methods are shallow, but skeleton synchronization and anonymous event callbacks introduce deeper nesting. Clarity of intent: Descriptive method names and section comments explain the editor's purpose; generic variables such as which, s, olds, and news, direct array manipulation, and string-based event links reduce clarity. Code length: Most handlers are concise, but repetitive UI setup and button-state updates make the class lengthy. Action granularity: Generally one statement per line, although assignments embedded in component additions combine actions, and an empty-body search loop is easy to overlook. Reading flow: Consistent formatting and logical progression from setup to handlers to supporting classes aid navigation. Long expressions, occasionally omitted braces, and nested anonymous classes interrupt otherwise natural flow.
Run 3
Code Structure: Clearly separated event handlers and focused inner classes provide logical organization, although the constructor mixes extensive UI setup with state initialization. Nesting: Most methods are flat, but skeleton synchronization and nested anonymous event callbacks require more effort to follow. Clarity of intent: Descriptive method names and useful comments explain operations well; generic variables such as which, s, olds, and news, plus string-based event bindings, reduce clarity. Code length: Most handlers are concise, but the lengthy constructor and repetitive button configuration could be extracted into helpers. Action granularity: Usually one statement per line, though assignments embedded in component creation and the empty-body search loop obscure individual actions. Reading flow: Consistent formatting and ordering from initialization through handlers to supporting classes make navigation natural; long expressions, omitted braces, and callbacks interrupt that flow.