Sample
Schnappinger/argoUML/org.argouml.uml.cognitive.critics.CrNoIncomingTransitions
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 44.8Δ 3.6 |
| Scalabrino | 0.703 | 0–1; higher is more readable | 38.7Δ 2.6 |
| Dorn | 0.257 | 0–1; higher is more readable | 45.2Δ 4.0 |
| Mi | 0.559 | 0–1; higher is more readable | 44.9Δ 3.6 |
| LLOC | 43 | Logical lines; fewer is more readable | 41.1Δ 0.2 |
| DeepSeek V4 Pro | 15.67 | 0–20; mean of three runs | 43.9Δ 2.6 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 2.3 |
| BTTF | 0.476 | 0–1; higher is more readable | 42.6Δ 1.3 |
| Human | 3.71 | 1–4; original rating | 41.3 |
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. | 3252.079 | −107.319 |
| Source linesThe number of non-empty source lines. | 160 | +64 |
| 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.94 | −7.41 |
Intercept 8.87 + feature contributions = -41.859 (log-odds).
Score = sigmoid(-41.859) = 0.
| Score | 0.703 |
|---|
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. | 161 | −4.664 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 96 | +2.583 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 159.904 | +1.825 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 96 | −1.782 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 92.963 | +0.695 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.483 |
| 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. | 92.963 | −0.272 |
Intercept 0.07 + feature contributions = -1.062 (log-odds).
Score = sigmoid(-1.062) = 0.257.
| Score | 0.559 |
|---|
| Score | 43 |
|---|
Run 1
The code is well-structured and readable. It follows a clear logical organization, with the predicate2 method effectively using guard clauses to handle different cases. Nesting is minimal, with only one level of indentation inside loops. The naming conventions are clear, and the comments explain the logic without being excessive. Action granularity is appropriate, with one main action per line. The reading flow is natural, allowing a developer to understand the critic's logic step-by-step. However, the method could be slightly more concise by combining some conditions, and the isSomeSubvertexOf method lacks null-safety for the subject parameter. Overall, the code demonstrates good readability and maintainability.
Run 2
The code has a clear overall structure with logical method separation and meaningful names. However, readability is significantly reduced by the `predicate2` method's multiple early returns and nested conditionals, which make the flow harder to follow despite comments attempting to explain state. The method mixes different levels of abstraction—checking pseudostate kinds, verifying top state, checking incoming transitions, then looping through transitions—without breaking them into helper methods. The `isSomeSubvertexOf` helper is well-extracted and clear. The code is not deeply nested (max 2-3 levels), and most lines perform a single action. Comments are generally helpful but some are redundant or verbose. Overall, the code is moderately readable but could benefit from decomposing `predicate2` into smaller, named boolean checks.
Run 3
The code is well-structured and highly readable. It has clear separation of concerns with a single public predicate method and a private helper. Nesting is minimal—early returns flatten the logic effectively. Intent is clear from method names and descriptive comments, especially the 'NO_PROBLEM' early exits. Action granularity is mostly one action per line, with logical grouping in the pseudostate checks. Reading flow is natural: guard clauses lead to the core logic, and comments explain non-obvious decisions. Minor deductions: some repetition in pseudostate kind checks could be condensed, and the long license header slightly detracts from readability. Overall, a clean, maintainable critic implementation.
Run 1
Code Structure: The class is logically organized into initialization, detection logic, a containment helper, and metadata reporting. Nesting: Guard clauses keep the main routine mostly flat; nested pseudostate checks and loop conditions remain manageable. Clarity of intent: Descriptive class and helper names, explicit result constants, and explanatory comments communicate the purpose well. Abbreviated variables such as dm, sm, k, and c, raw collections, and repeated facade calls reduce immediate clarity. Code length: Functional code is reasonably concise, although repetitive pseudostate checks and extensive license boilerplate increase reading effort. Action granularity: Statements generally perform one action per line, with only a few compound conditions requiring extra attention. Reading flow: Checks progress naturally from eligibility and exceptions to incoming transitions and composite-state handling. Inconsistent indentation and a long conditional slightly disrupt otherwise clear formatting.
Run 2
Code Structure: Well-organized class with separate initialization, detection, containment-checking, and metadata methods. Nesting: Early returns keep the main routine mostly flat; nested pseudostate checks and the traversal loop remain manageable. Clarity of intent: The class description, explanatory comments, and named result constants clearly communicate the purpose, although abbreviated variables such as dm, sm, k, and c and generic Object types reduce clarity. Code length: Functional code is reasonably concise, but repetitive pseudostate checks, extensive license text, and some redundant comments add reading overhead. Action granularity: Statements generally perform one action per line, with a single compound condition that is somewhat long. Reading flow: Validation, exemptions, incoming-transition checks, and composite-state handling follow a natural sequence. Mixed tab/space indentation, raw collections, repeated facade calls, and long lines slightly disrupt readability.
Run 3
Code Structure: Methods are logically separated into initialization, detection, containment checking, and metadata. Nesting: Guard clauses and early returns keep nesting shallow, with only modest nesting for pseudostates and transition checks. Clarity of intent: The class documentation, explanatory comments, and descriptive helper name make the purpose clear; abbreviated variables such as dm, sm, k, and c and raw Collection types reduce clarity. Code length: Functional code is reasonably concise, though repetitive pseudostate checks and extensive license text increase reading overhead. Action granularity: Statements generally perform one action per line, and the compound transition condition remains understandable. Reading flow: Checks progress naturally from exclusions to incoming transitions and composite-state handling, but inconsistent indentation, repeated facade calls, and a long conditional slightly disrupt scanning.