Sample
int-da0d9b8e790e-SRC
Unmodified source class
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 interface is highly readable. It is well-structured, with imports organized separately from the class definition and logical method grouping. The code is entirely flat with no nesting. Each method has a clear purpose, reinforced by Javadoc comments explaining parameters, return values, and exceptions. Methods are concise and follow a single-action-per-line philosophy. Reading flow is natural, progressing from lifecycle methods to configuration management, refresh, and update listeners. The nested interface for update listeners is appropriately separated, and default method behavior is clearly documented. Minor deductions only for the long Javadoc on claimWritePrivileges, which slightly disrupts flow, but overall this is excellent.
Run 2
The code is a well-structured Java interface with clear intent and excellent readability. Each method has a concise Javadoc explaining its purpose and parameters, which significantly enhances clarity. The structure is logical, grouping related methods (config operations, state changes, update listener callbacks) naturally. Nesting is minimal — only the inner UpdateListener interface exists, and its methods are clearly separated. Action granularity is appropriate: one method declaration per line with descriptive names. The reading flow is natural, starting with lifecycle methods, then snapshot/config operations, followed by state updates and listener callbacks. The only minor deductions are for a few long Javadoc lines (e.g., the claimWritePrivileges description) that could be wrapped for readability, and the interface is somewhat lengthy due to comprehensive documentation. Overall, this is highly maintainable and readable code that follows Java conventions well.
Run 3
This interface is highly readable due to its clear structure, flat nesting, and comprehensive Javadoc. Each method represents a single, well-defined action with descriptive names (e.g., putConnectorConfig, removeTaskConfigs). The logical grouping of methods and the embedded UpdateListener interface are well-organized. The code is concise but not terse, with no unnecessary complexity. The extensive documentation explicitly clarifies intent, parameters, and exceptions, significantly enhancing readability. Minor improvements could include grouping related methods with section comments, but overall the code is exemplary. The interface clearly communicates the contract for configuration storage and retrieval, making it easy for implementers and users to understand.
Run 1
Code Structure: The interface cleanly separates storage operations from update callbacks through a nested listener interface, though explicit grouping of related methods could improve organization. Nesting: Minimal nesting, with no complex control flow. Clarity of intent: Descriptive method names, types, and detailed Javadocs make responsibilities and parameter semantics clear; start() and stop() lack lifecycle documentation. Code length: Method declarations are concise, while extensive documentation adds useful context but occasionally repeats obvious information or creates long lines. Action granularity: Each declaration represents one distinct operation, with no compound statements. Reading flow: Consistent spacing and documentation support natural scanning; connector and task operations are grouped sensibly, although later methods mix several concerns. Overall, highly readable with minor documentation and ordering improvements possible.
Run 2
Code Structure: The interface cleanly organizes configuration operations and groups notification callbacks in UpdateListener. Nesting: Minimal nesting, limited to the listener interface and an empty default method. Clarity of intent: Descriptive method names, parameter types, and thorough Javadocs make responsibilities and important behavior clear; start() and stop() lack documentation. Code length: Appropriate for the API's scope, though some comments are repetitive and several documentation lines are long. Action granularity: Each declaration represents a single operation, with no compressed statements. Reading flow: Consistent formatting and related-method placement support natural scanning, although explicit grouping of lifecycle, configuration, coordination, and logging methods would improve navigation. Overall, highly readable declarative code with only minor documentation and organization issues.
Run 3
Code Structure: The interface logically separates storage operations from callbacks in a nested UpdateListener interface. Nesting: Minimal nesting and no complex control flow make scanning easy. Clarity of intent: Descriptive method names, explicit types, and detailed Javadocs clearly communicate responsibilities; start() and stop() lack documentation. Code length: Appropriate for the API's scope, though repetitive documentation and some long comment lines add bulk. Action granularity: Each declaration expresses a single operation, with no packed statements. Reading flow: Consistent formatting and spacing support natural reading, although stronger grouping of lifecycle, configuration, coordination, and logging methods would improve navigation. Missing separation between the package declaration and imports is a minor formatting issue.