Sample
Schnappinger/argoUML/org.argouml.uml.ui.behavior.state_machines.ButtonActionNewGuard
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 55.2Δ 0.4 |
| Scalabrino | 0.7 | 0–1; higher is more readable | 38.0Δ 16.8 |
| Dorn | 0.529 | 0–1; higher is more readable | 61.7Δ 6.9 |
| Mi | 0.564 | 0–1; higher is more readable | 47.5Δ 7.3 |
| LLOC | 21 | Logical lines; fewer is more readable | 58.4Δ 3.6 |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs | 73.9Δ 19.1 |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs | 73.8Δ 19.0 |
| BTTF | 0.614 | 0–1; higher is more readable | 60.4Δ 5.6 |
| Human | 3.91 | 1–4; original rating | 54.8 |
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. | 1818.147 | −59.999 |
| Source linesThe number of non-empty source lines. | 94 | +37.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. | 5.179 | −7.769 |
Intercept 8.87 + feature contributions = -21.298 (log-odds).
Score = sigmoid(-21.298) = 0.
| Score | 0.7 |
|---|
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. | 95 | −2.327 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 54 | +1.131 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 93.919 | +0.903 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 54 | −0.818 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 84.095 | +0.552 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.042 | +0.538 |
| 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. | 84.979 | +0.066 |
Intercept 0.07 + feature contributions = 0.114 (log-odds).
Score = sigmoid(0.114) = 0.529.
| Score | 0.564 |
|---|
| Score | 21 |
|---|
Run 1
The code is well-structured with a clear class hierarchy, clean method separation, and good use of early returns to reduce nesting. Method names clearly indicate intent, and action granularity is consistent with one operation per line mostly. Imports are organized, and comments are appropriate. The main readability issues are the excessive license header (which obscures the actual code start) and slight verbosity in constructor setup and actionPerformed where repeated TargetManager calls could be streamlined. Overall the code is straightforward and maintainable, only minor improvements needed.
Run 2
The code is well-structured with clear separation of concerns: constructor, action handler, state check, and configuration methods. It is almost entirely flat with minimal nesting (only one early-return guard clause). Intent is clear from descriptive method names and the Javadoc comment. Code length is appropriate—no redundant lines or bloated logic. Each meaningful action generally occupies its own line, improving readability. Reading flow is natural: the actionPerformed method follows a logical sequence of validation, execution, target resolution, and navigation. Licensing headers are verbose but standard practice and don't affect code readability. Minor deductions: the early return could be avoided, and inline conditional logic is slightly compact, but overall the code is highly readable.
Run 3
The code is highly readable with clear logical organization: fields, constructor, methods, and helper methods are well-ordered. Nesting is minimal—only one early return and one null check, keeping the action flow flat and easy to follow. Intent is explicit through descriptive method names, Javadoc, and consistent use of Translator and ResourceLoaderWrapper. Length is concise for the functionality, with no unnecessary repetition. Each action (retrieving target, building guard, setting target) is separated onto its own line, making granularity appropriate. Reading flow follows a natural top-down narrative: constructor sets up UI metadata, action performs the core logic, then helper methods encapsulate localized strings. The only minor drawbacks are the lengthy copyright header and slightly verbose import comments, but these do not affect the main logic.
Run 1
Code Structure: A small, focused class cleanly separates initialization, action handling, eligibility checks, and resource names. Nesting: An early return and a single conditional keep control flow shallow. Clarity of intent: Descriptive names and class documentation clearly communicate creating a guard or navigating to an existing one; generic Object types slightly obscure domain details. Code length: Implementation is concise, although the extensive license header delays reaching the functional code. Action granularity: Statements generally perform one action each, with intermediate variables making operations easy to follow. Reading flow: Methods follow a natural progression, and the action reads clearly as check eligibility, obtain target, retrieve or create guard, then select it. Framework calls introduce minor indirection but do not significantly hinder readability.
Run 2
Code Structure: Well organized into a constructor, action handler, enablement check, and resource-name helpers. Nesting: Minimal; an early return and a single conditional keep control flow flat. Clarity of intent: Descriptive class and method names, reinforced by the class comment, clearly convey guard creation or navigation; generic Object types slightly obscure model details. Code length: Implementation is concise, although the extensive license header delays reaching the relevant code. Action granularity: Statements generally perform one action each, with clear separation of initialization, guard retrieval or creation, and target selection. Reading flow: The action handler follows a natural sequence from checking eligibility to retrieving the target, ensuring a guard exists, and selecting it. Framework-specific calls require some background knowledge but do not substantially hinder readability.
Run 3
Code Structure: The class is logically organized into initialization, action handling, enablement checking, and resource helpers. Nesting: An early return and a single guard-creation conditional keep control flow shallow. Clarity of intent: Descriptive names and class documentation clearly explain creating or navigating to a transition guard, although generic Object types obscure domain details. Code length: Executable code is concise; the lengthy license header adds visual overhead without complicating the implementation. Action granularity: Statements generally perform one action each, with straightforward assignments and calls. Reading flow: The action naturally progresses from enablement validation to guard lookup, optional creation, and target selection. Repeated singleton/facade access slightly increases verbosity, but overall readability is high.