Sample
int-24b26ffdade5-I05
Rewrite eligible decimal integer literals in hexadecimal notation
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.708 | 0–1; higher is more readable |
| Dorn | 0.391 | 0–1; higher is more readable |
| Mi | 0.469 | 0–1; higher is more readable |
| LLOC | 30 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.322 | 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. | 2215.003 | −73.095 |
| Source linesThe number of non-empty source lines. | 110 | +44 |
| 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.524 | −6.785 |
Intercept 8.87 + feature contributions = -27.011 (log-odds).
Score = sigmoid(-27.011) = 0.
| Score | 0.708 |
|---|
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. | 110 | −2.858 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 66 | +1.546 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 109.752 | +1.124 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 65 | −1.071 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 99.964 | +0.808 |
| 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.964 | −0.569 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.045 | +0.508 |
Intercept 0.07 + feature contributions = -0.441 (log-odds).
Score = sigmoid(-0.441) = 0.391.
| Score | 0.469 |
|---|
| Score | 30 |
|---|
Run 1
The code is well-structured and mostly readable. It has clear documentation, single-purpose methods, low nesting, and good naming. The main weakness is logical ambiguity: the findRedundantOffset method's early return on equality with lastRedundantOffset and the hidden relationship between updateState and findRedundantOffset are not obvious. Comments help but could be clearer. Overall, concise and maintainable.
Run 2
The code demonstrates strong readability with clear organization into logical sections (fields, constructor, public methods, private helper, test accessor). The class has a single, well-documented purpose. Naming is descriptive (e.g., lastRedundantOffset, findRedundantOffset). Javadoc comments explain the complex timeline semantics and the algorithm's edge cases, which is crucial here. Nesting is minimal—only one if-block inside a loop—and the flow is natural. Variables are well-placed and initialization is sensible (Long.MAX_VALUE for Math.min). The code is concise yet sufficiently explanatory. Minor deductions: the constructor's inline comment and the magic number 0x0 used for both initial capacity and invalid offset could be extracted as named constants. The isDelete block appears after offset calculation, which slightly interrupts the logical sequence. Overall, the code is highly readable and maintainable.
Run 3
The code is generally well-structured and readable. It has a clear single responsibility, good use of Javadoc explaining non-obvious logic, and a flat method structure with minimal nesting. Field and method names are descriptive. However, the updateState method performs multiple actions (updating lastRedundantOffset, putting the offset, calculating redundant offset, and conditionally removing) which slightly reduces action granularity. The findRedundantOffset method includes a lengthy inline comment example that, while helpful, could be extracted for brevity. The use of TimelineHashMap and TimelineLong is domain-specific but well-documented. Overall, the code is concise, logically organized, and easy to follow for readers familiar with Kafka internals, though a few minor readability improvements could push it higher.
Run 1
Code Structure: Fields, initialization, updates, calculation, and accessors are logically separated into focused methods. Nesting: Shallow conditionals and a single loop keep complexity low; early returns simplify traversal. Clarity of intent: Descriptive names and documentation explain offset tracking and snapshot behavior, though lastRedundantOffset versus smallest necessary offset terminology is confusing, and soFar is vague. Code length: Implementation is compact, but repetitive comments and the lengthy inline example interrupt readability. Action granularity: Statements generally perform one action per line, with conventional expression composition. Reading flow: State updates and queries follow a natural sequence, although calculating the minimum before removing a deleted key requires careful interpretation. Hexadecimal zero literals add unnecessary visual friction.
Run 2
Code Structure: Fields, initialization, updates, calculation, and accessors are logically separated into focused methods. Nesting: Shallow conditionals and a single loop make control flow easy to follow. Clarity of intent: Descriptive method names and documentation explain offset tracking and rollback behavior, although lastRedundantOffset versus smallest necessary offset is conceptually confusing, and soFar is vague. Code length: The implementation is compact, but some comments are verbose or repeat the code. Action granularity: Statements generally perform one action per line, with readable expressions and a concise method reference. Reading flow: Organization is natural, and early returns simplify scanning. Minor distractions include hexadecimal zero literals, missing spacing between package and imports, and the subtle ordering of minimum calculation before deletion, whose rationale is not fully explained.
Run 3
Code Structure: Fields, initialization, state updates, minimum calculation, and accessors are logically separated into focused methods. Nesting: Shallow conditionals and a single loop keep control flow easy to follow. Clarity of intent: Descriptive method names and comments explain snapshot behavior and offset tracking, though lastRedundantOffset versus smallest necessary offset introduces boundary ambiguity; soFar and hexadecimal zero literals are less expressive. Code length: The implementation is compact, but some comments and Javadocs are repetitive or disproportionately long. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Execution proceeds naturally, with straightforward early returns. However, calculating redundancy before removing a deleted key requires careful reading, and the lengthy inline example interrupts the loop's visual flow.