Sample
int-d798f78ce83e-I11
Split eligible integer literals into pairs of short-named intermediate variables
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.633 | 0–1; higher is more readable |
| Dorn | 0.278 | 0–1; higher is more readable |
| Mi | 0.575 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.355 | 0–1; higher is more readable |
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. | 3458.042 | −114.115 |
| Source linesThe number of non-empty source lines. | 131 | +52.4 |
| Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value. | 4.717 | −7.076 |
Intercept 8.87 + feature contributions = -59.922 (log-odds).
Score = sigmoid(-59.922) = 0.
| Score | 0.633 |
|---|
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. | 132 | −3.637 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 88 | +2.307 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 88 | −1.599 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 130.782 | +1.418 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 97.652 | +0.771 |
| 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. | 99.977 | −0.569 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.068 | +0.286 |
Intercept 0.07 + feature contributions = -0.953 (log-odds).
Score = sigmoid(-0.953) = 0.278.
| Score | 0.575 |
|---|
| Score | 39 |
|---|
Run 1
The code is generally well-structured and readable, with clear separation between the abstract base class and its directed/undirected implementations. Nesting is minimal and the use of `while (true)` loops in `computeNext()` is idiomatic for Guava's `AbstractIterator`. Intent is mostly clear, especially through good Javadoc comments and the explanatory example for undirected edge deduplication. However, a few issues reduce readability: the placeholder variables `a` and `b` in `Undirected`'s constructor are obfuscating and unnecessary; the dual role of `visitedNodes` (used for both skip logic and null-termination check) adds complexity; and the nullability annotations combined with `requireNonNull` calls create minor cognitive overhead. The code length is appropriate, actions are generally granular, and overall flow is natural.
Run 2
The code is well-structured with clear separation of base and subclass logic. Helper methods and fields have meaningful names, and comments explain non-obvious behaviors like self-loop handling and null safety. Nesting is moderate—computeNext() methods use while(true) loops with inner conditions, but control flow remains understandable. One action per line is generally followed. However, the undirected visitedNodes logic with null sentinel and the expressions like `graph.nodes().size() + (a + b)` add unnecessary cognitive load. The `a` and `b` variables are cryptic and could be inlined or explained. The reading flow is natural for an iterator implementation, but the deep duplication of traversal logic between Directed and Undirected classes slightly hurts clarity. Overall, readable but could be improved by simplifying the undirected duplicate-suppression strategy.
Run 3
The code is well-structured with clear separation between directed and undirected iteration logic. Comments, especially the detailed example for the Undirected case, greatly enhance clarity of intent. Nesting is minimal, with the main computeNext methods using flat loops. Action granularity is good—most lines perform one logical action. The code is concise for what it accomplishes, and the use of helper methods like advance() improves readability. Minor deductions: the Undirected constructor contains seemingly magic numbers (a=2, b=-1) that could confuse readers; the nullable annotations and manual null checks add slight cognitive overhead, though they are well-documented. Overall, this is highly readable code with strong conventions.
Run 1
Code Structure: Well organized into a shared iterator base and separate directed and undirected implementations, with traversal advancement centralized. Nesting: Mostly shallow, although the undirected implementation has nested loops and a conditional. Clarity of intent: Descriptive names and comments explain duplicate suppression, self-loops, and null-safety invariants. However, constants a and b obscure a simple capacity adjustment, and nullable iterator state requires careful tracking. Code length: Implementation is reasonably concise; the lengthy example documentation is useful but adds reading overhead, while the capacity constants are unnecessary. Action granularity: Statements generally perform one action per line; iterator advancement within return expressions introduces minor compactness. Reading flow: Methods follow a natural traversal sequence, aided by early returns and explanatory comments. The initial null insertion and eventual visited-set clearing make the undirected lifecycle somewhat less intuitive.
Run 2
Code Structure: Well organized into a shared iterator base and separate directed/undirected implementations. Nesting: Mostly shallow, although the undirected traversal combines nested loops and a conditional. Clarity of intent: Descriptive names and comments explain traversal invariants, duplicate prevention, and self-loop handling; however, unexplained constants a and b obscure a simple capacity adjustment, and nullable state adds complexity. Code length: Implementation is reasonably concise, but the extended example and repeated null-safety explanations increase reading length. Action granularity: Statements generally perform one action per line, with clear state updates. Reading flow: Initialization, advancement, and traversal follow a logical sequence, though infinite loops, shared mutable iterator state, and the initial null insertion require careful tracking.
Run 3
Code Structure: Shared traversal logic and separate directed/undirected implementations provide clear organization. Nesting: Directed traversal is shallow; undirected traversal has moderately nested loops and a conditional, but remains manageable. Clarity of intent: Descriptive names and comments explain duplicate suppression, self-loops, and null-safety invariants. However, the arbitrary constants a and b obscure a simple capacity adjustment, and initially adding null to visitedNodes is unintuitive. Code length: Implementation is reasonably concise, although the lengthy example and repeated null-safety explanations increase reading time. Action granularity: Statements generally perform one action per line, with clear state updates. Reading flow: Factory, initialization, shared advancement, and specialized traversal follow a natural progression. Understanding computeNext requires tracking mutable iterator state and AbstractIterator conventions, slightly reducing readability.