Sample
int-6e083a0cd8a7-I06
Invert eligible conditions and exchange their branches
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.996 | 0–1; higher is more readable |
| Scalabrino | 0.879 | 0–1; higher is more readable |
| Dorn | 0.343 | 0–1; higher is more readable |
| Mi | 0.039 | 0–1; higher is more readable |
| LLOC | 23 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.63 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Source linesThe number of non-empty source lines. | 168 | +67.2 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 1935.261 | −63.864 |
| 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.399 | −6.598 |
Intercept 8.87 + feature contributions = 5.608 (log-odds).
Score = sigmoid(5.608) = 0.996.
| Score | 0.879 |
|---|
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. | 169 | −4.947 |
| 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. | 148.994 | −2.646 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 85 | +2.203 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 167.953 | +1.938 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 148.982 | +1.599 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.021 | +0.735 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = -0.65 (log-odds).
Score = sigmoid(-0.65) = 0.343.
| Score | 0.039 |
|---|
| Score | 23 |
|---|
Run 1
This is an excellent example of readable code. The interface is well-structured with clear separation of concerns, grouping related methods logically. The Javadoc comments are thorough and provide clear intent for each method and parameter. Nesting is minimal (only one inner interface), and the code maintains a flat, easily scannable structure. Action granularity is perfect - each method signature occupies a single line. The reading flow is natural, with related operations (config, restart, logging) organized coherently. The code is concise without being overly terse. Minor deductions: the long method signature for putConnectorConfig could be formatted more cleanly, and the claimWritePrivileges default method interrupts the method flow slightly. Overall, this represents near-ideal interface design for maintainability and clarity.
Run 2
This interface is highly readable. The code structure is logical, grouping related methods and providing a clear overview of the backing store's responsibilities. Nesting is minimal, limited to the inner UpdateListener interface. Clarity of intent is excellent due to comprehensive Javadoc comments explaining each method's purpose, parameters, and side effects. The code length is appropriate for an interface defining numerous operations; verbosity in documentation is justified. Action granularity is inherently one method per line. Reading flow is natural: core lifecycle methods first, then configuration operations, followed by other updates, and finally the listener interface. Minor deductions for slightly long Javadoc lines and a few verbose parameter descriptions, but overall it is exceptionally clear and maintainable.
Run 3
The code is highly readable due to its clear structure as a well-documented interface. Each method is logically organized and accompanied by concise Javadoc comments that explain purpose, parameters, and behavior. Nesting is minimal, limited to the inner UpdateListener interface, which is appropriately encapsulated. Intent is unambiguous—method names like putConnectorConfig, removeTaskConfigs, and claimWritePrivileges clearly describe actions. The code is concise yet descriptive, avoiding unnecessary verbosity while maintaining completeness. Action granularity is well-defined, with each method representing a single responsibility. Reading flow is natural, progressing from lifecycle methods to configuration operations, then to listener callbacks. Minor deductions: some Javadoc lines are long, slightly reducing scannability, and the default method claimWritePrivileges could benefit from a more explicit empty implementation comment. Overall, the interface exemplifies clean, maintainable code.
Run 1
Code Structure: A well-organized interface separates storage operations from notifications through a nested UpdateListener interface. Nesting: Minimal, with only one nested interface and no complex control flow. Clarity of intent: Descriptive method names and thorough Javadocs explain responsibilities, parameters, and important behavioral constraints; start() and stop() lack documentation. Code length: Method declarations are concise, although repetitive documentation and several long comment lines increase visual length. Action granularity: Each declaration represents a single operation, with no compound statements. Reading flow: Consistent spacing and documentation make scanning easy, and related configuration operations are generally grouped together. Minor weaknesses include imports immediately following the package declaration, inconsistent comment punctuation, and specialized operations that could be grouped more explicitly.
Run 2
Code Structure: Clearly organized interface with related configuration operations and a separate nested listener contract. Nesting: Minimal, limited to the listener interface and an empty default method. Clarity of intent: Descriptive method names, explicit types, and useful Javadoc make responsibilities clear; start and stop lack documentation, and some domain terminology assumes Kafka knowledge. Code length: Method declarations are concise, though repetitive documentation and several long comment lines add visual bulk. Action granularity: Each declaration represents a single operation, with no compressed statements. Reading flow: Consistent spacing and documentation support natural scanning, although explicit method groupings and clearer separation of imports would improve navigation.
Run 3
Code Structure: A well-organized interface separates storage operations from callbacks in a dedicated UpdateListener interface. Nesting: Minimal nesting, limited to the listener interface and an empty default method. Clarity of intent: Descriptive method names, typed parameters, and thorough Javadoc clearly explain responsibilities and important behavioral constraints; start and stop lack documentation. Code length: Declarations are concise, though repetitive documentation and a few long comment lines increase scanning effort. Action granularity: Each declaration represents a single operation, with no compound statements. Reading flow: Consistent formatting and related connector/task operations support natural reading, although lifecycle, write-privilege, and listener methods could be grouped more deliberately. Minor import-spacing and documentation inconsistencies prevent a perfect score.