Sample
Schnappinger/aoi/artofillusion.script.ScriptedObjectController
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 39.1Δ 24.6 |
| Scalabrino | 0.788 | 0–1; higher is more readable | 59.6Δ 4.1 |
| Dorn | 0.32 | 0–1; higher is more readable | 50.2Δ 13.5 |
| Mi | 0.291 | 0–1; higher is more readable | 19.5Δ 44.2 |
| LLOC | 50 | Logical lines; fewer is more readable | 39.4Δ 24.3 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 3.1 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 24.8 |
| BTTF | 0.414 | 0–1; higher is more readable | 36.3Δ 27.4 |
| Human | 3.95 | 1–4; original rating | 63.7 |
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. | 3261.834 | −107.641 |
| Source linesThe number of non-empty source lines. | 120 | +48 |
| 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.757 | −7.136 |
Intercept 8.87 + feature contributions = -57.906 (log-odds).
Score = sigmoid(-57.906) = 0.
| Score | 0.788 |
|---|
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. | 120 | −3.212 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 111 | +3.102 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 111 | −2.126 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 118.83 | +1.251 |
| 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. | 110.983 | −1.036 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 110.983 | +0.986 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.213 |
Intercept 0.07 + feature contributions = -0.752 (log-odds).
Score = sigmoid(-0.752) = 0.32.
| Score | 0.291 |
|---|
| Score | 50 |
|---|
Run 1
The code is well-structured with clear class organization and logical method grouping. Nesting is minimal, with only one inner class and a single loop that could potentially be inverted for early exit but remains readable. Intent is clearly documented through Javadoc comments for each method, and naming conventions are strong. Code length is appropriate—no unnecessary verbosity. Each action generally occupies its own line, with the exception of the loop in getParameter, which remains clear. Reading flow is natural, starting with the constructor, followed by getters, and then action methods. The only slight concern is the anonymous Thread subclass in the constructor adds minor complexity. Overall, this code is highly readable with excellent documentation and clean structure.
Run 2
The code is well-structured with clear class organization and logical method grouping. It uses minimal nesting, with only one level in the thread's run() method and in the getParameter loop. Each method has a concise Javadoc comment, making intent obvious. The code is appropriately concise without being overly compressed. Action granularity is good—most methods perform a single, well-defined action, and the single-line if statements are simple and readable. The reading flow is natural, with methods ordered logically (constructor, getters, parameter access, object addition). Minor deductions: the inner while loop in the constructor could be extracted for clarity, and the repeated exception handling in the thread could be slightly simplified, but these are minor. Overall, highly readable code that follows good Java conventions and clean-code principles.
Run 3
The code is well-structured with clear class purpose and logical method organization. Javadoc comments explain each method's intent. Nesting is minimal—only a few if statements and a while loop, neither deeply nested. Methods are concise and perform single, focused actions (e.g., getTime only sets a flag and returns scene time). Reading flow is natural: constructor, then accessors, then parameter lookup, then addObject overloads. However, some minor issues reduce clarity: the constructor mixes object unwrapping with thread execution logic, and there's slight redundancy in the two addObject methods' comments being identical. The anonymous Thread class adds mild abstraction, but its intent is clear from context. Variable and method names are descriptive. Overall, the code is readable, maintainable, and follows good object-oriented practices, losing points only for slight structural mixing and duplicated comments.
Run 1
Code Structure: The class is logically organized into initialization and small public methods, although the constructor combines setup with asynchronous script execution. Nesting: Most methods are flat; the anonymous thread and try/catch introduce moderate nesting, while unbraced loops and conditionals slightly hinder scanning. Clarity of intent: Descriptive method names and documentation explain the controller's purpose, but abbreviated variable names and implicit side effects, such as getScene() marking time usage, reduce clarity. Code length: The implementation is concise, though executionComplete() is duplicated across success and failure paths. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods follow a natural progression, but inconsistent indentation in exception handling, compact operator spacing, and inline thread creation interrupt otherwise straightforward reading.
Run 2
Code Structure: The class is logically organized into initialization, accessors, parameter lookup, and object addition, although the constructor mixes setup with asynchronous execution. Nesting: Most methods are flat; the anonymous thread and try/catch introduce moderate nesting. Clarity of intent: Descriptive method names and concise documentation explain the controller's purpose, but abbreviated constructor arguments and unexpected getter side effects reduce clarity. Code length: The implementation is compact, though duplicated executionComplete() calls and repeated object access add minor redundancy. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Methods follow a natural progression, but inconsistent indentation, omitted braces around control statements, and embedded thread creation interrupt an otherwise straightforward flow.
Run 3
Code Structure: The class is logically organized around script execution and small public access methods, though the constructor mixes initialization, object unwrapping, and asynchronous execution. Nesting: Most methods are flat; the anonymous thread and try/catch introduce moderate nesting. Clarity of intent: Method names and documentation communicate purpose well, but abbreviated identifiers and implicit side effects, such as getScene() marking time usage, require interpretation. Code length: Generally concise, although executionComplete() is duplicated and texture/material checks repeat accessor calls. Action granularity: Statements generally perform one action per line, with only conventional loop syntax combining operations. Reading flow: Methods follow a natural progression from setup to queries and object addition, but inconsistent brace indentation, omitted braces on control statements, and inline thread creation slightly interrupt readability.