Sample
Schnappinger/argoUML/org.argouml.notation.providers.uml.ClassifierRoleNotationUml
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 25.1Δ 20.1 |
| Scalabrino | 0.721 | 0–1; higher is more readable | 43.2Δ 38.2 |
| Dorn | 0.045 | 0–1; higher is more readable | 28.1Δ 23.1 |
| Mi | 0.519 | 0–1; higher is more readable | 37.0Δ 32.0 |
| LLOC | 106 | Logical lines; fewer is more readable | 23.1Δ 18.2 |
| DeepSeek V4 Pro | 12 | 0–20; mean of three runs | 15.5Δ 10.6 |
| GPT-6.1 Sol | 12.33 | 0–20; mean of three runs | 6.9Δ 2.0 |
| BTTF | 0.253 | 0–1; higher is more readable | 16.8Δ 11.9 |
| Human | 2.01 | 1–4; original rating | 5.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. | 8483.41 | −279.953 |
| Source linesThe number of non-empty source lines. | 299 | +119.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.549 | −6.823 |
Intercept 8.87 + feature contributions = -158.305 (log-odds).
Score = sigmoid(-158.305) = 0.
| Score | 0.721 |
|---|
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. | 300 | −9.586 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 211 | +6.561 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 211 | −4.421 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 298.922 | +3.769 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 100.973 | +0.825 |
| 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. | 100.97 | −0.611 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.334 |
Intercept 0.07 + feature contributions = -3.06 (log-odds).
Score = sigmoid(-3.06) = 0.045.
| Score | 0.519 |
|---|
| Score | 106 |
|---|
Run 1
The code is a UML notation parser for ClassifierRole, with all methods in one class. It has clear intent with extensive comments, but suffers from significant readability issues. The parseClassifierRole method is overly long (over 100 lines), with a complex token-handling loop that has several deeply nested if-else branches and repeated code blocks. The logic for handling bases is duplicated multiple times when encountering '/', ':', or ',' tokens. The code has unused variables (hasColon, hasSlash flags are assigned but never read), commented-out code, and inconsistent indentation. Method names like parseClassifierRole are descriptive, but the single giant method could be split into smaller focused methods. The code has a high cyclomatic complexity and uses labels (addBases:) for flow control, making it harder to follow. While it is logically structured, the method length and nested logic reduce its overall readability. The class-level documentation is helpful, but the implementation could use refactoring for better maintainability.
Run 2
The code is structured logically with clear class and method separation. However, the parseClassifierRole method is difficult to follow due to its length and complex branching logic. While the method maintains flat nesting with if-else chains, the token processing loop contains multiple state flags and repeated null checks that obscure the parsing flow. The action granularity is mostly acceptable, but many lines combine multiple operations. Several sections contain duplicated code (e.g., adding to bases list), and variable names like 'c', 'ns', 'it2' are terse. The Javadoc is thorough, especially the grammar description, but the method-level comments don't fully compensate for the implementation complexity. The formatNameList and trim operations in toString() show moderate clarity. The parsing error messages have inconsistent indentation and potentially incorrect message keys ('extra-test'). Overall, the code is maintainable but the parse method needs refactoring into smaller helper methods.
Run 3
The code has clear class-level documentation and logical separation of methods, which aids understanding. However, readability is significantly hindered by multiple factors: the header contains excessive license comments that bury the actual code; the tokenizer loop is deeply nested with many conditional branches, making the parsing logic hard to follow; several variables have unclear names like 's', 'c', 'd', 'b', and 'ns'; the `parseClassifierRole` method is overly long and mixes multiple responsibilities (tokenization, validation, model updates); and there is inconsistent formatting (tabs vs spaces, indentation issues). The use of labeled `continue` adds complexity. While each line generally performs one action, the overall flow is convoluted and requires careful study to understand the grammar being parsed and the model mutations performed.
Run 1
Code Structure: The class separates parsing, error reporting, and formatting, but parseClassifierRole combines token interpretation with model updates in one large method. Nesting: Several nested conditionals and loops, plus a labeled continue, increase mental effort. Clarity of intent: Grammar documentation and descriptive API calls explain the purpose, while abbreviated variables (s, cls, b, c, d), raw collections, and interacting parser flags obscure details. Code length: Repeated base-list initialization and identical error-handling blocks make parsing unnecessarily verbose; obsolete commented-out code adds clutter. Action granularity: Statements generally perform one action per line, with reasonable wrapping of longer calls. Reading flow: Execution broadly follows parsing, validation, updating, and formatting, but repeated branches, namespace resolution embedded in updates, and inconsistent indentation interrupt the flow.
Run 2
Code Structure: The class separates parsing, error reporting, and formatting, but parseClassifierRole combines token interpretation, validation, and model updates in one large method. Nesting: Multiple nested conditionals and loops, particularly base reconciliation, increase cognitive load; the labeled continue complicates control flow. Clarity of intent: Grammar documentation and descriptive API calls explain the purpose, but abbreviated variables, raw collections, boolean parsing states, and an unused parsed name obscure details. Code length: Repeated base accumulation and error construction make the implementation longer than necessary; duplicated documentation and obsolete commented code add clutter. Action granularity: Most statements perform one action per line, although chained model calls require additional interpretation. Reading flow: Parsing followed by model updates is broadly logical, and formatting is straightforward, but inconsistent indentation, repeated state handling, and mixed responsibilities interrupt the flow.
Run 3
Code Structure: The class separates parsing, error reporting, and formatting, but parseClassifierRole combines token interpretation and model updates in one large method. Nesting: Several nested conditionals and loops, plus a labeled continue, increase cognitive load. Clarity of intent: Grammar documentation and descriptive public method names help, but short variables such as cls, s, b, c, and d, raw collections, and boolean parsing states obscure details. Code length: Repeated base-list initialization, duplicate error handling, and verbose boilerplate make the implementation longer than necessary. Action granularity: Most statements perform one action per line, although chained model-access calls require additional interpretation. Reading flow: Execution generally progresses naturally from tokenization to model updates, but repeated branches, inconsistent indentation, an unresolved TODO, and labeled loop control interrupt readability.