Sample

int-e56f646da357-I08

Select one of ten high-readability unrelated code templates per class

Matched original source

Lines121

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.9060–1; higher is more readable
Dorn0.2450–1; higher is more readable
Mi0.7260–1; higher is more readable
LLOC32Logical lines; fewer is more readable
DeepSeek V4 Pro13.330–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.3620–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) { { int factorial = 1; for (int currentFactor = 2; currentFactor <= 4; currentFactor++) { factorial *= currentFactor; } } 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.2332.299−76.966
Source linesThe number of non-empty source lines.121+48.4
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.44−6.659

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

Score0.906

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.122−3.283
Indentation frequencyHow rapidly indentation changes from line to line.80+2.03
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.951−1.458
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.80−1.415
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.120.852+1.279
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.120.975+1.147
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.045+0.505

Intercept 0.07 + feature contributions = -1.124 (log-odds).
Score = sigmoid(-1.124) = 0.245.

Score0.726
Score32
Run 1

The code is generally readable but has issues. The Time interface is well-documented and methods are logically organized. However, there is a significant error: a stray code block ({ int factorial = 1; ... }) has been accidentally inserted inside the timer(Duration) method, which breaks flow and introduces unrelated logic. This severely impacts clarity and professionalism. The nesting in waitObject is moderate but acceptable, and the while(true) loops in waitObject and waitForFuture are straightforward. Method names like hiResClockMs and waitForFuture are clear. Code length is reasonable, though waitForFuture has an unnecessary timeoutException variable pattern that adds slight complexity. Action granularity is mostly one action per line. The reading flow is mostly natural but disrupted by the insertion error. Without that stray block, the code would score around 16.

Run 2

The code is well-structured and mostly readable, with clear Javadoc comments and logical organization of methods. However, there are significant flaws that lower the score: an inexplicable block of dead code inside the timer(Duration) method that computes factorial and serves no purpose in this context. The waitForFuture method has moderate nesting with a while loop and try-catch block, but the logic is reasonably clear. The waitObject method has a synchronized block with nested while loop and conditionals, though it remains understandable. Most operations follow one-action-per-line, and the method signatures are clear. The main issues are the confusing dead code block and some deep nesting in the wait methods. Overall, the code is generally readable but marred by the unexpected factorial code and slightly complex control flow in places.

Run 3

The code has clear intent and good documentation, but is undermined by a critical flaw: an unrelated, broken code fragment (`{ int factorial = 1; ... }`) was accidentally inserted inside the `timer(Duration)` method. This destroys the logical structure and interrupts the reading flow. The 'waitForFuture' method's loop and exception handling create mild nesting but remains understandable. The code length is reasonable and actions are generally granular, but the insertion of foreign code is a major readability issue. The structure would be clean and readable if the extraneous fragment were removed.

Run 1

Code Structure: The interface logically groups clock, timer, and waiting operations, but an unrelated factorial block disrupts timer(Duration). Nesting: Most methods are flat; synchronized loops and exception handling introduce moderate, manageable nesting. Clarity of intent: Descriptive names and useful documentation explain time semantics and deadlines, although the unused factorial calculation is confusing. Code length: Most implementations are concise; the factorial block adds unnecessary code, while extensive documentation is generally justified. Action granularity: Statements mostly perform one action per line, making execution easy to follow. Reading flow: Method organization and early returns support natural reading, but inconsistent indentation, the stray block, omitted braces on some conditionals, and uneven signature formatting interrupt it.

Run 2

Code Structure: The interface logically groups time operations, but an unrelated factorial block disrupts timer(Duration). Nesting: Most methods are flat; waitObject has moderate synchronized/loop/conditional nesting, and the factorial block adds unnecessary nesting. Clarity of intent: Descriptive names and helpful documentation explain clock semantics and deadlines, but the unused factorial calculation is confusing. Code length: Most implementations are concise; the factorial block adds needless code. Action granularity: Statements generally perform one action per line, supporting readability. Reading flow: Method ordering and documentation are natural overall, but inconsistent indentation in the factorial block, missing braces around some conditionals, and uneven formatting interrupt the flow.

Run 3

Code Structure: The interface logically groups time access, waiting, and timer utilities, but an unrelated factorial block disrupts timer(Duration). Nesting: Generally shallow; waitObject has moderate nesting, and the factorial block adds unnecessary depth. Clarity of intent: Descriptive method names and useful documentation clarify clock semantics and deadlines, but the unused factorial calculation is confusing. Code length: Most methods are concise; the factorial block is unnecessary, while detailed time-source documentation is justified. Action granularity: Statements generally perform one action per line, making operations easy to follow. Reading flow: Method ordering and documentation support natural reading, but inconsistent indentation, the extraneous block, and minor formatting inconsistencies interrupt it.