Sample

int-218a3b6a2773-I11

Split eligible integer literals into pairs of short-named intermediate variables

Matched original source

Lines49

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.610–1; higher is more readable
Dorn0.7290–1; higher is more readable
Mi0.5490–1; higher is more readable
LLOC14Logical lines; fewer is more readable
DeepSeek V4 Pro17.670–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.6130–1; higher is more readable

Views

Source code

package org.apache.kafka.streams.state.internals; import org.apache.kafka.common.utils.Bytes; import org.apache.kafka.streams.KeyValue; import org.apache.kafka.streams.kstream.Windowed; import org.apache.kafka.streams.state.KeyValueIterator; import static org.apache.kafka.streams.state.HeadersBytesStore.convertToHeaderFormat; /** * This class is used to ensure backward compatibility at DSL level between * {@link org.apache.kafka.streams.state.SessionStoreWithHeaders} and * {@link org.apache.kafka.streams.state.SessionStore}. * <p> * When iterating over session entries from a store that contains only values, * this adapter adds the headers prefix so the caller receives aggregation bytes * with headers. * * @see SessionToHeadersStoreAdapter */ class SessionToHeadersIteratorAdapter implements KeyValueIterator<Windowed<Bytes>, byte[]> { private final KeyValueIterator<Windowed<Bytes>, byte[]> innerIterator; SessionToHeadersIteratorAdapter(final KeyValueIterator<Windowed<Bytes>, byte[]> innerIterator) { this.innerIterator = innerIterator; } @Override public void close() { innerIterator.close(); } @Override public Windowed<Bytes> peekNextKey() { return innerIterator.peekNextKey(); } @Override public boolean hasNext() { return innerIterator.hasNext(); } @Override public KeyValue<Windowed<Bytes>, byte[]> next() { final KeyValue<Windowed<Bytes>, byte[]> keyValue = innerIterator.next(); if (keyValue == null) { return null; } return KeyValue.pair(keyValue.key, convertToHeaderFormat(keyValue.value)); } }

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.1421.457−46.908
Source linesThe number of non-empty source lines.49+19.6
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.754−7.131

Intercept 8.87 + feature contributions = -25.57 (log-odds).
Score = sigmoid(-25.57) = 0.

Score0.61

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.99.92+0.808
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.50−0.734
Indentation frequencyHow rapidly indentation changes from line to line.39+0.612
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.9−0.566
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.48.822+0.273
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.083+0.131

Intercept 0.07 + feature contributions = 0.991 (log-odds).
Score = sigmoid(0.991) = 0.729.

Score0.549
Score14
Run 1

The code is highly readable with clear structure and intent. The class serves a single purpose as a backward-compatibility adapter, and the Javadoc explains its role well. Nesting is minimal, code length is appropriate, and each method performs one action. The only minor issue is the null check in next(), which could be considered a slight defensive redundancy depending on the iterator contract, but it doesn't significantly impact readability.

Run 2

The code is well-structured as a simple adapter class with clear separation of concerns. It follows the adapter pattern cleanly, wrapping an inner iterator and delegating most methods directly. Nesting is minimal - the only conditional is a single-level null check. The method names and class-level Javadoc clearly communicate intent, explaining the backward compatibility purpose and header prefix addition. Code length is appropriate for the functionality, with no unnecessary boilerplate beyond what the interface requires. Action granularity is excellent, with one meaningful operation per line (delegation, null check, transformation). Reading flow is natural, progressing from constructor to simple delegating methods to the core transformation logic. Minor deductions for the slight ambiguity around why null is returned rather than throwing an exception, and the lack of null-input validation in the constructor.

Run 3

The code is highly readable with a clear, single-purpose adapter class. Structure is logical: fields, constructor, and simple delegate methods. Nesting is minimal (one if statement), and intent is well-documented with Javadoc. Each method performs one action, keeping line-level readability high. The `next()` method is concise—fetching, null-checking, and converting in three lines—with clear handling of a null edge case. Naming is explicit and meaningful. Overall, the class is short, flat, and easy to follow.

Run 1

Code Structure: A well-organized adapter with a single responsibility and clearly separated methods. Nesting: Minimal; the only conditional is a simple null guard. Clarity of intent: Descriptive class and method names, a final delegate field, and useful Javadoc make the compatibility purpose explicit. Code length: Concise, with only necessary delegation and conversion logic. Action granularity: Each statement performs one clear action; the final return naturally combines conversion and pair construction. Reading flow: Documentation, field, constructor, and iterator methods follow a logical order. Minor formatting improvements, such as separating the package declaration and grouping static imports, would make the presentation slightly cleaner.

Run 2

Code Structure: A well-organized iterator adapter with a single responsibility and clearly separated methods. Nesting: Minimal; the only conditional is a straightforward null guard. Clarity of intent: Descriptive class and method names, plus useful Javadoc, clearly explain delegation and header-format conversion. Code length: Concise, with no unnecessary logic; delegation methods are appropriate for the interface. Action granularity: Each statement performs one clear action, and fetching the next entry is separated from conversion. Reading flow: Natural progression from field and constructor to delegated operations and the transforming next() method. Minor formatting improvements, such as blank lines separating the package declaration and import groups, would improve scanning.

Run 3

Code Structure: A well-organized iterator adapter with a single field and clearly separated interface methods. Nesting: Minimal; the only conditional is a straightforward null guard. Clarity of intent: Descriptive class and method names, supported by useful documentation, clearly explain delegation and header-format conversion. Code length: Concise, with only necessary adapter boilerplate. Action granularity: Each statement performs one clear action; the final return naturally combines conversion with result construction. Reading flow: The constructor, simple delegation methods, and transformation method follow a logical progression. Minor formatting improvements, such as separating the package declaration and import groups with blank lines, would improve visual readability.