Sample
Schnappinger/argoUML/org.argouml.model.euml.XmiReaderEUMLImpl
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 21.4Δ 19.4 |
| Scalabrino | 0.737 | 0–1; higher is more readable | 45.5Δ 43.6 |
| Dorn | 0.07 | 0–1; higher is more readable | 30.0Δ 28.1 |
| Mi | 0.484 | 0–1; higher is more readable | 32.0Δ 30.0 |
| LLOC | 113 | Logical lines; fewer is more readable | 21.5Δ 19.5 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 47.4Δ 45.4 |
| GPT-6.1 Sol | 12 | 0–20; mean of three runs | 5.6Δ 3.6 |
| BTTF | 0.313 | 0–1; higher is more readable | 22.8Δ 20.8 |
| Human | 1.9 | 1–4; original rating | 2.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. | 10322.97 | −340.658 |
| Source linesThe number of non-empty source lines. | 294 | +117.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.352 | −6.528 |
Intercept 8.87 + feature contributions = -220.716 (log-odds).
Score = sigmoid(-220.716) = 0.
| Score | 0.737 |
|---|
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. | 295 | −9.409 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 237 | +7.46 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 237 | −5.018 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 293.927 | +3.699 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 94.953 | +0.728 |
| 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. | 94.936 | −0.356 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.073 | +0.233 |
Intercept 0.07 + feature contributions = -2.592 (log-odds).
Score = sigmoid(-2.592) = 0.07.
| Score | 0.484 |
|---|
| Score | 113 |
|---|
Run 1
The code demonstrates good structure with clear method separation and logical organization within a single class. Nesting is moderate but controlled, except in the isUML14 method which has deeply nested conditionals that reduce readability. Intent is generally clear through descriptive method names and comments, though some methods like getIgnoredElementCount are trivial stubs. Code length is appropriate for the complexity involved, with no unnecessary verbosity. Action granularity is mostly one action per line, making the code easy to follow. Reading flow is natural, with methods arranged in a logical order and good use of comments to explain non-obvious decisions. The isUML14 method stands out as the weakest point due to its complex nesting and multiple level if statements that require careful reading to understand. Overall, this is well-written legacy code that would benefit primarily from refactoring the isUML14 method.
Run 2
The code is well-structured with clear method separation and logical organization. The class has a clear purpose with most methods having good cohesion. Nesting is generally flat, with only the isUML14 method having deeper nesting, though its purpose is clear. Intent is generally clear through descriptive method names and Javadoc comments, despite some commented-out code and TODOs. Code length is reasonable, though the parse method could be slightly more concise with extracted helper methods. Action granularity is good, with one main action per line. Reading flow follows a natural progression from constructor to utility methods to core functions. Minor improvements could include extracting URL handling logic and reducing nesting in isUML14.
Run 3
The code is generally readable with clear method names, Javadoc comments, and logical organization. Methods like getXMIUUIDToObjectMap() and getTagName() are straightforward. However, there are significant readability issues: the parse() method is overly long (50+ lines) with multiple nested conditionals and a long try-catch-finally block, making the flow hard to follow. The isUML14() method has deeply nested loops (4-5 levels) that obscure intent and increase cognitive load. Some sections, like the TODO comments and commented-out code, add noise. Action granularity is mostly reasonable, but several lines combine multiple operations (e.g., conditionals with assignments). Overall, the code is moderate in readability, hindered by excessive nesting and long methods.
Run 1
Code Structure: Responsibilities are organized into named methods, but parse combines input selection, identifier processing, resource loading, validation, and cleanup. Nesting: Most methods are flat, while isUML14 has deeply nested loops and conditionals that significantly hinder comprehension. Clarity of intent: Method names and documentation explain the overall purpose, but abbreviated variables, raw collection types, silent exception catches, and unimplemented methods obscure details. Code length: Small utility methods are concise; parse and isUML14 are lengthy and could benefit from extracted helpers. Commented-out code and repetitive annotations add clutter. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Consistent formatting and sequential parsing steps help, but nested detection logic, scattered TODOs, and complex cleanup interrupt otherwise natural reading.
Run 2
1. Code Structure: Methods separate public operations and format checks logically, but parse mixes input resolution, resource loading, event management, and cleanup. 2. Nesting: Most methods are flat, but isUML14 contains deeply nested loops and conditionals that make its logic difficult to follow. 3. Clarity of intent: Descriptive method names and documentation establish purpose; abbreviated variables, silent exception handling, and unfinished stubs reduce clarity. 4. Code length: Small methods are concise, while parse and isUML14 would benefit from helper extraction. Commented-out code, redundant checks, and boilerplate add clutter. 5. Action granularity: Statements generally perform one action per line, with consistent formatting; some chained calls and long expressions require extra attention. 6. Reading flow: Input-to-load sequencing is mostly natural, but nested metadata inspection, scattered TODOs, and cleanup-related control flow interrupt readability.
Run 3
Code Structure: Responsibilities are separated into methods, but parse combines input selection, identifier handling, loading, validation, and cleanup. Nesting: Most methods are straightforward, but isUML14 contains deeply nested loops and conditionals that obscure its logic. Clarity of intent: Descriptive method names and documentation explain the overall purpose; abbreviated variables, raw collection types, silent exception handling, and unexplained exceptions reduce clarity. Code length: The class is manageable, but the long parsing and detection methods, redundant checks, commented-out code, and TODOs add clutter. Action granularity: Statements generally perform one action per line, making individual operations easy to follow. Reading flow: Input-to-resource processing follows a logical sequence, but nested validation, cleanup handling, inconsistent wrapping, and legacy comment noise interrupt the flow.