Sample

int-b548e2baa90b-I09

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

Matched original source

Lines116

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8970–1; higher is more readable
Dorn0.2550–1; higher is more readable
Mi0.310–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro11.670–20; mean of three runs
GPT-6.1 Sol15.330–20; mean of three runs
BTTF0.3110–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() { {int lI0O_297f8eb1=0x7EB5;boolean lI0O_e174305d=true;do{lI0O_297f8eb1^=0x7EB5;lI0O_e174305d=false;}while(lI0O_e174305d);} 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.2370.587−78.229
Source linesThe number of non-empty source lines.116+46.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.527−6.79

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

Score0.897

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.117−3.106
Indentation frequencyHow rapidly indentation changes from line to line.75+1.857
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.974−1.459
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.75−1.3
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.115.836+1.209
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.120.957+1.147
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.044+0.511

Intercept 0.07 + feature contributions = -1.07 (log-odds).
Score = sigmoid(-1.07) = 0.255.

Score0.31
Score33
Run 1

The code is generally well-structured with clear method separation and good Javadoc documentation, which improves readability. However, there is a glaring issue: an obfuscated line of dead code inside the `hiResClockMs()` method that serves no purpose and significantly harms clarity. The `waitObject` method uses an infinite `while(true)` loop with multiple exit points, making the control flow harder to follow than a more direct condition-based loop. The `waitForFuture` method also uses an infinite loop and a somewhat convoluted approach to rethrowing a timeout exception, which reduces clarity. Nesting is moderate, with one synchronized block and one try-catch inside loops. Overall, the code is maintainable but could be improved by removing the obfuscated code, simplifying loop conditions, and streamlining the timeout handling logic.

Run 2

The code is generally well-structured and documented, but readability is severely damaged by a confusing, obfuscated unreachable loop in the `hiResClockMs()` method. This block significantly obscures intent and breaks the reading flow. The `waitObject` and `waitForFuture` methods use infinite loops with multiple exit conditions, adding moderate nesting and making the logic harder to follow at a glance. While the code is concise overall and each line performs a single action, the presence of the misleading loop and the tight looping constructs reduce clarity. The Javadocs are helpful, but they cannot compensate for the unnecessary complexity in a few key methods.

Run 3

The code is generally well-structured, with clear method names and Javadoc explaining intent. However, readability is significantly hurt by an obfuscated block of dead code in `hiResClockMs()`, which serves no purpose and disrupts the reading flow. The `waitObject` method is somewhat deeply nested (synchronized block containing a while loop and multiple conditionals), though each action is on its own line and the logic is understandable. The `waitForFuture` method has a loop with a somewhat complex timeout handling pattern, but it remains reasonably clear. Overall, the code is functional and mostly readable but the unnecessary obfuscated block and occasional nesting reduce the score.

Run 1

Code Structure: Methods are logically organized within a focused time abstraction, although an unrelated block disrupts hiResClockMs. Nesting: Generally shallow; waitObject has moderate, understandable nesting, while the injected do-while block adds unnecessary complexity. Clarity of intent: Descriptive method names and helpful documentation make most behavior clear, but cryptic variable names and meaningless operations obscure the injected block's purpose. Code length: Mostly concise, with appropriate documentation; the extraneous block adds avoidable code. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and control flow onto one line. Reading flow: Consistent formatting and straightforward methods support natural reading, except for the abrupt, unindented obfuscation in hiResClockMs.

Run 2

Code Structure: The interface logically groups clock access, waiting, and timer creation, but hiResClockMs contains an unrelated obfuscated block. Nesting: Most methods are flat; synchronized waiting and retry loops have moderate, manageable nesting. Clarity of intent: Descriptive method names and documentation make the API clear, while meaningless variable names and redundant operations obscure the injected block's purpose. Code length: Most implementations are concise, but the no-op block adds unnecessary code. Action granularity: Normal code generally uses one action per line; the injected block compresses declarations, assignments, and a loop onto one line. Reading flow: Methods and comments follow a natural sequence, but the unindented obfuscated block sharply interrupts otherwise consistent formatting.

Run 3

Code Structure: The interface logically groups clock access, waiting, and timer creation into focused methods. Nesting: Mostly shallow; synchronized and loop blocks in waitObject introduce manageable nesting. Clarity of intent: Descriptive method names and useful documentation explain the API, but the meaningless variables and do-while block in hiResClockMs obscure an otherwise simple conversion. Code length: Most methods are concise, though the injected block adds unnecessary code. Action granularity: Most statements occupy separate lines; the injected block compresses several declarations and operations into one line, substantially reducing readability locally. Reading flow: Method organization and consistent formatting generally support natural reading, but the unindented, obfuscated block interrupts that flow. Overall, the code is readable apart from a conspicuous and distracting fragment.