Sample
int-c7d1c0d44224-I02
Shorten method, parameter, and local names without collisions
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.553 | 0–1; higher is more readable |
| Dorn | 0.095 | 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 | 5.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 13 | 0–20; mean of three runs |
| BTTF | 0.281 | 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. | 8378.039 | −276.475 |
| Source linesThe number of non-empty source lines. | 162 | +64.8 |
| 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.728 | −7.092 |
Intercept 8.87 + feature contributions = -209.897 (log-odds).
Score = sigmoid(-209.897) = 0.
| Score | 0.553 |
|---|
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. | 163 | −4.735 |
| 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 (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 143.988 | −2.434 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.959 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 143.11 | +1.505 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.078 | +0.185 |
Intercept 0.07 + feature contributions = -2.253 (log-odds).
Score = sigmoid(-2.253) = 0.095.
| Score | 0.119 |
|---|
| Score | 50 |
|---|
Run 1
The code suffers from several readability issues. Variable names like 'connector2', 'connector3', 'connector4', 'connector5', 'connector6', 'create2', 'con', 'con2', 'wor', 'plu', 'rest2', 'rest3', 'arg2', and 'mai' are non-descriptive and confusing. The parse method is lengthy and mixes multiple parsing strategies with exception handling, making it hard to follow. The process method catches Throwable, which is overly broad. There are redundant code blocks for checking NAME_CONFIG presence. The structure and naming fail to convey intent clearly, leading to low readability despite some logical organization and flat nesting.
Run 2
The code is difficult to read due to poor naming conventions (connector2, file2, connector3, create2, etc.) that obscure intent. It contains deeply nested try-catch blocks, inconsistent method names (usa, create2, mai), and multiple actions packed into single lines. The parse method is overly long and mixes concerns: JSON parsing, validation, and fallback logic all in one place with cryptic variable names. Reading flow is disorganized—variable names like 'object' for an ObjectMapper and 'connector3' for a File are misleading. While the class-level Javadoc is decent, method-level documentation is sparse and the code structure lacks logical separation of parsing strategies. Error handling with broad Throwable catches adds to the ambiguity. Overall, the code requires significant effort to understand and maintain.
Run 3
The code has logical organization with a clear class structure and separated methods, but it suffers from poor variable naming (e.g., 'connector2', 'file2', 'con2', 'worker2', 'plu', 'rest2', 'rest3', 'connector3', 'connector4', 'connector5', 'connector6', 'arg2', 'wor', 'create2') that obscures intent. The method names are also confusing—'usa()' appears to be a typo for 'usage()' and 'mai()' for 'main()'—which severely hampers clarity. Nesting is moderate, and the parse() method is long and does multiple things across several try-catch blocks, reducing readability. Action granularity is reasonable in most places but the long method chains and multi-line throws add complexity. The reading flow is disrupted by these naming and structural issues.
Run 1
Code Structure: Responsibilities are separated into methods, and parsing follows a documented fallback sequence, though validation is duplicated. Nesting: Mostly shallow, with moderate nesting in the callback and connector-name validation. Clarity of intent: Documentation and API calls explain the overall purpose, but abbreviated and numbered identifiers such as con2, connector4, create2, usa, and mai obscure meaning. Code length: Reasonably concise, although repeated validation and exception-handling blocks add verbosity. Action granularity: Generally one action per statement; chained calls and inline object construction occasionally increase cognitive load. Reading flow: Startup, parsing, and worker creation are logically organized, but inconsistent indentation, dense imports, and weak naming interrupt otherwise natural flow.
Run 2
Code Structure: Methods separate connector processing, configuration parsing, and runtime construction logically. Nesting: Mostly shallow, though the callback and nested name-validation conditions add complexity. Clarity of intent: Documentation and API calls explain the purpose, but abbreviated or numbered identifiers such as usa, mai, con2, connector4, and create2 obscure meaning; the parse Javadoc also names a nonexistent parameter. Code length: Reasonably compact, although mandatory-name validation is duplicated and imports are visually dense. Action granularity: Generally one action per statement, with a few chained calls and inline constructions requiring extra attention. Reading flow: The documented JSON-to-properties fallback sequence is easy to follow, but exception-driven parsing, inconsistent naming, omitted conditional braces, and uneven formatting interrupt the flow.
Run 3
Code Structure: Methods separate connector processing, configuration parsing, and runtime construction logically, though parsing combines three fallback formats. Nesting: Generally moderate, with a loop containing a callback and a nested conditional in parsing; neither is excessively deep. Clarity of intent: Documentation and Kafka API calls explain the purpose, but names such as usa, mai, con2, connector4, and wor obscure roles. The parse documentation also references a parameter name absent from the signature. Code length: Reasonably concise, although repeated name validation and lengthy exception messages add bulk. Action granularity: Most statements perform one action, with a few compound expressions that require extra interpretation. Reading flow: Sequential parsing attempts and straightforward setup provide a natural progression, but inconsistent naming, tightly packed imports, uneven line wrapping, and unbraced conditionals reduce readability.