Sample
int-a6c0eb6b82c1-I13
Lower every eligible classic and enhanced for loop to a while loop
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.461 | 0–1; higher is more readable |
| Dorn | 0.707 | 0–1; higher is more readable |
| Mi | 0.038 | 0–1; higher is more readable |
| LLOC | 39 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.464 | 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.757 | −7.135 |
Intercept 8.87 + feature contributions = -116.099 (log-odds).
Score = sigmoid(-116.099) = 0.
| Score | 0.461 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 99 | +2.687 |
| 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 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 142.981 | +1.502 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 102.854 | +1.028 |
| 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.073 | +0.233 |
Intercept 0.07 + feature contributions = 0.881 (log-odds).
Score = sigmoid(0.881) = 0.707.
| Score | 0.038 |
|---|
| Score | 39 |
|---|
Run 1
The code is highly readable with a clear, logical structure and class-level responsibility. Methods are short, focused, and follow a consistent pattern for error handling. Nesting is minimal, with if/else branches in only two small methods. The intent is explicit, supported by descriptive method names, comments, and specific exception messages. Action granularity is mostly one action per line, though the final method chains a logger call with a throw; minor. The helper method `partition` effectively centralizes partition fetching and leader validation, reducing duplication. The lack of early returns in `endOffsetMetadata` is acceptable given its concise branching structure. Overall, the code demonstrates strong adherence to readability principles, with only minor verbosity in the repeated timestamp fetch blocks, which are still clear and understandable.
Run 2
The code is well-structured and readable. It follows the Single Responsibility Principle with clear method names and consistent patterns. The class is flat with minimal nesting, using simple conditional checks and early returns. Each method performs one logical action, and the code is concise without being overly compressed. The reading flow is natural: methods are ordered logically (offset lookups, metadata retrieval, listener management, private helper). Minor deductions include slight repetition in the offset-fetching methods (three similar blocks) which could be refactored, and the long method signature lines for fetchOffsetForTimestamp reduce scanability. The comments are helpful and placed appropriately. Overall, this is production-quality code with clear intent, good naming, and strong organization.
Run 3
The code is well-structured and readable. It uses clear method names, consistent formatting, and follows single responsibility principles. The class has a single purpose: providing partition metadata via ReplicaManager. Nesting is minimal—only simple if-statements with no deep nesting. Each method performs one logical action and reads naturally from top to bottom. The code is concise without sacrificing clarity. Helper methods like partition() consolidate validation logic, avoiding repetition. Comments are used sparingly but effectively to explain non-obvious choices like isolation level usage. Minor deductions: slightly verbose exception messages and the else-if chain in endOffsetMetadata could arguably be a switch, but neither significantly impacts readability. Overall, this is professional-quality, maintainable code.
Run 1
Code Structure: Well-organized class with focused interface methods and a shared partition-validation helper. Nesting: Minimal; simple guard clauses and a flat conditional chain keep control flow easy to follow. Clarity of intent: Descriptive method and variable names, useful isolation-level comments, and explicit exceptions make behavior clear, though positional boolean arguments are opaque. Code length: Appropriately concise overall, but the three timestamp-offset methods repeat retrieval and validation logic. Action granularity: Statements generally perform one clear action; chained calls and long argument lists slightly increase reading effort. Reading flow: Methods follow a coherent progression from offset retrieval to metadata and listener operations. Minor weaknesses include long lines, tightly packed imports, and omitted braces in the isolation conditional.
Run 2
Code Structure: Well-organized class with focused interface implementations and a shared partition-validation helper. Nesting: Minimal nesting; simple guards and straightforward conditional branches keep control flow easy to follow. Clarity of intent: Descriptive method and variable names, explicit exception messages, and useful isolation-level comments clearly communicate purpose. Boolean arguments and mixed Java/Scala optional types slightly obscure call semantics. Code length: Generally concise, although the three timestamp lookup methods repeat fetching and empty-result handling. Action granularity: Statements generally perform one action, with only modest method chaining; long argument lists require additional attention. Reading flow: Consistent formatting and predictable fetch-check-return sequences support natural reading. Long lines, tightly packed imports, and omitted braces in endOffsetMetadata slightly reduce visual consistency.
Run 3
Code Structure: Well-organized implementation with focused public methods and a shared partition-validation helper. Nesting: Shallow conditionals and straightforward returns keep complexity low. Clarity of intent: Descriptive method and variable names, explicit exceptions, and useful isolation-level comments make behavior clear; boolean arguments and mixed Java/Scala optional types require some API familiarity. Code length: Mostly concise, although the three timestamp-offset methods repeat fetching and error-handling patterns. Action granularity: Statements generally perform one action, with manageable method chaining; some argument lists and exception messages are long. Reading flow: Consistent formatting and predictable method patterns support natural reading, though unbraced conditionals in endOffsetMetadata and minimally separated imports slightly reduce consistency.