Sample
Schnappinger/argoUML/org.argouml.uml.diagram.ui.PathConvPercent2
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 51.2Δ 17.2 |
| Scalabrino | 0.78 | 0–1; higher is more readable | 58.2Δ 24.2 |
| Dorn | 0.137 | 0–1; higher is more readable | 36.3Δ 2.3 |
| Mi | 0.611 | 0–1; higher is more readable | 64.7Δ 30.7 |
| LLOC | 37 | Logical lines; fewer is more readable | 45.2Δ 11.2 |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs | 29.9Δ 4.1 |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs | 30.7Δ 3.3 |
| BTTF | 0.217 | 0–1; higher is more readable | 12.5Δ 21.5 |
| Human | 3.24 | 1–4; original rating | 34.0 |
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. | 3049.381 | −100.63 |
| Source linesThe number of non-empty source lines. | 177 | +70.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.944 | −7.416 |
Intercept 8.87 + feature contributions = -28.375 (log-odds).
Score = sigmoid(-28.375) = 0.
| Score | 0.78 |
|---|
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. | 178 | −5.266 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 98 | +2.653 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 176.866 | +2.062 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 98 | −1.828 |
| 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.994 | −1.036 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 110.399 | +0.977 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.53 |
Intercept 0.07 + feature contributions = -1.839 (log-odds).
Score = sigmoid(-1.839) = 0.137.
| Score | 0.611 |
|---|
| Score | 37 |
|---|
Run 1
The code is generally clear and well-documented, with a logical class structure and meaningful method/field names. However, readability suffers in `applyOffsetAmount` due to low-level math logic with cryptic comments, variables like `recipnumerator`/`recipdenominator`, and a redundant `tanh` calculation that obscures intent. `stuffPoint` uses magic numbers (10, 5, 100) without explanation. The license header adds noise, and `setClosestPoint` is empty with no clarification. Nesting is shallow but the math-heavy method creates a cognitive load. Line-level clarity is decent, but some lines bundle multiple operations. The class is concise overall but could be improved by extracting the offset logic into a well-named helper and explaining the geometric intent more clearly.
Run 2
The code has decent structure with clear class organization and reasonable Javadoc comments, but suffers from readability issues. The method 'applyOffsetAmount' contains complex mathematical logic with comments explaining the math but using unclear variable names like 'recipnumerator' and 'recipdenominator'. The overall nesting is acceptable, but the mathematical operations make intent hard to follow. Code length is reasonable, though the custom 'tanh' implementation is unnecessarily verbose. Action granularity is mostly one action per line, but some complex expressions combine multiple operations. Reading flow is disrupted by the mathematical calculations and inline math comments that don't clearly explain the geometric purpose. The unused 'setClosestPoint' method and serialVersionUID add noise. While the basic structure and naming conventions are adequate, the mathematical complexity and unclear variable names significantly reduce clarity.
Run 3
The code is generally structured and readable, with appropriate class and method organization. However, it suffers from several issues: outdated Javadoc comments, unnecessary serialVersionUID placement, magic numbers (10, 5, 100), and a complex mathematical offset calculation in applyOffsetAmount that lacks sufficient clarity. While methods are logically separated and nested depth is acceptable, the reading flow is interrupted by verbose comments and unclear variable names like recipnumerator. The empty setClosestPoint method is a code smell. Despite these issues, the code maintains a reasonable action granularity and overall intent is discernible, earning a moderate score.
Run 1
Code Structure: The class is logically organized into state, construction, positioning, and mathematical helpers, though the empty setClosestPoint method lacks explanation. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: The class documentation explains label placement, but terse names such as res, p1, and p2, unexplained constants (10 and 5), and the geometric offset calculations require interpretation. Comments explain the normal calculation but not the rationale for absolute offsets or the tanh adjustment. Code length: Methods are reasonably concise, although repetitive boilerplate documentation and the lengthy license header increase scanning effort. Action granularity: Statements generally perform one action per line, with calculations separated into intermediate variables. Reading flow: Execution proceeds naturally from perimeter positioning to offset adjustment, but inconsistent line wrapping, redundant parentheses, and awkward mathematical variable names interrupt readability.
Run 2
Code Structure: Logically organized into focused methods for positioning, configuration, and offset calculation. Nesting: Shallow conditionals and early returns make control flow easy to follow. Clarity of intent: Class documentation explains the purpose, and mathematical comments help, but names such as stuffPoint, res, and recipnumerator require interpretation. The unexplained constants 10 and 5, absolute-value adjustments, and empty setClosestPoint method obscure some decisions. Code length: Implementation is reasonably concise, although extensive licensing text and repetitive, low-information Javadoc add reading overhead. Action granularity: Statements generally perform one action per line; mathematical expressions remain manageable. Reading flow: Consistent formatting and sequential calculations support natural reading, but unusual line wrapping and the geometry-specific offset logic require extra attention.
Run 3
Code Structure: Clearly organized into focused methods, with positioning and offset calculations separated. Nesting: Shallow conditionals and early returns keep control flow easy to follow. Clarity of intent: Class documentation explains label placement, and comments explain the normal-vector calculation, but names such as res, p1, and recipnumerator require interpretation. Magic constants 10 and 5, unexplained absolute-value adjustments, and an undocumented empty method obscure some behavior. Code length: Implementation is reasonably concise, although extensive boilerplate documentation and the manual tanh formula add reading overhead. Action granularity: Statements generally perform one action per line, making updates easy to track. Reading flow: Methods proceed logically from selecting a point to applying offsets, but inconsistent wrapping and dense geometric arithmetic interrupt the otherwise natural flow.