Sample
int-af38803478a0-I11
Split eligible integer literals into pairs of short-named intermediate variables
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.33 | 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
The code is highly readable. It is a well-structured interface with clear separation of concerns: lifecycle methods, configuration operations, target state, session keys, restart requests, and listener callbacks. Each method has a single, clearly defined purpose and is documented with concise Javadoc. Nesting is minimal, and action granularity is appropriate. Parameter names are descriptive. The reading flow is natural, moving from general lifecycle to specific operations. Minor deductions: some Javadoc lines are long, but overall this is exemplary for an interface definition.
Run 3
This code is a very clean, well-documented interface. The structure is highly logical, grouping related methods (start/stop, snapshots, configs, target states) together. There is no nesting as it's an interface definition. Clarity of intent is excellent due to concise Javadoc on each method explaining purpose, parameters, and default behaviors. The code is concise without being vague; each method is a single declaration. Action granularity is perfect, with one conceptual action per interface method. Reading flow is natural, moving from lifecycle to queries to mutations to listener callbacks. Minor deductions only for the long Javadoc on the class and some methods, which adds verbosity, but this is a matter of preference and arguably improves maintainability. Overall, it exemplifies highly readable interface design.
Run 1
Code Structure: A well-organized interface separates storage operations from notification callbacks through a nested listener interface. Nesting: Minimal nesting, with no complex control flow. Clarity of intent: Descriptive method names and detailed Javadocs make responsibilities and parameter semantics clear; start and stop lack documentation. Code length: Declarations are concise, although repetitive documentation and several long comment lines add visual bulk. Action granularity: Each method declaration represents a single operation, with no compressed multi-action lines. Reading flow: Consistent formatting and adjacent configuration update/removal methods support natural scanning, though lifecycle, configuration, coordination, and logging methods could be grouped more explicitly.
Run 2
Code Structure: The interface logically separates storage operations from callbacks in the nested UpdateListener interface. Nesting: Minimal, with only one nested interface and no complex control flow. Clarity of intent: Descriptive method names, explicit types, and comprehensive Javadocs clearly explain responsibilities and parameter semantics; start() and stop() lack documentation. Code length: Appropriate for the API's scope, though repetitive comments and several long documentation lines add minor verbosity. Action granularity: Each declaration represents one operation, with no combined actions. Reading flow: Consistent formatting and related connector/task methods make scanning natural, although specialized operations could be grouped more explicitly and imports lack visual separation. Overall, highly readable with minor documentation and organization improvements possible.
Run 3
1. Code Structure: Well-organized interface separating storage operations from update callbacks in a nested listener interface. 2. Nesting: Minimal nesting, with no complex control flow. 3. Clarity of intent: Descriptive method names, explicit types, and useful Javadoc make responsibilities clear; specialized concepts such as zombie fencing require domain knowledge. 4. Code length: Method declarations are concise, though repetitive documentation and some long comment lines increase scanning effort. 5. Action granularity: Each declaration represents one operation, with no multiple-action lines. 6. Reading flow: Consistent formatting and related configuration methods support natural reading, although lifecycle methods lack documentation and the later miscellaneous operations could be grouped more explicitly.