Sample

int-0dfcd8bf6a57-I05

Rewrite eligible decimal integer literals in hexadecimal notation

Matched original source

Lines77

Scores

MethodScoreScale
Posnett10–1; higher is more readable
Scalabrino0.9280–1; higher is more readable
Dorn0.5810–1; higher is more readable
Mi0.2260–1; higher is more readable
LLOC13Logical lines; fewer is more readable
DeepSeek V4 Pro180–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.7170–1; higher is more readable

Views

Source code

package org.apache.kafka.common.network; import java.util.Objects; /** * Defines the context in which an {@link Authenticator} is to be created during * a re-authentication. */ public class ReauthenticationContext { private final NetworkReceive networkReceive; private final Authenticator previousAuthenticator; private final long reauthenticationBeginNanos; /** * Constructor * * @param previousAuthenticator * the mandatory {@link Authenticator} that was previously used to * authenticate the channel * @param networkReceive * the applicable {@link NetworkReceive} instance, if any. For the * client side this may be a response that has been partially read, a * non-null instance that has had no data read into it yet, or null; * if it is non-null then this is the instance that data should * initially be read into during re-authentication. For the server * side this is mandatory and it must contain the * {@code SaslHandshakeRequest} that has been received on the server * and that initiates re-authentication. * * @param nowNanos * the current time. The value is in nanoseconds as per * {@code System.nanoTime()} and is therefore only useful when * compared to such a value -- it's absolute value is meaningless. * This defines the moment when re-authentication begins. */ public ReauthenticationContext(Authenticator previousAuthenticator, NetworkReceive networkReceive, long nowNanos) { this.previousAuthenticator = Objects.requireNonNull(previousAuthenticator); this.networkReceive = networkReceive; this.reauthenticationBeginNanos = nowNanos; } /** * Return the applicable {@link NetworkReceive} instance, if any. For the client * side this may be a response that has been partially read, a non-null instance * that has had no data read into it yet, or null; if it is non-null then this * is the instance that data should initially be read into during * re-authentication. For the server side this is mandatory and it must contain * the {@code SaslHandshakeRequest} that has been received on the server and * that initiates re-authentication. * * @return the applicable {@link NetworkReceive} instance, if any */ public NetworkReceive networkReceive() { return networkReceive; } /** * Return the always non-null {@link Authenticator} that was previously used to * authenticate the channel * * @return the always non-null {@link Authenticator} that was previously used to * authenticate the channel */ public Authenticator previousAuthenticator() { return previousAuthenticator; } /** * Return the time when re-authentication began. The value is in nanoseconds as * per {@code System.nanoTime()} and is therefore only useful when compared to * such a value -- it's absolute value is meaningless. * * @return the time when re-authentication began */ public long reauthenticationBeginNanos() { return reauthenticationBeginNanos; } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.77+30.8
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.529.661−17.479
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.253−6.38

Intercept 8.87 + feature contributions = 15.811 (log-odds).
Score = sigmoid(15.811) = 1.

Score0.928

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.77−1.69
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.118.962−1.374
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.119+1.116
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.014+0.807
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.76.842+0.664
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Indentation frequencyHow rapidly indentation changes from line to line.31+0.335

Intercept 0.07 + feature contributions = 0.326 (log-odds).
Score = sigmoid(0.326) = 0.581.

Score0.226
Score13
Run 1

The code is well-structured with a clear class purpose and logical organization. It uses flat nesting, minimal lines, and one action per line. Javadoc comments thoroughly explain parameters and return values, making intent unambiguous. The constructor and getters follow natural reading flow, and the use of Objects.requireNonNull is concise and clear. Minor deductions for verbose comments slightly increasing length, but overall the code is highly readable.

Run 2

This code is highly readable. It has a clear, logical class structure with fields, constructor, and accessor methods. Nesting is minimal, with only basic class and method blocks. The intent is explicit through comprehensive Javadoc, which clearly explains parameters, edge cases, and time values. Although the Javadoc is lengthy, it documents non-obvious behavior (e.g., nullability, time semantics) appropriately. Each constructor assignment and return statement is on its own line, improving clarity. The reading flow is natural: fields, constructor, then getters. Minor deductions are for slight verbosity in repeated Javadoc and missing class-level summary, but overall the code is easy to understand and maintain.

Run 3

The code demonstrates excellent readability across all criteria. Structure is logical: fields, constructor, then accessors in a natural order. No nesting or control flow exists, keeping the code flat and easy to follow. Intent is clearly conveyed through descriptive method names and comprehensive Javadoc, especially for the context of re-authentication. Code length is appropriate — no unnecessary lines or overengineering, just a simple immutable data holder. Action granularity is ideal: each line performs one clear action, particularly in the constructor. Reading flow feels natural, mirroring how a developer would explain the class: 'what it holds,' 'how it's built,' 'how to access it.' The only minor deduction is for slightly verbose Javadoc on simple getters, but this is consistent with Apache Kafka project standards and not a flaw in the code itself.

Run 1

Code Structure: Logically organized into immutable fields, a constructor, and simple accessors. Nesting: Flat methods with no nested control flow. Clarity of intent: Descriptive names and detailed documentation clearly explain re-authentication state, nullability, and timing semantics. Code length: Implementation is concise, though repeated documentation about networkReceive and timing makes the class longer than necessary. Action granularity: Each statement performs one clear action, including explicit null validation. Reading flow: Conventional Java organization and consistent formatting make the code easy to follow; minor field/constructor ordering differences and verbose comments slightly interrupt the flow.

Run 2

Code Structure: A logically organized context class with private final fields, a constructor, and straightforward accessors. Nesting: Flat implementation with no nested control flow. Clarity of intent: Descriptive names and thorough documentation clearly explain re-authentication state, nullability, and timestamp semantics. Code length: The implementation is concise, but repeated, lengthy Javadoc adds unnecessary bulk. Action granularity: Each assignment and return occupies its own line, making individual operations easy to follow. Reading flow: The conventional fields–constructor–accessors sequence is natural and consistent; minor distractions include the long constructor signature and documentation repetition.

Run 3

Code Structure: Clearly organized into immutable fields, a constructor, and simple accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and documentation explain re-authentication context, nullability, and timing semantics. Code length: Implementation is concise, though repeated, lengthy Javadoc adds unnecessary reading overhead. Action granularity: Each statement performs one clear action, including explicit non-null validation. Reading flow: Natural progression from state definition to initialization and accessors; minor formatting issues, such as no blank line after the package declaration and a long constructor signature, slightly reduce polish.