Sample
int-fce3b09bba62-I11
Split eligible integer literals into pairs of short-named intermediate variables
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 with clear separation of concerns and consistent method patterns. Each method has a single responsibility and follows a logical flow. Nesting is minimal, with only one level of conditional checks in most methods. Variable and method names are descriptive and convey intent clearly. The code is concise without being overly compressed - each method focuses on one task. Action granularity is appropriate, with one logical operation per line. Reading flow is natural - imports are organized, methods are grouped logically, and the helper method 'partition' is placed at the end. Minor deductions: the endOffsetMetadata method has multiple return statements in if-else branches which slightly impacts flow, and the long method calls could benefit from better formatting. Overall, this is highly readable production-quality code with only minor opportunities for improvement.
Run 3
The code is highly readable with a clear, logical structure. Methods are short, focused, and have descriptive names that convey intent. Nesting is minimal, with straightforward single-level conditionals. The private partition() helper centralizes common logic, reducing duplication. Each method performs one primary action, aligning with good action granularity. Reading flow is natural, from public API methods down to the private helper. Minor deductions: the timestampAndOffset extraction lines are somewhat long due to multiple chained calls, and the repeated empty-check pattern could be factored out for slightly better conciseness, but these are minor.
Run 1
Code Structure: Well-organized class with focused interface implementations and a shared partition-validation helper. Nesting: Shallow conditionals and early exceptions keep methods easy to follow. Clarity of intent: Descriptive method and variable names, useful comments, and explicit exceptions clearly communicate purpose; boolean arguments and mixed Java/Scala optional types introduce minor ambiguity. Code length: Mostly concise, although the three timestamp lookup methods repeat fetching and validation logic. Action granularity: Statements generally perform one action, with only modest chaining in fetch calls. Reading flow: Methods follow a consistent pattern and delegation is straightforward. Long argument lists and exception messages, tightly grouped imports, and the unbraced conditional chain in endOffsetMetadata slightly reduce readability.
Run 2
Code Structure: Well-organized class with focused interface methods and a shared partition-validation helper. Nesting: Shallow conditionals and straightforward returns make control flow easy to follow. Clarity of intent: Descriptive method and variable names, explanatory isolation comments, and specific exception messages communicate purpose clearly; boolean arguments and Java/Scala optional interoperability add minor ambiguity. Code length: Mostly concise, although the three timestamp lookup methods repeat fetching and missing-offset handling. Action granularity: Statements generally perform one action each; chained fetch calls remain understandable but are somewhat dense. Reading flow: Consistent formatting and predictable method patterns support natural reading. Long argument lists, unbraced conditionals in endOffsetMetadata, and minimally separated imports slightly reduce readability.
Run 3
Code Structure: Clearly organized around the provider interface, with focused methods and a shared partition-validation helper. Nesting: Very shallow; simple guards and a straightforward conditional chain keep complexity low. Clarity of intent: Descriptive method and variable names, explanatory isolation-level comments, and informative exceptions make behavior clear. Boolean arguments and Java/Scala optional-type mixing slightly obscure call semantics. Code length: Generally concise, though the three timestamp methods repeat fetching and exception-handling logic. Action granularity: Statements generally perform one action each; chained calls and long argument lists add minor reading effort. Reading flow: Consistent formatting and predictable fetch-check-return patterns support natural reading. Long lines, minimally separated imports, and omitted braces in endOffsetMetadata slightly reduce visual consistency.