Sample
Schnappinger/aoi/artofillusion.CreateVertexTool
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 13.0Δ 6.8 |
| Scalabrino | 0.551 | 0–1; higher is more readable | 14.0Δ 5.8 |
| Dorn | 0.018 | 0–1; higher is more readable | 23.1Δ 3.3 |
| Mi | 0.48 | 0–1; higher is more readable | 31.4Δ 11.6 |
| LLOC | 185 | Logical lines; fewer is more readable | 14.5Δ 5.3 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 29.9Δ 10.1 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 16.2Δ 3.6 |
| BTTF | 0.155 | 0–1; higher is more readable | 8.6Δ 11.2 |
| Human | 2.88 | 1–4; original rating | 19.8 |
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. | 17335.217 | −572.062 |
| Source linesThe number of non-empty source lines. | 302 | +120.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.861 | −7.292 |
Intercept 8.87 + feature contributions = -449.684 (log-odds).
Score = sigmoid(-449.684) = 0.
| Score | 0.551 |
|---|
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. | 302 | −9.657 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 278 | +8.879 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 279 | −5.981 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 300.899 | +3.796 |
| 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. | 136.98 | −2.137 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 136.977 | +1.406 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.133 | −0.35 |
Intercept 0.07 + feature contributions = -3.975 (log-odds).
Score = sigmoid(-3.975) = 0.018.
| Score | 0.48 |
|---|
| Score | 185 |
|---|
Run 1
The code is generally well-structured with clear methods and comments explaining complex operations. However, it has several readability issues: mixed action granularity (some lines perform multiple operations), deeply nested conditional blocks in createBoundaryVertex, and inconsistent formatting. The mousePressed method is quite long with complex branching logic. Variable declarations are grouped at method starts rather than near usage. The copyright header and comments are good. Method names clearly indicate intent. The parameter update logic in createBoundaryVertex is complex and could benefit from helper methods. Overall, readable for experienced Java developers familiar with 3D mesh operations, but the dense sections reduce clarity.
Run 2
The code is moderately readable. It has clear structure with logical method separation and good Javadoc comments explaining intent. However, readability suffers in several areas: mousePressed is long and contains multiple branches with different logic paths for point, edge, and face modes. createBoundaryVertex is particularly complex with deep nesting, multiple nested loops, and unclear variable names (e.g., 'f', 'e', 'v1', 'v2'). The repeated triangle orientation checks are verbose and hard to follow. Magic numbers (e.g., using -1 as a sentinel) and inconsistent naming reduce clarity. The method does one logical action (creating a vertex) but mixes concerns: geometry manipulation, parameter updating, and edge smoothness copying. There is some duplication between mouseDragged and mouseReleased. Overall, the code is structured but dense, requiring domain knowledge to fully understand.
Run 3
The code is moderately readable. Structure is logical, with clear method separation and comments for major sections. However, several methods are quite lengthy (e.g., mousePressed, createBoundaryVertex), mixing multiple actions per line and obscuring intent. Nesting is acceptable in most places but becomes deeper in createBoundaryVertex with nested loops and conditionals. Clarity of intent is mixed: some method names are descriptive (findDragVector, createBoundaryVertex), but the main mousePressed contains many operations without explanatory comments. Code length is only slightly verbose, mostly driven by domain complexity. Action granularity is poor in spots—multiple statements on one line (e.g., newval[face.length][0] = newval[face.length][1] = ...). Reading flow is generally natural but interrupted by large methods and occasional dense expressions. Overall, readable enough for experienced developers but could benefit from refactoring into smaller helper methods.
Run 1
Code Structure: Event handlers and focused helper methods provide logical organization, but createBoundaryVertex combines topology changes, smoothness copying, and parameter updates. Nesting: Mostly moderate, with deeper loop/conditional nesting in boundary processing; early returns help. Clarity of intent: Descriptive method names and section comments explain the purpose, while abbreviated variables, implicit mesh assumptions, and dense orientation checks require extra interpretation. Code length: Reasonable for the functionality, but duplicated drag handling, refresh calls, and face-orientation logic could be extracted. Action granularity: Most statements perform one action per line; chained assignments and compound expressions are exceptions. Reading flow: Consistent formatting and the press-drag-release sequence are easy to follow, though the long boundary helper and repeated casts interrupt the flow.
Run 2
Code Structure: Event handlers and helper methods provide logical organization, but mousePressed and createBoundaryVertex combine several responsibilities. Nesting: Generally moderate, with early returns improving flow; nested loops and parameter-update branches add complexity. Clarity of intent: Descriptive method names, documentation, and section comments explain the purpose, while abbreviated variables and dense mesh-index expressions require careful interpretation. Code length: Mostly justified by the operations, but repeated drag handling, UI updates, face-orientation checks, and parameter-copy logic could be extracted. Action granularity: Most lines perform one action, although chained assignments, compound expressions, and grouped declarations reduce clarity. Reading flow: The press-drag-release sequence and consistent formatting are natural to follow, but long methods, omitted braces, and detailed topology manipulation interrupt the otherwise clear progression.
Run 3
Code Structure: Event handlers and helper methods provide logical organization, but mousePressed and createBoundaryVertex combine several responsibilities. Nesting: Generally moderate, with deeper loops and conditionals in boundary creation and parameter updates. Clarity of intent: Descriptive method names, documentation, and section comments explain the tool's purpose; abbreviated variables and dense mesh-index expressions obscure implementation details. Code length: Reasonable for the functionality, but repeated drag handling, UI updates, face-orientation checks, and parameter-copy logic could be extracted. Action granularity: Most lines perform one action, although chained assignments and long expressions reduce clarity. Reading flow: The press-drag-release sequence and sequential boundary-update sections are natural, but omitted braces, shared mutable state, and lengthy topology manipulation require careful tracking.