Sample
Schnappinger/argoUML/org.argouml.dev.UndoManagerWrapper
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 1 | 0–1; higher is more readable | 99.7Δ 63.7 |
| Scalabrino | 0.949 | 0–1; higher is more readable | 97.9Δ 62.0 |
| Dorn | 0.974 | 0–1; higher is more readable | 99.3Δ 63.4 |
| Mi | 0.614 | 0–1; higher is more readable | 65.3Δ 29.4 |
| LLOC | 1 | Logical lines; fewer is more readable | 98.3Δ 62.4 |
| DeepSeek V4 Pro | 5.67 | 0–20; mean of three runs | 2.3Δ 33.7 |
| GPT-6.1 Sol | 11 | 0–20; mean of three runs | 3.3Δ 32.7 |
| BTTF | 0.646 | 0–1; higher is more readable | 66.7Δ 30.7 |
| Human | 3.29 | 1–4; original rating | 36.0 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 93 | +37.2 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 5.129 | −7.694 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 66.608 | −2.198 |
Intercept 8.87 + feature contributions = 36.178 (log-odds).
Score = sigmoid(36.178) = 1.
| Score | 0.949 |
|---|
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. | 1 | +1.001 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.003 | +0.917 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 92.721 | +0.886 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 83.191 | +0.538 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 14 | −0.253 |
| 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. | 85 | +0.065 |
Intercept 0.07 + feature contributions = 3.622 (log-odds).
Score = sigmoid(3.622) = 0.974.
| Score | 0.614 |
|---|
| Score | 1 |
|---|
Run 1
The code consists almost entirely of commented-out blocks and lengthy license headers, leaving only an empty wrapper class. Structure is confusing: the class is declared but all meaningful logic is disabled, and it no longer extends UndoManager despite the name suggesting it should. Nesting is flat, and action granularity is irrelevant since there are no active actions. Clarity of intent is poor—the purpose of the wrapper is unclear and the commented code raises ambiguity about whether functionality is intentionally removed or pending restoration. Code length is inflated by verbose legal text and dead comments. Reading flow is disjointed, forcing the reader to scroll past irrelevant blocks before reaching the trivial active code. Overall, the file is largely unreadable due to dead code and lack of substantive implementation.
Run 2
The code is largely unreadable due to excessive commented-out code, which obscures any actual implementation. The active class contains only an empty constructor, making its purpose unclear. The structure is tangled with large copyright blocks and dead code. Nesting is flat but the file lacks meaningful content. Clarity of intent is very low; the class name suggests a wrapper but no behavior is present. Code length is unnecessarily long due to commented blocks. Action granularity is irrelevant since there is no logic. Reading flow is poor because the reader must navigate through noise to find that nothing is implemented.
Run 3
This code is essentially a skeleton with all functionality commented out. The active class contains only an empty constructor, while the entire UndoManager logic is disabled via large block comments. Structure is poor - the massive copyright headers consume most of the file, burying the actual code. The commented-out methods create confusion about intent: is this a wrapper, a stub, or dead code? Nesting is minimal but only because there is no logic. Clarity of intent is ambiguous - the class name suggests UndoManager wrapping, but no wrapping occurs. Code length is unnecessarily long due to verbose license text and dead code comments. Action granularity and reading flow cannot be properly evaluated because there are no actions to read. The file violates basic readability by requiring readers to wade through dozens of lines of comments before reaching two lines of functional code. This appears to be disabled or abandoned code that should either be restored or deleted.
Run 1
Code Structure: The package and class are conventionally organized, but nearly all functionality is commented out, leaving an empty shell. Nesting: Minimal nesting makes the remaining code easy to scan. Clarity of intent: The class name and documentation suggest undo-stack logging, but the active implementation does nothing, creating a mismatch between stated purpose and behavior. Code length: Extensive license text and disabled methods overwhelm the tiny active implementation; the explicit empty constructor adds little value. Action granularity: The disabled methods generally contain one clear action per line. Reading flow: Conventional ordering helps, but commented-out inheritance and large blocks of inactive code interrupt the flow and obscure the class's current role.
Run 2
Code Structure: The class is logically organized, but nearly all functionality is commented out, obscuring its current role. Nesting: Very shallow, with no complex control flow. Clarity of intent: The class name and documentation suggest undo-stack monitoring, but the active implementation is only an empty constructor, contradicting that purpose. Code length: Excessive relative to the active functionality; the lengthy license notices and disabled implementation dominate the file. Action granularity: The commented methods generally contain one action per line, making individual operations easy to follow. Reading flow: Conventional Java organization helps, but extensive commented-out code and the disabled inheritance declaration interrupt the flow and require readers to distinguish historical behavior from actual behavior.
Run 3
Code Structure: The package and class are conventionally organized, but commented-out inheritance and methods obscure the actual implementation. Nesting: Very shallow and easy to follow. Clarity of intent: The class name and documentation suggest an undo-stack wrapper, yet the active class only has an empty constructor, making its current purpose unclear. Code length: The extensive license header and disabled implementation overwhelm the tiny amount of active code; the empty constructor and its generic documentation add little value. Action granularity: Statements in the disabled methods generally perform one action per line. Reading flow: Formatting is consistent, but readers must separate inactive historical code from executable code, disrupting an otherwise straightforward flow.