Sample
Schnappinger/aoi/artofillusion.TriMeshSelectionUtilities
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 15.4Δ 1.1 |
| Scalabrino | 0.471 | 0–1; higher is more readable | 6.8Δ 9.7 |
| Dorn | 0.022 | 0–1; higher is more readable | 23.8Δ 7.3 |
| Mi | 0.123 | 0–1; higher is more readable | 11.2Δ 5.3 |
| LLOC | 178 | Logical lines; fewer is more readable | 15.3Δ 1.2 |
| DeepSeek V4 Pro | 14.67 | 0–20; mean of three runs | 34.8Δ 18.3 |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs | 16.2Δ 0.3 |
| BTTF | 0.248 | 0–1; higher is more readable | 16.5Δ 0.0 |
| Human | 2.71 | 1–4; original rating | 16.5 |
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. | 14456.274 | −477.057 |
| Source linesThe number of non-empty source lines. | 321 | +128.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.544 | −6.815 |
Intercept 8.87 + feature contributions = -346.603 (log-odds).
Score = sigmoid(-346.603) = 0.
| Score | 0.471 |
|---|
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. | 322 | −10.365 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 275 | +8.775 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 274 | −5.867 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 320.894 | +4.076 |
| 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. | 121.96 | −1.501 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.978 | +1.164 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.114 | −0.162 |
Intercept 0.07 + feature contributions = -3.809 (log-odds).
Score = sigmoid(-3.809) = 0.022.
| Score | 0.123 |
|---|
| Score | 178 |
|---|
Run 1
The code is well-structured with clear separation of methods and good Javadoc comments. It follows a logical flow and maintains a consistent style throughout. The action granularity is generally good, with one main operation per line. However, there are some readability issues: use of raw types (HashSet, ArrayList, Iterator) instead of generics, magic numbers (-1), and some deeply nested conditional blocks, especially in findSingleEdgeStrip and the face comparison sections. The findSingleEdgeStrip method is quite long and complex. Variable names like e, f, v are concise but somewhat vague. Several lines are dense, packing multiple operations. Overall the code is understandable for domain experts but could benefit from refactoring into smaller helper methods and modernizing with generics.
Run 2
The code has clear method separation and each method has a single responsibility, with reasonable Javadoc comments explaining intent. Nesting is mostly flat, but some methods (e.g., findSingleEdgeStrip) contain multiple nested loops and conditionals that reduce readability. Variable names are generally descriptive, though some are abbreviated (e.g., 'v', 'e', 'f', 'ce'). The action granularity is good; most lines perform one operation. However, some multi-action lines like 'newSel[e[i].v1] = newSel[e[i].v2] = true;' are less clear. The reading flow is acceptable, but the use of primitive arrays instead of collection types adds mental overhead. Unused variable 'f' in findSingleEdgeLoop and 'Face f[]' in findSelectionBoundary suggests minor cleanup is needed. Overall, the code is readable but could benefit from refactoring more complex blocks into helper methods, using descriptive variable names, and reducing deeply nested loops.
Run 3
The code has a clear overall structure with documented methods, but readability suffers from several issues. Method names and Javadoc comments are helpful, but the logic within methods is often dense and hard to follow. It uses deep nesting in a few places (especially in `findSingleEdgeStrip`), multiple actions per line, and ambiguous variable names like `v`, `e`, `f`, `ce`, `ed`, etc. The `convertSelection` method is relatively clear, but the selection boundary and edge loop/strip methods feel tangled. Loops are straightforward, but there are several repeated structural patterns that increase verbosity. Overall, it is maintainable by someone familiar with the domain, but not immediately accessible to a general programmer.
Run 1
1. Code Structure: Methods are logically separated by selection operation, with private helpers for individual loops and strips. However, findSingleEdgeStrip combines several substantial tasks. 2. Nesting: Conversion and wrapper methods have manageable nesting, but strip traversal contains deeply nested loops and conditionals. 3. Clarity of intent: Descriptive method names, Javadoc, and algorithm comments explain the purpose well. Abbreviations such as v, e, f, ce, and fc1 make implementation details harder to follow. 4. Code length: Mostly purposeful, but repeated neighbor collection, face comparisons, and selection aggregation could be extracted into helpers. Unused variables and verbose legacy collection syntax add clutter. 5. Action granularity: Most statements perform one action, though chained assignments update several selection entries at once, and complex indexed expressions require extra parsing. 6. Reading flow: Consistent indentation, whitespace, comments, and early returns support natural reading. Omitted braces, lengthy boolean expressions, raw collections, and the long strip-finding method interrupt that flow.
Run 2
Code Structure: Methods are logically grouped by selection operation, with useful private helpers, but strip traversal combines several responsibilities. Nesting: Most methods have manageable nesting; candidate searches and shared-face checks in findSingleEdgeStrip are deeply nested. Clarity of intent: Descriptive method names, Javadocs, and algorithm comments explain the purpose well, while abbreviated variables, raw collections, and unused declarations reduce clarity. Code length: Generally reasonable, but the long strip method and repeated neighbor and face comparisons could be extracted into helpers. Action granularity: Most lines perform one action, although chained assignments update several selections at once and complex expressions require extra parsing. Reading flow: Consistent formatting, sequential algorithm stages, and early returns support natural reading; omitted braces, dense indexing, and repetitive conditionals occasionally interrupt it.
Run 3
1. Code Structure: Related operations are organized into clearly named methods, with private helpers separating single-edge traversal from selection aggregation. The strip helper could be decomposed further. 2. Nesting: Most methods have manageable nesting, but strip candidate searches and shared-face checks contain several nested loops and conditionals. 3. Clarity of intent: Javadocs and algorithm comments explain purpose well; abbreviated names, raw collections, and unused variables reduce clarity. 4. Code length: Generally purposeful, though repeated neighbor collection and shared-edge comparisons make the strip implementation unnecessarily lengthy. 5. Action granularity: Most lines perform one action, but chained assignments update multiple selection entries, and dense Boolean expressions require careful reading. 6. Reading flow: Consistent formatting, logical method ordering, and early returns support natural flow. Omitted braces, lengthy traversal methods, and repeated indexed expressions make complex sections harder to follow.