Sample
Schnappinger/argoUML/org.argouml.uml.ui.foundation.core.UMLAssociationEndOrderingCheckBox
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.999 | 0–1; higher is more readable | 91.3Δ 21.8 |
| Scalabrino | 0.76 | 0–1; higher is more readable | 52.1Δ 17.4 |
| Dorn | 0.646 | 0–1; higher is more readable | 70.6Δ 1.2 |
| Mi | 0.55 | 0–1; higher is more readable | 41.6Δ 27.9 |
| LLOC | 5 | Logical lines; fewer is more readable | 83.0Δ 13.5 |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs | 66.8Δ 2.6 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 14.2 |
| BTTF | 0.791 | 0–1; higher is more readable | 95.0Δ 25.6 |
| Human | 3.95 | 1–4; original rating | 69.5 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 71 | +28.4 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 680.99 | −22.473 |
| 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.219 | −7.828 |
Intercept 8.87 + feature contributions = 6.969 (log-odds).
Score = sigmoid(6.969) = 0.999.
| Score | 0.76 |
|---|
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. | 72 | −1.513 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.023 | +0.721 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 70.768 | +0.579 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 80.833 | +0.5 |
| 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. | 80.958 | +0.236 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 28 | +0.231 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 28 | −0.222 |
Intercept 0.07 + feature contributions = 0.603 (log-odds).
Score = sigmoid(0.603) = 0.646.
| Score | 0.55 |
|---|
| Score | 5 |
|---|
Run 1
The code is highly readable. The structure is logical, with a clear package declaration, imports, class definition, and constructor. Nesting is minimal—only one conditional block exists, and it is flat and easy to follow. The intent is clear: a specialized checkbox for UML association end ordering. Code length is concise and appropriate; the lengthy comments are standard license headers, not functional clutter. Each action is on its own line, and the buildModel method is a short sequence of straightforward calls. The reading flow is natural, moving from constructor setup to behavior. Minor deductions: the license headers are verbose, and the method call chain in setSelected slightly reduces readability, but overall the code is maintainable and clear.
Run 2
The code is generally readable due to its clear structure and intent. The class has a single responsibility, with a short constructor and one overridden method. Nesting is minimal (one if statement), and action granularity is acceptable, though the buildModel method contains a multi-line conditional expression that could be simplified for better clarity. The lengthy copyright headers (over 40 lines) significantly detract from readability, obscuring the actual code at the top of the file. Reading flow is natural for a small class, but the heavy comment block disrupts initial navigation. Overall, the logic is straightforward, but the verbosity of legal text and the slightly dense conditional reduce the score.
Run 3
The code is highly readable due to its clear structure, minimal nesting, and concise implementation. The class has a single responsibility, with a straightforward constructor that delegates localization and action setup. The `buildModel` method uses one level of nesting with a null guard, making the logic easy to follow. Each line performs a single action, and method names clearly convey intent. Imports are minimal and focused. The only minor drawbacks are the extensive license header comments, which add length but are typical for open-source projects, and the slightly verbose chained method call in `setSelected`, though it remains understandable. Overall, the code follows clean coding practices and is easy to read.
Run 1
Code Structure: The class is logically organized with imports, a constructor, and a single model-update method. Nesting: Control flow is shallow, with only one null-check conditional, though nested method calls add visual complexity. Clarity of intent: Descriptive class and variable names make the ordered-association checkbox purpose clear; framework dependencies and minimal behavioral documentation require some external knowledge. Code length: Executable code is concise, but extensive license headers dominate the file and delay reaching the implementation. Action granularity: Statements generally perform one action each, with the selection update expressed as one compound calculation. Reading flow: Conventional Java layout supports natural reading, although the heavily wrapped setSelected expression slightly interrupts it.
Run 2
Code Structure: A small, logically organized class separates initialization from model synchronization. Nesting: Only one conditional introduces control-flow nesting, although the nested method calls require some parsing. Clarity of intent: The class name, ordering label, associationEnd variable, and setSelected call clearly indicate the checkbox's purpose; the minimal documentation does not explain its behavior when the target is null. Code length: Executable code is concise, but extensive licensing comments and boilerplate dominate the file. Action granularity: Statements generally perform one action each; the selection expression combines several lookups but remains manageable. Reading flow: Conventional package/import/class ordering and consistent formatting support natural reading, slightly interrupted by the long header and multiline call chain.
Run 3
Code Structure: The class is logically organized, with imports, a constructor, and a focused model-update method. Nesting: Control flow is shallow, containing only one null-check, though the nested method calls require some parsing. Clarity of intent: The class name, ordering label, and setSelected call clearly indicate an ordering checkbox; buildModel and generic Object typing provide less explicit context. Code length: Executable code is concise, but extensive license text and minimally informative documentation increase reading overhead. Action granularity: Each statement performs one primary action, with the selection calculation embedded in a single expression. Reading flow: Conventional Java layout and consistent indentation support natural reading, although the wrapped call chain slightly interrupts it.