Sample
int-ac4c5f915cbc-I01
Remove line comments, block comments, and Javadoc
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.43 | 0–1; higher is more readable |
| Dorn | 0.208 | 0–1; higher is more readable |
| Mi | 0.025 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.454 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 4819.225 | −159.034 |
| Source linesThe number of non-empty source lines. | 103 | +41.2 |
| 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.733 | −7.099 |
Intercept 8.87 + feature contributions = -116.063 (log-odds).
Score = sigmoid(-116.063) = 0.
| Score | 0.43 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 103 | +2.826 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 104 | −2.646 |
| 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. | 142.99 | −2.391 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 102.854 | +1.028 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.078 | +0.185 |
Intercept 0.07 + feature contributions = -1.335 (log-odds).
Score = sigmoid(-1.335) = 0.208.
| Score | 0.025 |
|---|
| Score | 39 |
|---|
Run 1
The code is generally readable with clear separation of concerns and logical organization. Each method has a single responsibility, and naming is descriptive. However, several issues reduce readability: some methods repeat similar patterns (fetching timestamp offsets) creating duplication that could be extracted. The conditional logic in endOffsetMetadata uses multi-line if-else that could be more concise. Some lines exceed typical readability length, particularly method calls with multiple arguments on single lines. Action granularity is mostly good but could be improved in the timestamp-fetching methods. The code would benefit from extracting repeated null/empty checks and the timestamp-fetching logic into helper methods. Overall, the structure is sound but could be more polished with additional abstraction and formatting improvements.
Run 2
The code is well-structured and readable. It clearly implements an interface with concise methods, each performing a single logical action. The repeated pattern for fetching offsets is easy to follow, though it creates minor duplication. Nesting is minimal (one level). Intent is clear from method names and error messages. The helper method `partition()` centralizes leader checks. The main weakness is the repeated retrieval of timestamp/offset and exception logic, which could be extracted to improve conciseness. Overall flow is natural and straightforward.
Run 3
The code is generally clear and well-structured, with a straightforward class implementing an interface. Methods are concise and focused, following a consistent pattern of delegating to ReplicaManager. The private partition() helper avoids duplication and centralizes leader validation. Naming is clear, and logging is minimal but appropriate. Minor readability drawbacks include somewhat long method chains in offsetForEarliestTimestamp/offsetForLatestTimestamp/offsetForTimestamp, which reduce scanability, and the use of Scala types (Some, Option) in a Java file, which can confuse readers unfamiliar with mixed-language codebases. The endOffsetMetadata method uses sequential if/else rather than a switch, which is slightly less readable for three distinct enum cases. Overall, the code is readable but not exemplary.
Run 1
Code Structure: Well-organized provider class with focused methods and a shared partition lookup helper. Nesting: Shallow conditionals and straightforward returns keep complexity low. Clarity of intent: Descriptive method and variable names make responsibilities clear, although positional boolean arguments and mixed Java/Scala optional types require API knowledge. Code length: Mostly concise, but the three timestamp lookup methods repeat fetching and exception-handling logic. Action granularity: Generally one action per statement; chained fetch calls remain manageable despite long argument lists. Reading flow: Methods follow a natural progression from offset queries to metadata and listener operations. Extra blank lines, long exception messages, and omitted braces in the isolation conditional slightly weaken formatting consistency.
Run 2
Code Structure: Well-organized adapter class with focused public methods and a shared partition-validation helper. Nesting: Shallow conditionals and early exceptions keep control flow easy to follow. Clarity of intent: Descriptive method and variable names make responsibilities clear, though boolean arguments and mixed Java/Scala optional types require API knowledge. Code length: Generally concise, but three timestamp-offset methods repeat fetching and missing-result handling. Action granularity: Statements typically perform one action each; chained calls remain manageable. Reading flow: Methods follow a natural progression from offset queries to metadata and listener operations. Excess blank lines, long argument lists and exception messages, and omitted braces in endOffsetMetadata slightly reduce consistency and readability.
Run 3
Code Structure: Well-organized class with focused interface implementations and a shared partition helper. Nesting: Shallow conditionals and early exceptions keep control flow easy to follow. Clarity of intent: Descriptive method and variable names clearly communicate offset retrieval, leadership checks, and listener management; boolean arguments and Java/Scala interoperability slightly obscure call semantics. Code length: Methods are concise, although three timestamp lookup methods repeat similar retrieval and validation logic. Action granularity: Statements generally perform one action each, with only modest method chaining. Reading flow: Methods follow a coherent progression, but excessive blank lines, long argument lists and exception messages, and omitted braces in endOffsetMetadata slightly reduce consistency and scanability.