Sample
Schnappinger/argoUML/org.argouml.gefext.ArgoFigRect
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0.061 | 0–1; higher is more readable | 73.6Δ 3.5 |
| Scalabrino | 0.696 | 0–1; higher is more readable | 37.3Δ 39.7 |
| Dorn | 0.101 | 0–1; higher is more readable | 33.3Δ 43.7 |
| Mi | 0.533 | 0–1; higher is more readable | 38.3Δ 38.8 |
| LLOC | 14 | Logical lines; fewer is more readable | 66.8Δ 10.2 |
| DeepSeek V4 Pro | 16 | 0–20; mean of three runs | 47.4Δ 29.7 |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs | 55.3Δ 21.8 |
| BTTF | 0.722 | 0–1; higher is more readable | 86.8Δ 9.7 |
| Human | 3.96 | 1–4; original rating | 77.1 |
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. | 1429.308 | −47.167 |
| Source linesThe number of non-empty source lines. | 108 | +43.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.089 | −7.633 |
Intercept 8.87 + feature contributions = -2.73 (log-odds).
Score = sigmoid(-2.73) = 0.061.
| Score | 0.696 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 169.982 | −3.535 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 109 | −2.823 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 169.972 | +1.938 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 59 | +1.304 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 107.842 | +1.098 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 59 | −0.933 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.025 | +0.7 |
Intercept 0.07 + feature contributions = -2.181 (log-odds).
Score = sigmoid(-2.181) = 0.101.
| Score | 0.533 |
|---|
| Score | 14 |
|---|
Run 1
The code is well-structured and readable. It has a clear class purpose, a single constructor, and straightforward delegation to a NotificationBroadcasterSupport instance. Nesting is minimal, with no deep conditional or loop structures. Each method performs one clear action (delegating to the notifier), and the reading flow is natural—methods are grouped logically. The code length is appropriate; no unnecessary verbosity in the logic itself. However, the extensive legal header at the top, while likely required, harms readability by forcing the reader to scroll before reaching meaningful code. Additionally, some lines are wrapped awkwardly (e.g., method signatures split across lines), slightly disrupting the reading flow. Overall, the code is clear and maintainable, with only minor formatting and header-related readability drawbacks.
Run 2
The code is largely readable due to its clear structure, low nesting, and straightforward delegation pattern. The class implements a simple notification emitter by wrapping NotificationBroadcasterSupport, and each method is short, focused, and performs a single action. Imports are organized, and the overall flow is natural. However, the score is reduced by the extremely long license header (which dominates the file and adds noise before the actual code), as well as some minor formatting inconsistencies (e.g., line breaks in method signatures and alignment). The comments are sparse but not harmful. Overall, the code is concise and easy to follow, but the header and minor style issues prevent a top score.
Run 3
The code is well-structured with clear separation of concerns: license headers, package declaration, imports, class definition, and method implementations follow a logical order. The class is flat with minimal nesting, making it easy to follow. Each method has a single clear purpose, and the delegation pattern to NotificationBroadcasterSupport is straightforward. Lines are generally concise, though some event-related lines could be broken down for better action granularity. The reading flow is mostly natural, with Javadoc references explaining method origins. Minor readability barriers include the lengthy license header and a few multi-purpose lines that mix notification firing with property changes. Overall, the code is clean and maintainable despite slight verbosity in headers and some line density.
Run 1
Code Structure: The class is logically organized around rectangle behavior and notification delegation, with short, focused methods. Nesting: There is no conditional or loop nesting, making execution easy to follow. Clarity of intent: Descriptive method names and straightforward delegation communicate purpose well, though the notification sequence number 0 and repeated "remove" string are unexplained. Code length: The implementation is concise, but lengthy license headers and verbose @see comments add visual overhead. Action granularity: Each statement performs a single clear action; constructing and sending the notification together remains easy to understand. Reading flow: Constructor, deletion behavior, and listener methods form a generally natural progression, although grouping the listener-removal overloads together and using more consistent indentation would improve scanning.
Run 2
Code Structure: The class is logically organized around construction, deletion, and notification delegation. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method names and straightforward delegation make the purpose clear, though the relationship between property-change events and notifications, and the literal sequence number 0, are unexplained. Code length: Implementation is concise, but extensive license text and repetitive, long @see comments interrupt scanning. Action granularity: Each statement performs one clear action; deletion steps are separated cleanly. Reading flow: Consistent formatting and short methods support natural reading, with minor distractions from long comments, wrapped signatures, and inconsistent spacing.
Run 3
Code Structure: A small, logically organized class separates construction, deletion behavior, and notification delegation. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method names and straightforward delegation make most behavior obvious, though the relationship between property-change and notification events and the sequence number 0 are unexplained. Code length: Executable code is concise, but extensive license headers and repetitive, long interface-reference comments add visual bulk. Action granularity: Each statement performs one clear action, with deletion steps explicitly separated. Reading flow: Consistent formatting and short methods support easy scanning, although wrapping long signatures and interleaving listener-management methods slightly interrupt the flow.