Sample
Schnappinger/aoi/artofillusion.animation.AnimationPreviewer
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 16.4Δ 9.5 |
| Scalabrino | 0.635 | 0–1; higher is more readable | 27.4Δ 20.5 |
| Dorn | 0.046 | 0–1; higher is more readable | 28.4Δ 21.5 |
| Mi | 0.719 | 0–1; higher is more readable | 86.5Δ 79.5 |
| LLOC | 153 | Logical lines; fewer is more readable | 17.8Δ 10.9 |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs | 38.0Δ 31.0 |
| GPT-6.1 Sol | 13.33 | 0–20; mean of three runs | 12.2Δ 5.3 |
| BTTF | 0.178 | 0–1; higher is more readable | 9.6Δ 2.6 |
| Human | 2.03 | 1–4; original rating | 6.9 |
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. | 13527.709 | −446.414 |
| Source linesThe number of non-empty source lines. | 301 | +120.4 |
| 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.752 | −7.128 |
Intercept 8.87 + feature contributions = -324.272 (log-odds).
Score = sigmoid(-324.272) = 0.
| Score | 0.635 |
|---|
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. | 301 | −9.621 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 287 | +9.19 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 287 | −6.165 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 299.933 | +3.783 |
| 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. | 117.937 | −1.33 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 117.987 | +1.099 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.102 | −0.05 |
Intercept 0.07 + feature contributions = -3.024 (log-odds).
Score = sigmoid(-3.024) = 0.046.
| Score | 0.719 |
|---|
| Score | 153 |
|---|
Run 1
The code is generally readable and well-structured, with clear sections and Javadoc comments explaining the main phases. It uses a class-based approach with logical field grouping and helper methods, and the action granularity is mostly good—each line does one thing. However, several issues reduce readability. Nesting is deep in places, especially in the `run()` method, where nested try-catch blocks and anonymous inner classes obscure the flow. The `run()` method is too long and mixes concerns like rendering, timing, and UI updates, making the reading flow disorganized. Some magic numbers and repeated code blocks (e.g., timing and sleep logic) add unnecessary length and reduce clarity of intent. Also, the constructor has multiple responsibilities, from camera discovery to UI setup, which could be better separated. Overall, the code is above average but could be significantly improved by extracting methods (e.g., for frame rendering, delay handling) and flattening nested structures.
Run 2
The code is generally organized into clear sections (e.g., camera discovery, UI setup, rendering loop) with descriptive method names and comments. However, the constructor is quite long and performs multiple responsibilities: finding cameras, building the dialog, and setting up the preview. The run() method contains deeply nested loops, anonymous inner classes, and duplicated frame-timing logic, which hurts readability. Some lines combine multiple actions, particularly in loop headers and UI setup. Variable declarations are interspersed with logic, and magic numbers or implicit defaults appear. The reading flow is acceptable but could be improved by extracting methods such as 'collectCameras()', 'buildOptionsDialog()', 'renderFrame()', and 'waitForNextFrame()'. Overall, the code is understandable but not as flat or single-purpose as it could be.
Run 3
The code demonstrates excellent readability through clear method separation, descriptive naming, and consistent formatting. Each method has a single, well-defined responsibility (e.g., recordImage, retrieveImage, setLabels), keeping actions granular. The constructor is logically organized into distinct sections with helpful comments (finding cameras, creating components, displaying dialogs). Nesting is moderate - the run() method contains nested loops and inner classes for threading, which adds some complexity but remains understandable given the nature of animation preview generation. The flow is mostly natural: setup leads to dialog display, then thread execution with clear render-and-display logic. Minor deductions come from the deeply nested anonymous inner classes within run() and some duplicated sleep/delay patterns between the two loops, which could be extracted into a helper method. The long constructor also slightly impacts readability, though sections are well-demarcated. Overall, the code is clear, well-structured, and maintainable, with only minor opportunities for refactoring the timing logic and reducing nesting depth.
Run 1
Code Structure: Responsibilities are grouped into clearly named methods, but the constructor combines camera discovery, configuration, UI construction, and thread startup; run() mixes rendering, playback, and timing. Nesting: Rendering and playback contain deep nesting through loops, try/catch blocks, conditionals, and anonymous callbacks. Clarity of intent: Descriptive method names and section comments explain the workflow, although terse variables, numeric display modes, shared mutable state, and silently handled exceptions obscure details. Code length: The class is moderately long, with duplicated camera scans, timing logic, and UI-update patterns that could be extracted. Action granularity: Most statements perform one action, but assignments embedded in calls, grouped declarations, and counter increments inside indexing reduce clarity. Reading flow: The configuration-to-rendering-to-playback sequence is natural and formatting is consistent, but long methods and nested asynchronous operations require substantial context tracking.
Run 2
Code Structure: Methods separate closing, labeling, and image serialization, but the constructor combines camera discovery, configuration, UI construction, and thread startup; run() combines rendering and playback. Nesting: Rendering and playback contain deeply nested loops, try/catch blocks, and anonymous Runnable implementations. Clarity of intent: Descriptive names and section comments explain the workflow, although terse variables and silent exception handling obscure details. Code length: The lengthy constructor and duplicated frame timing and UI-update logic could be extracted into helpers. Action granularity: Most lines perform one action, but grouped declarations, assignments within calls, and count increments within array indexing reduce clarity. Reading flow: The overall configuration-to-rendering-to-playback sequence is logical, with useful whitespace and comments, but concurrency callbacks and repeated error-handling blocks interrupt the flow.
Run 3
Code Structure: Comments divide the workflow into logical stages, and small helpers isolate labeling and image conversion, but the constructor and run() combine too many responsibilities. Nesting: Rendering and playback contain deeply nested loops, try/catch blocks, conditionals, and anonymous Runnable implementations. Clarity of intent: Most names and comments explain the animation-preview process, though abbreviated variables and silent exception handling obscure details. Code length: The class is moderately long, with duplicated timing and UI-update logic that could be extracted into helpers. Action granularity: Most statements perform one action, but combined declarations, assignment inside calls, and loop counter manipulation occasionally increase parsing effort. Reading flow: Setup, initial rendering, cached playback, and cleanup follow a natural sequence; however, lengthy methods, shared mutable fields, and transitions between background execution and UI callbacks make the control flow harder to follow.