Sample
int-cb802694728d-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.998 | 0–1; higher is more readable |
| Scalabrino | 0.931 | 0–1; higher is more readable |
| Dorn | 0.706 | 0–1; higher is more readable |
| Mi | 0.335 | 0–1; higher is more readable |
| LLOC | 3 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 18 | 0–20; mean of three runs |
| GPT-6.1 Sol | 19 | 0–20; mean of three runs |
| BTTF | 0.658 | 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. | 57 | +22.8 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 560.253 | −18.488 |
| 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.763 | −7.145 |
Intercept 8.87 + feature contributions = 6.037 (log-odds).
Score = sigmoid(6.037) = 0.998.
| Score | 0.931 |
|---|
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. | 57 | −0.982 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 96.621 | +0.754 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.029 | +0.656 |
| 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. | 99.948 | −0.568 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 56.881 | +0.385 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 26 | +0.162 |
Intercept 0.07 + feature contributions = 0.876 (log-odds).
Score = sigmoid(0.876) = 0.706.
| Score | 0.335 |
|---|
| Score | 3 |
|---|
Run 1
This code is highly readable. The structure is logical and follows standard Java interface conventions, with clear separation between imports, Javadoc, and method declarations. Nesting is minimal—there are no deeply nested blocks, only annotations and Javadoc. Intent is unambiguous: the interface clearly extends Iterator and adds a peek() method, with thorough documentation explaining behavior and edge cases. Code length is appropriate; the Javadoc is extensive but justified for a public API. Action granularity is excellent—each method is a single declaration with clear purpose. Reading flow is natural, progressing from class-level documentation to method-level details. The only minor deductions are for the verbose Javadoc with HTML tags (necessary for Guava but slightly dense) and multiple annotations that add visual noise, but these are standard practice for this codebase.
Run 2
The code is highly readable. It is a single, focused interface with a clear purpose. Structure is logical, with imports, Javadocs, and method declarations arranged conventionally. Nesting is flat and minimal. The intent is explicit through descriptive method names and thorough Javadocs. Code length is concise, avoiding unnecessary methods or complexity. Each action is self-contained per line. The reading flow is natural, moving from broader context (package, imports) to the interface declaration and then to method contracts. Minor deductions for verbose Javadocs with HTML tags, which add some visual noise. Overall, excellent clarity and maintainability.
Run 3
The code is highly readable with a clear, logical structure. It defines a well-documented interface with a single responsibility, following standard Java conventions. Nesting is minimal, limited to the interface and method declarations. Intent is explicitly conveyed through descriptive names and comprehensive Javadoc comments that explain method behavior, edge cases, and exceptions. Code length is appropriate—concise yet thorough documentation adds value without unnecessary verbosity. Each line performs a single action, maintaining clear action granularity. The reading flow is natural, progressing from imports and class-level documentation to method declarations in order of importance. Overall, this represents exemplary interface design and documentation practices.
Run 1
Code Structure: A well-organized interface with imports, interface documentation, and clearly separated method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive naming and precise documentation explain lookahead behavior, return guarantees, and removal restrictions. Code length: Concise declarations; the longer comments provide useful API-contract details rather than unnecessary verbosity. Action granularity: Each declaration and annotation occupies its own line, making individual elements easy to identify. Reading flow: Methods follow a natural peek-next-remove sequence, with documentation immediately preceding each declaration. Minor readability drawbacks include tightly packed imports and awkward wrapping in some Javadoc links.
Run 2
Code Structure: The interface is logically organized, with imports, type documentation, and three clearly separated method declarations. Nesting: The structure is flat, with no nested control flow. Clarity of intent: Descriptive naming and precise Javadoc explain lookahead behavior, method guarantees, and removal constraints. Code length: The declarations are concise; documentation is longer but justified by subtle contract details. Action granularity: Each method declaration and annotation occupies its own line, with no combined actions. Reading flow: The progression from peek() to next() to remove() is natural. Minor distractions include annotation density, wrapped Javadoc links, and the lack of a blank line after the package declaration.
Run 3
Code Structure: A small, logically organized interface with imports, class documentation, and clearly separated method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive naming and precise Javadoc explain lookahead behavior, method relationships, and removal constraints. Code length: Concise declarations; documentation is proportionate to the subtle API contract, though annotations add some visual overhead. Action granularity: Each declaration and annotation occupies its own line; there are no combined actions. Reading flow: Methods follow a natural peek-next-remove sequence, with consistent formatting. Minor distractions include the wrapped Javadoc link and lack of blank lines separating the package declaration and import groups.