Sample

int-24b26ffdade5-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines110

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7080–1; higher is more readable
Dorn0.3910–1; higher is more readable
Mi0.4690–1; higher is more readable
LLOC30Logical lines; fewer is more readable
DeepSeek V4 Pro170–20; mean of three runs
GPT-6.1 Sol170–20; mean of three runs
BTTF0.3220–1; higher is more readable

Views

Source code

package org.apache.kafka.coordinator.share; import org.apache.kafka.server.share.SharePartitionKey; import org.apache.kafka.timeline.SnapshotRegistry; import org.apache.kafka.timeline.TimelineHashMap; import org.apache.kafka.timeline.TimelineLong; import java.util.Objects; import java.util.Optional; /** * Util class to track the offsets written into the internal topic * per share partition key. * It calculates the minimum offset globally up to which the records * in the internal partition are redundant i.e. they have been overridden * by newer records. */ public class ShareCoordinatorOffsetsManager { // Map to store share partition key => current partition offset // being written. private final TimelineHashMap<SharePartitionKey, Long> offsets; // Minimum offset representing the smallest necessary offset // across the internal partition (offsets below this are redundant). // We are using timeline object here because the offsets which are passed into // updateState might not be committed yet. In case of retry, these offsets would // be invalidated via the snapshot registry. Hence, using timeline object // the values would automatically revert in accordance with the last committed offset. private final TimelineLong lastRedundantOffset; public ShareCoordinatorOffsetsManager(SnapshotRegistry snapshotRegistry) { Objects.requireNonNull(snapshotRegistry); offsets = new TimelineHashMap<>(snapshotRegistry, 0x0); lastRedundantOffset = new TimelineLong(snapshotRegistry); lastRedundantOffset.set(Long.MAX_VALUE); // For easy application of Math.min. } /** * Method updates internal state with the supplied offset for the provided * share partition key. It then calculates the minimum offset, if possible, * below which all offsets are redundant. * * @param key - represents {@link SharePartitionKey} whose offset needs updating * @param offset - represents the latest partition offset for provided key * @param isDelete - true if the offset is for a tombstone record */ public void updateState(SharePartitionKey key, long offset, boolean isDelete) { lastRedundantOffset.set(Math.min(lastRedundantOffset.get(), offset)); offsets.put(key, offset); Optional<Long> redundantOffset = findRedundantOffset(); redundantOffset.ifPresent(lastRedundantOffset::set); // If the share partition is deleted, we should not hold onto its offset in our calculations // as there is nothing beyond deletion which is going to update its state. if (isDelete) { offsets.remove(key); } } private Optional<Long> findRedundantOffset() { if (offsets.isEmpty()) { return Optional.empty(); } long soFar = Long.MAX_VALUE; for (long offset : offsets.values()) { // Get min offset among latest offsets // for all share keys in the internal partition. soFar = Math.min(soFar, offset); // lastRedundantOffset represents the smallest necessary offset // and if soFar equals it, we cannot proceed. This can happen // if a share partition key hasn't had records written for a while. // For example, // <p> // key1:1 // key2:2 4 6 // key3:3 5 7 // <p> // We can see in above that offsets 2, 4, 3, 5 are redundant, // but we do not have a contiguous prefix starting at lastRedundantOffset // and we cannot proceed. if (soFar == lastRedundantOffset.get()) { return Optional.of(soFar); } } return Optional.of(soFar); } /** * Most recent last redundant offset. This method is to be used * when the caller wants to query the value of such offset. * @return Optional of type Long representing the offset or empty for invalid offset values */ public Optional<Long> lastRedundantOffset() { long value = lastRedundantOffset.get(); if (value <= 0x0 || value == Long.MAX_VALUE) { return Optional.empty(); } return Optional.of(value); } // visible for testing TimelineHashMap<SharePartitionKey, Long> curState() { return offsets; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.

Score0.708

Feature contributions

FeatureValueContribution
(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.

Score0.469
Score30
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.