Sample
Schnappinger/argoUML/org.argouml.core.propertypanels.ui.UMLOFSStateListModel
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 29.4Δ 0.9 |
| Scalabrino | 0.749 | 0–1; higher is more readable | 47.9Δ 17.6 |
| Dorn | 0.129 | 0–1; higher is more readable | 35.6Δ 5.3 |
| Mi | 0.522 | 0–1; higher is more readable | 37.3Δ 6.9 |
| LLOC | 72 | Logical lines; fewer is more readable | 28.5Δ 1.8 |
| DeepSeek V4 Pro | 14.33 | 0–20; mean of three runs | 32.3Δ 2.0 |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs | 25.7Δ 4.6 |
| BTTF | 0.376 | 0–1; higher is more readable | 31.7Δ 1.3 |
| Human | 3.02 | 1–4; original rating | 30.4 |
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. | 6421.826 | −211.92 |
| Source linesThe number of non-empty source lines. | 239 | +95.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.605 | −6.907 |
Intercept 8.87 + feature contributions = -114.358 (log-odds).
Score = sigmoid(-114.358) = 0.
| Score | 0.749 |
|---|
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. | 240 | −7.461 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 172 | +5.212 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 172 | −3.526 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 238.833 | +2.929 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 88.892 | +0.63 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.062 | +0.339 |
| 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. | 88.971 | −0.103 |
Intercept 0.07 + feature contributions = -1.911 (log-odds).
Score = sigmoid(-1.911) = 0.129.
| Score | 0.522 |
|---|
| Score | 72 |
|---|
Run 1
The code demonstrates generally clear structure with logical class organization and proper method separation. Class and method purposes are evident from names. However, readability is hampered by several factors: excessive boilerplate license headers (not code logic but distracting), deep nesting in methods like ActionAddOFSState.doIt and getChoices reaching 3-4 levels, and some methods combining multiple actions per line (e.g., chained Model.getFacade() calls). Variable names like 't', 'c', 'cis' are cryptic. Many null/type checks create repetitive conditional blocks. The actionPerformed method shows reasonable flow but could be flattened. Comments are sparse in complex logic areas. Overall, competent but not exemplary readability.
Run 2
The code is generally well-structured with clear class and method separation. It uses consistent formatting, meaningful method names, and logical grouping of related operations. Nesting is moderate and justified in validation logic. Some duplication exists between methods checking ObjectFlowState/ClassifierInState chains (e.g., in buildModelList, isValidElement, and action classes), which slightly reduces clarity. The removeTopStateFrom loop could be simpler, and the empty collection check in ActionAddOFSState could use isEmpty(). Javadoc comments are helpful but occasionally verbose. Overall, the code is readable but would benefit from extracting the repeated type-checking pattern into a helper method.
Run 3
The code shows moderate readability with clear organization through logical class structure and method segmentation. However, it suffers from inconsistent indentation and excessive empty lines between methods, disrupting reading flow. Nesting is reasonably flat (2-3 levels), though some methods like getChoices() and actionPerformed() contain multiple conditional branches that could be simplified. Intent is generally clear through descriptive method names, but some operations like 'removeTopStateFrom' violate single responsibility by mixing filtering logic with collection manipulation. Action granularity is acceptable but several lines combine multiple operations. The code length is inflated by verbose comments and duplicated model facade checks. Overall structure is logical but readability is hampered by inconsistent formatting and some overly complex conditionals.
Run 1
1. Code Structure: Well organized into a list model and separate nested add/remove action classes, with focused helper methods. 2. Nesting: Several methods contain two or three nested conditionals; guard clauses would make validation and removal easier to follow. 3. Clarity of intent: Method names and domain-specific API calls convey purpose, but abbreviations such as t, c, cis, and ret, along with raw collections and Object types, obscure meaning. 4. Code length: Methods are reasonably short, although repeated facade calls, boilerplate comments, and excess blank lines add verbosity. 5. Action granularity: Statements generally perform one action per line; wrapped method chains remain understandable. 6. Reading flow: The progression from construction and validation to addition and removal is natural, but repeated type checks, lengthy call chains, and inconsistent spacing interrupt scanning.
Run 2
Code Structure: The list model and separate add/remove action classes provide logical organization, with small methods and focused helpers. Nesting: Several methods contain two or three nested conditionals; guard clauses could simplify validation and removal paths. Clarity of intent: Method names and model API calls generally communicate purpose, but abbreviations such as t, c, ret, and cis, raw collections, and pervasive Object types obscure meaning. Code length: Implementation methods are reasonably concise, though repeated target/type checks, boilerplate comments, and the lengthy license header increase reading overhead. Action granularity: Statements generally perform one action per line, and intermediate variables help separate operations. Reading flow: Consistent formatting and related method grouping support navigation, but repeated facade chains, uneven blank-line spacing, and wrapped expressions occasionally interrupt the flow.
Run 3
Code Structure: Logically organized into a list model and separate nested add/remove action classes, with focused methods. Nesting: Several methods contain two to three nested conditionals, making validation and removal harder to scan; guard clauses would simplify them. Clarity of intent: Descriptive method names and model API calls communicate the purpose, but abbreviated variables such as t, c, ret, and cis, raw collections, and pervasive Object types reduce clarity. Code length: Implementation is reasonably concise, though repeated facade checks, boilerplate comments, and the lengthy license header add reading overhead. Action granularity: Statements generally perform one action per line, with clear separation of retrieval, checks, and updates. Reading flow: Methods follow a natural check-fetch-update sequence, but repeated chained API calls, uneven spacing, and wrapped expressions occasionally interrupt the flow.