Sample

int-b27f5016bd62-SRC

Unmodified source class

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 Pro17.670–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 highly readable. It has a clear, logical structure with a single class, well-named fields, and a straightforward constructor. Nesting is minimal (only the class and methods), and there is no complex control flow. The intent is clearly documented with thorough Javadoc comments that explain the purpose of each parameter and method. The code is concise yet sufficiently detailed, avoiding unnecessary verbosity in the implementation while maintaining clarity in documentation. Each action is on its own line, and the reading flow is natural: fields, constructor, then getters. Minor deductions are for the somewhat long Javadoc comments, but these enhance understanding without harming readability.

Run 2

The code is well-structured as a simple immutable data holder with clear field grouping, constructor, and accessor methods. It has a flat structure with no nesting or control flow. Intent is clear from class and method names, and Javadoc is thorough. Code length is concise. Each statement is on its own line with good action granularity. Reading flow is natural, moving from context fields to constructor to getters. Minor deductions: Javadoc is somewhat verbose for trivial accessors, and constructor parameter order differs from field declaration order, slightly disrupting readability.

Run 3

The code is highly readable due to its logical structure, flat nesting, clear documentation, and concise implementation. It defines a simple immutable data class with three private final fields, a single constructor with validation, and straightforward getter methods. Javadoc comments provide thorough context for non-obvious parameters like networkReceive and nowNanos. Naming is descriptive and consistent. The constructor validates inputs using Objects.requireNonNull, enhancing robustness without clutter. Each getter is a single action with no complex logic. The only minor deductions are for slightly verbose Javadoc (some repetition between field and method docs) and the import placement style. Overall, it exemplifies clean, maintainable Java code with excellent reading flow.

Run 1

Code Structure: Clearly 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 explain re-authentication context, nullability, and timing semantics. Code length: Implementation is concise, but repeated Javadoc descriptions add unnecessary length. Action granularity: Each statement performs one clear action, including explicit non-null validation. Reading flow: Conventional Java organization makes the class easy to follow; minor inconsistencies between field order and constructor parameter order, along with 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 methods with no nested control flow. Clarity of intent: Descriptive names and detailed Javadoc clearly explain re-authentication state, nullability, and timing semantics. Code length: Implementation is concise, though repeated documentation about networkReceive and timing adds unnecessary length. Action granularity: Each assignment and return occupies its own line, making operations easy to scan. Reading flow: Fields, initialization, and accessors follow a natural sequence; verbose comments and the long constructor signature slightly interrupt the otherwise smooth flow.

Run 3

Code Structure: Logically organized into immutable fields, a constructor, and simple accessors. Nesting: Flat, with no nested control flow. Clarity of intent: Descriptive names and detailed documentation clearly explain the re-authentication context, nullability, and timing semantics. Code length: Implementation is concise, although repeated documentation about networkReceive and timing adds unnecessary length. Action granularity: Each statement performs one clear action. Reading flow: The fields-to-constructor-to-accessors sequence is natural and easy to follow; lengthy comments slightly interrupt scanning.