Sample

int-1d4ae2111a5f-I11

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

Matched original source

Lines114

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.9180–1; higher is more readable
Dorn0.6510–1; higher is more readable
Mi0.7260–1; higher is more readable
LLOC28Logical lines; fewer is more readable
DeepSeek V4 Pro170–20; mean of three runs
GPT-6.1 Sol180–20; mean of three runs
BTTF0.5990–1; higher is more readable

Views

Source code

package org.apache.kafka.common.utils; import java.time.Duration; import java.util.concurrent.ExecutionException; import java.util.concurrent.Future; import java.util.concurrent.TimeUnit; import java.util.concurrent.TimeoutException; import java.util.function.Supplier; /** * An interface abstracting the clock to use in unit testing classes that make use of clock time. * * Implementations of this class should be thread-safe. */ public interface Time { Time SYSTEM = SystemTime.getSystemTime(); /** * Returns the current time in milliseconds. */ long milliseconds(); /** * Returns the value returned by `nanoseconds` converted into milliseconds. */ default long hiResClockMs() { return TimeUnit.NANOSECONDS.toMillis(nanoseconds()); } /** * Returns the current value of the running JVM's high-resolution time source, in nanoseconds. * * <p>This method can only be used to measure elapsed time and is * not related to any other notion of system or wall-clock time. * The value returned represents nanoseconds since some fixed but * arbitrary <i>origin</i> time (perhaps in the future, so values * may be negative). The same origin is used by all invocations of * this method in an instance of a Java virtual machine; other * virtual machine instances are likely to use a different origin. */ long nanoseconds(); /** * Sleep for the given number of milliseconds */ void sleep(long ms); /** * Wait for a condition using the monitor of a given object. This avoids the implicit * dependence on system time when calling {@link Object#wait()}. * * @param obj The object that will be waited with {@link Object#wait()}. Note that it is the responsibility * of the caller to call notify on this object when the condition is satisfied. * @param condition The condition we are awaiting * @param deadlineMs The deadline timestamp at which to raise a timeout error * * @throws org.apache.kafka.common.errors.TimeoutException if the timeout expires before the condition is satisfied */ default void waitObject(Object obj, Supplier<Boolean> condition, long deadlineMs) throws InterruptedException { synchronized (obj) { while (true) { if (condition.get()) return; long currentTimeMs = milliseconds(); if (currentTimeMs >= deadlineMs) throw new org.apache.kafka.common.errors.TimeoutException("Condition not satisfied before deadline"); obj.wait(deadlineMs - currentTimeMs); } } } /** * Get a timer which is bound to this time instance and expires after the given timeout */ default Timer timer(long timeoutMs) { return new Timer(this, timeoutMs); } /** * Get a timer which is bound to this time instance and expires after the given timeout */ default Timer timer(Duration timeout) { return timer(timeout.toMillis()); } /** * Wait for a future to complete, or time out. * * @param future The future to wait for. * @param deadlineNs The time in the future, in monotonic nanoseconds, to time out. * @return The result of the future. * @param <T> The type of the future. */ default <T> T waitForFuture( Future<T> future, long deadlineNs ) throws TimeoutException, InterruptedException, ExecutionException { TimeoutException timeoutException = null; while (true) { long nowNs = nanoseconds(); if (deadlineNs <= nowNs) { throw (timeoutException == null) ? new TimeoutException() : timeoutException; } long deltaNs = deadlineNs - nowNs; try { return future.get(deltaNs, TimeUnit.NANOSECONDS); } catch (TimeoutException t) { timeoutException = t; } } } }

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.2107.815−69.558
Source linesThe number of non-empty source lines.114+45.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.421−6.631

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

Score0.918

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.115−3.035
Indentation frequencyHow rapidly indentation changes from line to line.73+1.788
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.120.991−1.46
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.113.861+1.182
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.120.991+1.148
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.042+0.535
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.625 (log-odds).
Score = sigmoid(0.625) = 0.651.

Score0.726
Score28
Run 1

The code is highly readable with clear structure and intent. It is a well-documented interface with logical organization of methods, flat nesting levels, and natural reading flow. Each method has a single purpose and concise implementation. The waitForFuture method demonstrates clean handling of timeout logic with minimal nesting. Documentation is thorough without being excessive, explaining both purpose and edge cases. Minor deductions for slight verbosity in some comments and the multi-line method signature in waitForFuture.

Run 2

The code is generally well-structured and readable. It has clear purpose with a cohesive interface for time abstraction, good documentation, and mostly flat nesting. The methods `waitObject` and `waitForFuture` have clear logic but introduce slightly deeper nesting with loops and conditionals. Action granularity is mostly one action per line, and reading flow is natural. The main drawbacks are the long `waitForFuture` method with a catch block that assigns to an outer variable, and the use of an infinite loop in `waitObject` which slightly reduces clarity. Overall, it is readable but could be simplified by extracting some loop logic into helpers.

Run 3

The code is highly readable. It is well-structured as a clear interface with logically grouped methods, minimal nesting, and concise Javadoc. Each method performs a single, well-defined action, and the line-level readability flows naturally. The only minor deductions are due to the `waitObject` and `waitForFuture` methods containing loops that, while necessary, are slightly more complex than the surrounding code.

Run 1

Code Structure: A cohesive clock interface groups related time, timer, and waiting operations into small methods. Nesting: Generally shallow; waitObject adds moderate nesting through synchronization, a loop, and conditionals. Clarity of intent: Descriptive method names, explicit time units, and helpful documentation make the purpose clear. The retry behavior and retained exception in waitForFuture could benefit from a brief explanation. Code length: Implementations are concise; extensive documentation is mostly justified by timing semantics. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Methods follow a logical progression from clock access to waiting utilities. Minor inconsistencies, including unbraced conditionals, split parameter formatting, and a fully qualified timeout exception, slightly interrupt otherwise clean reading.

Run 2

Code Structure: The interface logically groups clock access, waiting, and timer creation into focused methods. Nesting: Most methods are flat; waitObject has moderate synchronized/loop/conditional nesting, but early exits keep it manageable. Clarity of intent: Descriptive method names, explicit time-unit suffixes, and useful Javadocs make the purpose clear. The retry behavior and retained exception in waitForFuture could benefit from a short explanatory comment. Code length: Implementations are concise; lengthy documentation largely provides relevant timing semantics. Action granularity: Statements generally perform one action per line, with no crowded multi-statement lines. Reading flow: Method organization and consistent spacing support natural reading, though the multiline waitForFuture signature, missing braces on some conditionals, and fully qualified timeout exception slightly interrupt consistency.

Run 3

Code Structure: The interface logically groups clock access, sleeping, timers, and waiting utilities into focused methods. Nesting: Most methods are flat; waitObject has moderate synchronized/loop/conditional nesting, while waitForFuture remains manageable. Clarity of intent: Descriptive method names, explicit time-unit suffixes, and useful documentation make behavior clear. The retained timeout exception in waitForFuture could benefit from a brief explanatory comment. Code length: Implementations are concise; lengthy documentation mostly provides valuable timing semantics, though timer documentation is repeated. Action granularity: Statements generally perform one action per line, with no compressed multi-statement lines. Reading flow: Ordering and spacing are mostly natural. Minor inconsistencies, including missing braces on some conditionals, the multiline waitForFuture signature, and a fully qualified exception name, slightly interrupt an otherwise readable presentation.