Sample
int-20454aa739fb-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.517 | 0–1; higher is more readable |
| Dorn | 0.041 | 0–1; higher is more readable |
| Mi | 0.119 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 10.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.259 | 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. | 8569.337 | −282.788 |
| Source linesThe number of non-empty source lines. | 159 | +63.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. | 4.755 | −7.133 |
Intercept 8.87 + feature contributions = -217.451 (log-odds).
Score = sigmoid(-217.451) = 0.
| Score | 0.517 |
|---|
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. | 160 | −4.629 |
| 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. | 180.981 | −4.001 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 136 | +3.967 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 136 | −2.7 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 180.969 | +2.115 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 158.984 | +1.812 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.076 | +0.208 |
Intercept 0.07 + feature contributions = -3.156 (log-odds).
Score = sigmoid(-3.156) = 0.041.
| Score | 0.119 |
|---|
| Score | 50 |
|---|
Run 1
The code shows moderate readability but has several issues. Structure is mostly logical with clear class hierarchy and methods, but some sections have confusing logic. The most significant problem is the inverted conditional pattern (e.g., `if (!((!condition))) {} else { ... }`) which obscures intent and makes code unnecessarily difficult to follow. Nesting depth is generally acceptable, but the parseConnectorConfigurationFile method is lengthy and combines multiple parsing strategies. The callback lambda in processExtraArgs is compact but hard to read due to inline conditionals. Some lines attempt multiple actions, reducing clarity. The method signatures are verbose but clear. Error handling is consistent. Action granularity suffers in places where multiple operations occur on single lines. Reading flow is disrupted by the unnatural conditional inversions. The code would benefit from extracting helper methods for validation logic and simplifying boolean expressions to improve readability.
Run 2
The code has basic structure with clear class purpose and method separation, but readability suffers significantly from several issues. The main problems are: (1) excessive use of negated conditionals with empty blocks like 'if (!((!connectorConfigs.containsKey(NAME_CONFIG)))) {} else {' which is extremely confusing and should be simplified to 'if (connectorConfigs.containsKey(NAME_CONFIG))'; (2) inconsistent brace style in lambda - some use braces some don't; (3) deeply nested lambda logic with ternary conditions making flow hard to follow; (4) duplicate logic for parsing connector configs creating unnecessary complexity; (5) long method signatures that span many lines without clear formatting; (6) mixed exception handling patterns with empty debug logging blocks. The code attempts to handle multiple file formats but the implementation obscures intent rather than clarifying it. Error handling creates ambiguity about which parsing strategy succeeded. Variable names are generally good and the Javadoc is helpful, but the actual implementation logic requires significant mental effort to understand.
Run 3
The code has clear structure at the class/method level, but readability is significantly reduced by awkward inverted conditionals (e.g., `if (!((!condition))) {} else { ... }`) and dense one-line lambda bodies with nested ternaries. Some methods like `processExtraArgs` mix multiple actions per line and rely on exceptions for control flow. While the parsing logic is broken into digestible steps, the intent is sometimes obscured by formatting choices and redundant comments. Import organization is flat but acceptable. Overall, the code functions but would benefit from cleaner conditionals, better line spacing, and more explicit error handling.
Run 1
Code Structure: Methods separate CLI setup, configuration parsing, and runtime construction logically, though parsing repeats validation. Nesting: Mostly shallow, but an avoidable nested else-if and empty conditional branches complicate control flow. Clarity of intent: Descriptive names and detailed documentation explain the purpose and parsing order; redundant negations such as !((!condition)) obscure straightforward checks. Code length: Generally appropriate, with some duplicated validation and verbose condition syntax. Action granularity: Most statements occupy separate lines, but the callback compresses an entire if/else and logging actions onto one line. Reading flow: Sequential parsing fallbacks and clear method boundaries support natural reading, while inconsistent indentation, tightly packed imports, empty branches, and convoluted conditions interrupt it.
Run 2
Code Structure: Methods separate CLI handling, configuration parsing, and runtime construction logically, though validation is duplicated. Nesting: Mostly shallow, but try/loop/lambda combinations and nested name checks add complexity. Clarity of intent: Descriptive names and detailed parsing documentation help, while redundant negations and empty success branches obscure straightforward conditions. Code length: Generally appropriate, with some avoidable repetition and verbose expressions. Action granularity: Most lines perform one action, but the callback compresses an entire if/else and logging operations onto one line. Reading flow: The documented JSON-to-properties fallback sequence is natural, but inconsistent formatting, long lines, and awkward conditional expressions interrupt scanning.
Run 3
Code Structure: Well-separated methods organize CLI startup, configuration parsing, and worker creation; parsing repeats name validation. Nesting: Mostly shallow, but try/loop/lambda blocks and nested name checks add complexity. Clarity of intent: Descriptive names and documentation explain the purpose, but redundant negations, excessive parentheses, and empty if branches obscure straightforward conditions. Code length: Generally proportionate to functionality, though duplicated validation and verbose conditional forms add unnecessary length. Action granularity: Most statements occupy separate lines, but the callback compresses an entire if/else and logging calls onto one line, hurting scanability. Reading flow: Startup and parsing fallback order are logical and documented; inconsistent formatting, crowded imports, and awkward conditionals interrupt an otherwise natural progression.