Sample
int-bfadb4c3952c-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.885 | 0–1; higher is more readable |
| Scalabrino | 0.825 | 0–1; higher is more readable |
| Dorn | 0.578 | 0–1; higher is more readable |
| Mi | 0.116 | 0–1; higher is more readable |
| LLOC | 5 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.726 | 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. | 60 | +24 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 724.925 | −23.923 |
| 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.604 | −6.907 |
Intercept 8.87 + feature contributions = 2.041 (log-odds).
Score = sigmoid(2.041) = 0.885.
| Score | 0.825 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 123.967 | −1.586 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.951 | +1.163 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 61 | −1.123 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.021 | +0.734 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 59.864 | +0.427 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 28 | +0.231 |
Intercept 0.07 + feature contributions = 0.315 (log-odds).
Score = sigmoid(0.315) = 0.578.
| Score | 0.116 |
|---|
| Score | 5 |
|---|
Run 1
The code is highly readable. It demonstrates clear structure with logical separation between the interface declaration, Javadoc, and methods. Nesting is non-existent, as expected for an interface. Intent is clearly communicated through comprehensive Javadoc, explaining the purpose, use cases, and lifecycle. The code is concise for its purpose—the verbose documentation is justified for a public Kafka API. Action granularity is appropriate: each method declaration is on its own line, and default implementations are minimal. The reading flow is natural, starting with the interface overview, moving to the primary 'validate' method, and ending with inherited framework methods. Minor deductions are for slightly long return type documentation in the Javadoc, which wraps awkwardly, and the interface extends four other interfaces, which slightly increases cognitive load upfront. Overall, this is exemplary of well-documented, maintainable Java interface code.
Run 2
The code is highly readable due to its clear logical structure and purpose. The interface is well-organized, with imports neatly grouped and Javadoc thoroughly explaining the contract, usage, and discovery mechanism. Nesting is non-existent since this is an interface with only two methods and two default implementations. Intent is unambiguous—every method and parameter is documented, and the naming is descriptive. Code length is appropriate for an API definition; it is concise without omitting critical documentation. Action granularity is excellent, with each method and default implementation separated naturally. Reading flow is logical, progressing from interface declaration to validation logic to configuration metadata. The only minor drawback is slightly verbose Javadoc, which could be considered excessive for simple default methods, but this does not significantly hinder readability. Overall, this is exemplary API code.
Run 3
The code is well-structured and readable. It starts with clear package and import declarations, followed by comprehensive Javadoc that explains the interface's purpose, usage, and discovery mechanism. The interface definition is straightforward, extending logical interfaces. The method validate() has a clear signature and descriptive Javadoc, though the return tag formatting is slightly misaligned. Default methods config() and version() are concise and self-documenting. Nesting is non-existent, and action granularity is appropriate. The reading flow is natural, with a logical progression from purpose to methods. Minor deductions: the long Javadoc paragraph about ServiceLoader could be broken up, and the import list is slightly long but necessary. Overall, the code demonstrates high readability with clear intent and minimal complexity.
Run 1
Code Structure: The interface is logically organized, with imports, interface documentation, validation, configuration, and version methods clearly separated. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and thorough Javadoc explain the policy's purpose, lifecycle, and method contracts; the default version value is somewhat uninformative. Code length: The implementation is concise, though documentation dominates and could be tightened slightly. Action granularity: Each method declaration or return statement occupies its own line, with no bundled actions. Reading flow: The top-to-bottom progression is natural. Minor formatting issues—extra blank lines, ungrouped imports, and inconsistent indentation in the return documentation—slightly reduce polish without obstructing understanding.
Run 2
Code Structure: The interface logically groups validation, configuration, and version methods, with clear annotations and documentation. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: Descriptive names and detailed Javadocs explain the policy's purpose, integration, and validation contract. Code length: The implementation is concise, though documentation dominates and contains some wordy phrasing. Action granularity: Each declaration and return statement occupies its own line; no actions are combined. Reading flow: The progression from interface documentation to method contracts and simple defaults is natural. Minor distractions include extra blank lines, inconsistent Javadoc indentation, and imports without visual grouping.
Run 3
Code Structure: Logically organized interface with imports, class documentation, and clearly separated methods. Nesting: Minimal nesting; default methods contain single return statements. Clarity of intent: Descriptive names and comprehensive Javadoc explain policy validation, configuration, and version behavior. Code length: Implementation is concise, though documentation is somewhat verbose relative to the small interface. Action granularity: Each statement performs one action, with no compressed or compound operations. Reading flow: Natural progression from interface purpose to validation and default metadata methods. Minor readability issues include extra blank lines, inconsistent Javadoc continuation formatting, long documentation lines, and slightly awkward wording.