Sample
int-d78a831cb630-I10
Remove about 40% of line-break groups while retaining structure
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.355 | 0–1; higher is more readable |
| Dorn | 0.001 | 0–1; higher is more readable |
| Mi | 0 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 6.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.67 | 0–20; mean of three runs |
| BTTF | 0.038 | 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. | 8343.63 | −275.34 |
| Source linesThe number of non-empty source lines. | 106 | +42.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.808 | −7.212 |
Intercept 8.87 + feature contributions = -231.282 (log-odds).
Score = sigmoid(-231.282) = 0.
| Score | 0.355 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 335.981 | −10.566 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 336 | +4.617 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 107 | −2.752 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 83 | +2.134 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 83 | −1.484 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 105.92 | +1.071 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.075 | +0.216 |
Intercept 0.07 + feature contributions = -6.695 (log-odds).
Score = sigmoid(-6.695) = 0.001.
| Score | 0 |
|---|
| Score | 50 |
|---|
Run 1
The code suffers from severe readability issues. Multiple statements are crammed onto single lines (especially in the imports and method declarations), making it extremely difficult to scan. There is inconsistent indentation and brace placement throughout, which breaks visual structure. Some methods like processExtraArgs and parseConnectorConfigurationFile are long and have multiple responsibilities, reducing clarity of intent. The exceptional flow with try-catch blocks that swallow exceptions and use log.debug instead of meaningful error handling adds ambiguity. Nesting depth is moderate, but the dense formatting makes the logic feel tangled. The action granularity is poor, with multiple actions per line and inconsistent spacing. Reading flow is unnatural due to the formatting inconsistencies. The class-level Javadoc is good, but method-level documentation is sparse. Overall, the code would greatly benefit from consistent formatting, better separation of concerns, and clearer error handling. This readability metric reflects both the formatting issues and the structural problems in the implementation.
Run 2
The code suffers from poor readability due to several factors. The import section is dense with multiple imports on single lines, making it hard to scan. Methods like processExtraArgs and parseConnectorConfigurationFile are overly long and contain deeply nested try-catch blocks. The conditional logic in processExtraArgs is compressed onto single lines (if/else on one line), violating the one-action-per-line principle. Error handling obscures the main logic flow. The parseConnectorConfigurationFile method attempts three different parsing strategies with unclear separation of concerns. While the class-level Javadoc is good, method-level documentation is inconsistent. The overall structure feels tangled, with high cognitive load required to trace execution paths through exception handling and nested conditionals.
Run 3
The code suffers from severe readability issues. Multiple statements are crammed onto single lines (e.g., imports, field declarations, method signatures), which violates the 'one action per line' principle and disrupts reading flow. The class-level Javadoc is clear, but method-level formatting is poor. The parseConnectorConfigurationFile method is very long, performing multiple parsing attempts with nested try-catch blocks and tangled logic, making it difficult to follow. Error handling and control flow feel disorganized. While identifiers and basic logic are understandable, the overall structure is harmed by inconsistent formatting and excessive line compression. The code would be far more readable with standard line breaks, separated declarations, and clearer method decomposition.
Run 1
1. Code Structure: Separate methods clearly divide CLI handling, configuration parsing, and worker creation, but compressed formatting obscures these boundaries. 2. Nesting: Mostly moderate, with deeper nesting in callbacks and connector-name validation; manageable but harder to follow due to inline braces. 3. Clarity of intent: Descriptive names, detailed documentation, and meaningful log messages explain the purpose and parsing order well. 4. Code length: Reasonable for its responsibilities, although repeated name validation adds minor duplication; long physical lines reduce scanability. 5. Action granularity: Frequently combines imports, declarations, method boundaries, and multiple executable statements on one line, substantially hurting readability. 6. Reading flow: The overall execution sequence and parsing fallbacks are logical, but inconsistent indentation, crowded annotations, and inline control flow repeatedly interrupt reading.
Run 2
1. Code Structure: Responsibilities are sensibly separated into startup, configuration parsing, and component creation methods, but compressed formatting obscures their boundaries. 2. Nesting: Mostly moderate, with deeper nesting in connector creation callbacks and configuration-name validation. 3. Clarity of intent: Descriptive names, useful documentation, and informative error messages explain the purpose and parsing fallback order. 4. Code length: Reasonably concise for its responsibilities, though repeated validation and lengthy signatures add some overhead; packing statements together does not improve readability. 5. Action granularity: Frequently poor: imports, declarations, method boundaries, and multiple executable statements share lines. 6. Reading flow: The underlying execution sequence is logical, but inconsistent indentation, inline braces, crowded annotations, and abrupt transitions force readers to reconstruct the structure. Overall, understandable logic and documentation are substantially undermined by formatting.
Run 3
Code Structure: Distinct methods logically separate CLI handling, configuration parsing, and worker setup, but compressed formatting obscures these boundaries. Nesting: Mostly moderate, with a loop, callback conditional, and nested configuration validation; not excessively deep. Clarity of intent: Descriptive names and useful Javadoc clearly explain the class and parsing fallback order. Code length: Reasonable for the functionality, although repeated mandatory-name validation adds some duplication. Action granularity: Frequently poor; imports, declarations, method boundaries, and multiple executable statements share lines. Reading flow: Sequential parsing attempts are understandable, but inconsistent indentation, inline braces, and crowded exception handlers disrupt scanning. Overall, the underlying organization is sound, but presentation substantially reduces readability.