Sample
Schnappinger/argoUML/org.argouml.uml.ui.UMLTableCellRenderer
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 1 | 0–1; higher is more readable | 92.6Δ 8.0 |
| Scalabrino | 0.826 | 0–1; higher is more readable | 69.5Δ 15.1 |
| Dorn | 0.792 | 0–1; higher is more readable | 83.8Δ 0.8 |
| Mi | 0.656 | 0–1; higher is more readable | 75.2Δ 9.4 |
| LLOC | 8 | Logical lines; fewer is more readable | 73.8Δ 10.9 |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs | 53.1Δ 31.5 |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs | 62.2Δ 22.4 |
| BTTF | 0.811 | 0–1; higher is more readable | 97.0Δ 12.4 |
| Human | 3.97 | 1–4; original rating | 84.7 |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 69 | +27.6 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 607.821 | −20.058 |
| 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.13 | −7.695 |
Intercept 8.87 + feature contributions = 8.717 (log-odds).
Score = sigmoid(8.717) = 1.
| Score | 0.826 |
|---|
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. | 70 | −1.442 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.021 | +0.734 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 68.864 | +0.553 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 77.657 | +0.449 |
| 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. | 30 | +0.301 |
| 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 | +0.277 |
Intercept 0.07 + feature contributions = 1.338 (log-odds).
Score = sigmoid(1.338) = 0.792.
| Score | 0.656 |
|---|
| Score | 8 |
|---|
Run 1
The code is highly readable. It has a clear, logical structure with a simple class hierarchy and well-separated methods. Nesting is minimal, limited to a few if-else levels that remain easy to follow. Intent is clear from the class and method names, and the single override method directly implements the stated purpose. Length is concise; the only verbosity comes from legal headers, which are distinct from the functional code. Each line generally performs one action, and the reading flow is natural, moving from construction to value-setting logic. Minor deductions could apply for the slightly redundant else branch and the empty constructor, but these do not significantly hamper readability.
Run 2
The code is generally readable and well-structured. The class has a clear, single responsibility and uses inheritance appropriately. The overridden setValue method is flat, with only one level of nesting in the if-else chain, making the logic easy to follow. Variable names are short but clear, and the use of Model.getFacade() abstractions hides complexity. However, minor deductions apply: the else block could be simplified by using a ternary or combining conditions, and the method does two actions per line in a couple of spots (calling getFacade and getName). The lengthy copyright header adds noise, though it is typical for open-source code. Overall, clarity of intent and logical organization are strong.
Run 3
The code is well-structured with clear separation of concerns: license headers, package declaration, imports, class Javadoc, constructor, and a single overridden method. It is a short, focused class with minimal nesting (one if-else with an inner if-else). The intent is clear from the class and method Javadoc: render a table cell using a UML element's name. Action granularity is appropriate, with one logical action per line. Reading flow is natural. Minor deductions: the nested else-if could be flattened slightly, and the empty else branch (setText("")) could be simplified, but these are minor. The license header is verbose but standard for open-source code and does not affect readability of the logic.
Run 1
Code Structure: The class is logically organized, with a constructor and a focused rendering method. Nesting: Conditional depth is modest, although an else-if would flatten the nested else block. Clarity of intent: Descriptive names and class documentation clearly explain that model element names or strings become cell text. Code length: The implementation is concise, but the lengthy license header and explicit constructor add reading overhead. Action granularity: Each statement performs one clear action, with name retrieval separated from text assignment. Reading flow: Formatting and straightforward branching make execution easy to follow; the nested fallback slightly interrupts an otherwise natural flow.
Run 2
Code Structure: A small, focused class with clearly separated constructor and rendering method. Nesting: Only two conditional levels, though the nested else/if could be flattened into else if. Clarity of intent: Descriptive names and class documentation make the rendering purpose clear; handling model elements, strings, and other values is straightforward. Code length: Implementation is concise, although the explicit constructor adds little and the lengthy license header delays reaching the functional code. Action granularity: Each statement performs a single action, with name retrieval separated from text assignment. Reading flow: Conventional Java organization and consistent formatting support easy top-to-bottom reading, with only minor interruption from the nested fallback logic.
Run 3
Code Structure: A single focused renderer class cleanly separates construction from value rendering. Nesting: The conditional logic is shallow, although the nested else/if could be flattened into else-if. Clarity of intent: The class name, documentation, and straightforward setText calls clearly communicate the rendering behavior; fallback handling is easy to infer. Code length: The implementation is concise, but the extensive license header and explicit constructor add reading overhead relative to its small functionality. Action granularity: Each statement performs one clear action, with no compressed multi-action lines. Reading flow: Formatting and branch order provide a natural progression from model elements to strings to an empty fallback, with only minor interruption from the nested conditional.