Sample
int-07dcfc5553fa-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.691 | 0–1; higher is more readable |
| Dorn | 0.175 | 0–1; higher is more readable |
| Mi | 0.291 | 0–1; higher is more readable |
| LLOC | 29 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 13.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.33 | 0–20; mean of three runs |
| BTTF | 0.601 | 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. | 5409.555 | −178.515 |
| Source linesThe number of non-empty source lines. | 178 | +71.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.634 | −6.951 |
Intercept 8.87 + feature contributions = -105.396 (log-odds).
Score = sigmoid(-105.396) = 0.
| Score | 0.691 |
|---|
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. | 178 | −5.266 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 139 | −2.769 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 177.966 | +2.078 |
| 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. | 115.966 | −1.247 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 113.402 | +1.025 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.047 | +0.486 |
Intercept 0.07 + feature contributions = -1.552 (log-odds).
Score = sigmoid(-1.552) = 0.175.
| Score | 0.291 |
|---|
| Score | 29 |
|---|
Run 1
The code is a deprecated Netty class implementing an event loop group. Its structure is mostly linear with many constructor overloads, which bloats length but is conventional for this API. Nesting is minimal, but the newChild() method contains awkward inverted conditionals with empty if-bodies, harming readability. Clarity of intent is mixed: javadocs help, but some constructors lack documentation, and the NioIoHandler factory pattern is repetitive. Action granularity is generally good, though super() calls pack multiple arguments onto single lines. Reading flow is disrupted by the bizarre if (!condition) {} else pattern and unnecessary parentheses. The class is maintainable but not exemplary; improving the conditional clarity and consolidating constructors would raise the score.
Run 2
The code has clear structure and intent, with well-named methods and JavaDoc comments explaining each constructor. However, readability suffers from excessive constructor overloads that create redundancy and make the class hard to navigate. The `newChild` method contains awkward inverted conditionals (`if (!((argsLength > 1))) {} else { ... }`) that should be written as straightforward `if` statements. Action granularity is mostly good, with one operation per line, but the long parameter lists in constructors reduce clarity. The reading flow is disrupted by the many similar-looking constructors and the unnecessarily verbose empty if-blocks. Overall, the code is maintainable but could be significantly improved by simplifying constructor chains and cleaning up conditional logic.
Run 3
The code is generally well-structured with clear constructor delegation and Javadocs, but has some readability issues. The main problems are: (1) awkward inverted conditionals in newChild() using 'if (!((argsLength > 1))) {} else' pattern which is confusing and should be simple 'if (argsLength > 1)'; (2) many similar constructor overloads create repetition though this is common for builder-pattern APIs. Positives include flat nesting, logical organization, clear method names, good Javadoc coverage, and one-action-per-line formatting. The constructor chain is logical and follows a clear pattern. Overall the code is readable but the newChild() method unnecessarily obscures simple logic, and the numerous constructors add length that may be unavoidable given API flexibility requirements.
Run 1
Code Structure: Constructors are logically grouped, followed by operational methods and child creation; delegation keeps implementation organized. Nesting: Very shallow, with only a loop and simple conditionals. Clarity of intent: Descriptive names and Javadoc explain most behavior, but positional Object... arguments and casts obscure configuration handling. The negated conditions with empty if blocks and populated else blocks are unnecessarily confusing. Code length: Numerous constructor overloads and repetitive documentation increase scanning effort, although individual methods remain concise. Action granularity: Statements generally perform one action each; compact empty branches are an awkward exception. Reading flow: Consistent delegation and method ordering support natural reading, but long parameter lists, uneven indentation, and inverted conditional logic interrupt the flow.
Run 2
Code Structure: Constructors are logically grouped and delegate consistently, followed by operational methods, though numerous overloads add repetition. Nesting: Mostly flat, with only a simple loop and conditionals; empty if branches with negated conditions unnecessarily complicate newChild. Clarity of intent: Descriptive names and Javadoc clarify responsibilities, defaults, and deprecation, but positional Object varargs and casts obscure configuration handling. Code length: Individual methods are concise, but repetitive constructors and documentation make the class lengthy to scan. Action granularity: Statements generally perform one action each, although inline empty branches reduce visual clarity. Reading flow: Constructor progression and consistent delegation support natural reading; inconsistent parameter indentation, redundant parentheses, and inverted conditional logic interrupt it.
Run 3
Code Structure: Constructors are grouped logically, followed by operational methods and child creation; repeated overloads add clutter. Nesting: Mostly flat, with only shallow loops and conditionals, although empty if branches with negated conditions unnecessarily complicate newChild. Clarity of intent: Descriptive names and Javadoc explain the class and configuration, but positional Object... arguments and casts obscure type expectations. Code length: Individual methods are concise, while numerous similar constructors and repetitive documentation make the class lengthy. Action granularity: Statements generally perform one action each; compact empty-if/else formatting is a notable readability exception. Reading flow: Constructor delegation and consistent method responsibilities support natural reading, but uneven indentation, long signatures, redundant parentheses, and inverted conditional logic interrupt it.