Sample
int-e74d89aad944-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.773 | 0–1; higher is more readable |
| Dorn | 0.807 | 0–1; higher is more readable |
| Mi | 0.405 | 0–1; higher is more readable |
| LLOC | 53 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 12.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs |
| BTTF | 0.591 | 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. | 4154.724 | −137.106 |
| Source linesThe number of non-empty source lines. | 183 | +73.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. | 4.895 | −7.342 |
Intercept 8.87 + feature contributions = -62.378 (log-odds).
Score = sigmoid(-62.378) = 0.
| Score | 0.773 |
|---|
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. | 184 | −5.479 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 134 | +3.898 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 182.832 | +2.146 |
| 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. | 111.978 | −1.078 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 112 | +1.003 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.048 | +0.472 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 1.429 (log-odds).
Score = sigmoid(1.429) = 0.807.
| Score | 0.405 |
|---|
| Score | 53 |
|---|
Run 1
The code is generally well-structured with clear class-level Javadocs, sensible field separation, and meaningful methods. However, the `resolveContainerFactory` method significantly hurts readability. Its nested ternary-style `if-else` structure creates excessive depth and obscures the logic. The boolean check `if (!((...)))` is awkward and adds unnecessary parentheses. The fallback logic inside that nested block—setting `this.containerFactory` as a side effect—is not immediately obvious. Most other methods are flat and clear, but this method’s nesting and tangled branching pull the score down. Minor issues include a long concatenated exception message and inconsistent spacing between some members. Overall, the code is maintainable but would improve with refactoring `resolveContainerFactory` into early returns and a clearer priority path.
Run 2
The code has some positive qualities like good field grouping, descriptive method names, and an inner class for data encapsulation. However, the `resolveContainerFactory` method is deeply nested and has a convoluted condition with awkward double negatives, making it hard to follow. There's also inconsistent style (e.g., `if (!((condition)))` instead of a simple `if (!condition)`). The method mixes concerns like state mutation within a resolver. Some methods are well-documented but the flow is disrupted by unnecessary parentheses and a thrown-together exception message. The overall structure is a bit tangled, especially around nested conditionals and deferred state changes.
Run 3
The code has a clear, logical structure with sensible field grouping, getter/setter pairs, and a private descriptor class. However, readability is hurt by inconsistent nesting and awkward control flow, especially in `resolveContainerFactory` which uses a negated outer condition and deeply nested if-else blocks. Several lines contain multiple statements or actions, reducing action granularity. The use of double negatives like `if (!((...)))` adds cognitive overhead. Parts of the code are concise and well-documented, but the conditional logic and one-line if statements make the reading flow less natural. Overall it is maintainable but could be improved with flatter conditionals and clearer early returns.
Run 1
Code Structure: Well organized into configuration accessors, lifecycle initialization, endpoint registration, factory resolution, and a small descriptor class. Nesting: Generally shallow, but factory resolution unnecessarily nests its fallback chain inside a negated condition. Clarity of intent: Descriptive names, Javadoc, nullability annotations, and assertions explain responsibilities clearly; redundant parentheses and negation obscure otherwise simple conditions. Code length: Most methods are concise, though accessor boilerplate and extensive documentation increase overall length. Action granularity: Usually one action per line, but placing two if statements and multiple closing/opening braces on the same line reduces readability. Reading flow: Mostly natural and consistent, with factory resolution standing out for awkward formatting and inverted control flow. Early returns and conventional formatting would improve an otherwise readable class.
Run 2
Code Structure: Well-organized fields, configuration methods, lifecycle handling, registration logic, and a small descriptor class. Nesting: Mostly shallow, but resolveContainerFactory introduces unnecessary nesting and awkward brace placement. Clarity of intent: Descriptive names, documentation, nullability annotations, and assertions explain responsibilities clearly; redundant parentheses and negated conditions obscure straightforward decisions. Code length: Reasonable for the functionality, though accessor documentation and boilerplate increase scanning effort. Action granularity: Generally one action per line, except compressed conditional statements and braces in factory resolution. Reading flow: Configuration followed by initialization and registration is logical, but inconsistent conditional formatting interrupts the otherwise natural flow.
Run 3
Code Structure: Well organized into configuration accessors, lifecycle registration, factory resolution, and a small descriptor class. Nesting: Mostly shallow, but resolveContainerFactory adds avoidable nesting and compresses adjacent conditionals onto one line. Clarity of intent: Descriptive names, Javadoc, nullability annotations, and assertions clearly communicate responsibilities; redundant parentheses and negated conditions obscure otherwise simple decisions. Code length: Reasonable for its responsibilities, though accessor documentation adds bulk and factory resolution could be simplified with early returns. Action granularity: Generally one action per line, except for awkwardly combined conditional and brace formatting. Reading flow: Configuration followed by registration logic is natural, but inconsistent formatting in resolveContainerFactory and registerEndpoint interrupts scanning. Overall, readable and maintainable with localized conditional-style problems.