Sample
int-62cfa49a02a2-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.523 | 0–1; higher is more readable |
| Dorn | 0.011 | 0–1; higher is more readable |
| Mi | 0.358 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 14 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15.67 | 0–20; mean of three runs |
| BTTF | 0.266 | 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. | 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.715 | −7.073 |
Intercept 8.87 + feature contributions = -208.743 (log-odds).
Score = sigmoid(-208.743) = 0.
| Score | 0.523 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 162 | +4.866 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 163 | −4.735 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 162 | −3.297 |
| 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. | 146.988 | −2.561 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.98 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.086 | +0.102 |
Intercept 0.07 + feature contributions = -4.504 (log-odds).
Score = sigmoid(-4.504) = 0.011.
| Score | 0.358 |
|---|
| Score | 50 |
|---|
Run 1
The code is moderately readable but has several issues. The structure is logical with clear method separation, but the 'parseConnectorConfigurationFile' method is overly long and tries three different parsing approaches in sequence, making it harder to follow. Nesting is reasonable, though error handling adds some depth. Intent is mostly clear but the fallback parsing logic could be better documented. The code is unnecessarily verbose in places, particularly the multiple try-catch blocks. Action granularity is good in most methods, but 'processExtraArgs' has multiple actions per line in callbacks. Reading flow is disrupted by the long parsing method and the inconsistent formatting with random blank lines. The imports are extensive but properly organized. Overall, the code would benefit from refactoring the parsing logic into smaller, more focused methods and improving error message consistency.
Run 2
The code has a clear overall structure with logical method separation, but readability is hampered by several issues. The parseConnectorConfigurationFile method is too long and contains multiple parsing attempts with repetitive catch blocks, creating unnecessary nesting. The method tries to parse JSON in three different ways with fallback logic, which obscures intent. Import statements are numerous but organized. The processExtraArgs method has reasonable readability with good use of lambda expressions, though the callback handling adds complexity. Action granularity is mostly good with one operation per line. The reading flow is interrupted by multiple blank lines between methods. Field and method naming is clear, but the multi-attempt parsing strategy could be refactored into smaller methods or a chain of responsibility pattern. The error handling in the catch block is concise but loses some debugging information. Overall, the code is workable but would benefit from decomposition of the parsing logic.
Run 3
The code has a clear class structure with well-named methods and follows common patterns. Imports are organized, and the main method is concise. However, the parseConnectorConfigurationFile method has multiple nested try-catch blocks and repeated parsing logic, making the intent less clear. The method is long and handles three different parsing strategies (map, CreateConnectorRequest, properties), increasing cognitive load. Logging of caught exceptions uses debug level even when those exceptions may indicate real problems, adding ambiguity. The processExtraArgs method has a lambda with conditionally indented statements that reduces readability. Some lines are long and wrap, but overall action granularity is acceptable. Reading flow is mostly natural, but the parsing method’s control flow disrupts it.
Run 1
Code Structure: Methods logically separate CLI handling, configuration parsing, and runtime construction, though parsing combines three formats in one method. Nesting: Mostly shallow, with moderate nesting in the connector loop, callback, and name validation. Clarity of intent: Descriptive method and variable names make the purpose clear; the exception-driven parsing fallback requires closer reading. Code length: Generally concise, but excessive blank lines and duplicated mandatory-name validation add unnecessary bulk. Action granularity: Most statements perform one action per line; chained calls and multiline constructor arguments remain understandable. Reading flow: Execution proceeds naturally from configuration loading to connector creation, with clear returns between parsing attempts. Inconsistent spacing, long expressions, and unbraced callback conditionals slightly disrupt readability.
Run 2
Code Structure: Responsibilities are separated into methods for argument processing, configuration parsing, and runtime construction; parsing repeats validation logic. Nesting: Mostly shallow, although the callback inside a loop and nested name checks add complexity. Clarity of intent: Descriptive method and variable names communicate purpose, but the exception-driven fallback across three configuration formats lacks explanatory comments, and 'cb' is less descriptive. Code length: Generally proportionate to functionality, but excessive blank lines, repeated checks, and verbose exception messages reduce concision. Action granularity: Most statements perform one action per line; chained calls and multi-argument construction remain manageable. Reading flow: Startup and parsing proceed logically, but inconsistent indentation, large whitespace gaps, and long wrapped expressions interrupt scanning.
Run 3
Code Structure: Methods logically separate CLI processing, configuration parsing, and runtime construction, though parsing combines three formats and repeats validation. Nesting: Generally moderate, with deeper nesting in the callback and connector-name checks. Clarity of intent: Descriptive method and variable names, explicit exceptions, and logging make the purpose clear; exception-driven format detection requires closer reading. Code length: Mostly concise, but excessive blank lines and duplicated missing-name checks add unnecessary bulk. Action granularity: Most statements perform one action, although chained calls and nested constructor expressions occasionally combine several operations. Reading flow: Startup and parsing proceed in a logical sequence, but inconsistent indentation, long lines, missing braces around callback branches, and large whitespace gaps interrupt the flow.