Sample

int-f01fe6914fb8-I10

Remove about 40% of line-break groups while retaining structure

Matched original source

Lines42

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.3840–1; higher is more readable
Dorn0.0250–1; higher is more readable
Mi00–1; higher is more readable
LLOC22Logical lines; fewer is more readable
DeepSeek V4 Pro4.330–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.3750–1; higher is more readable

Views

Source code

package org.apache.kafka.server.purgatory; import org.apache.kafka.common.errors.TimeoutException; import org.apache.kafka.common.utils.internals.LogContext; import org.slf4j.Logger; import java.util.List; import java.util.concurrent.CompletableFuture; /** * A delayed operation using CompletionFutures that can be created by KafkaApis and watched * in a DelayedFuturePurgatory purgatory. This is used for ACL updates using async Authorizers. */ public class DelayedFuture<T> extends DelayedOperation { private final Logger log = new LogContext().logger(DelayedFuture.class.getName()); private final List<CompletableFuture<T>> futures; private final Runnable responseCallback; private final long timeoutMs; public DelayedFuture(long timeoutMs, List<CompletableFuture<T>> futures, Runnable responseCallback) { super(timeoutMs); this.timeoutMs = timeoutMs; this.futures = futures; this.responseCallback = responseCallback; } /** * The operation can be completed if all the futures have completed successfully * or failed with exceptions. */ @Override public boolean tryComplete() { log.trace("Trying to complete operation for {} futures", futures.size()); long pending = futures.stream().filter(future -> !future.isDone()).count(); if (pending == 0) { log.trace("All futures have been completed or have errors, completing the delayed operation"); return forceComplete(); } else { log.trace("{} future still pending, not completing the delayed operation", pending); return false; } } /** * Timeout any pending futures and invoke responseCallback. This is invoked when all * futures have completed or the operation has timed out. */ @Override public void onComplete() { List<CompletableFuture<T>> pendingFutures = futures.stream().filter(future -> !future.isDone()).toList(); log.trace("Completing operation for {} futures, expired {}", futures.size(), pendingFutures.size()); pendingFutures.forEach(future -> future.completeExceptionally(new TimeoutException("Request has been timed out after " + timeoutMs + " ms"))); responseCallback.run(); } /** * This is invoked after onComplete(), so no actions required. */ @Override public void onExpiration() { // This is invoked after onComplete(), so no actions required. } }

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.2108.69−69.587
Source linesThe number of non-empty source lines.42+16.8
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.749−7.123

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

Score0.384

Feature contributions

FeatureValueContribution
(log-odds)
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.251−6.966
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.251+3.245
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.41−0.415
Indentation frequencyHow rapidly indentation changes from line to line.30+0.301
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.30−0.268
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.077+0.191
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.41.726+0.173

Intercept 0.07 + feature contributions = -3.669 (log-odds).
Score = sigmoid(-3.669) = 0.025.

Score0
Score22
Run 1

The code suffers from major readability issues. Multiple statements are compressed onto single lines, especially in the constructor and tryComplete() method, violating the 'one action per line' principle. Opening braces are placed at the end of lines containing multiple statements, making block structure difficult to discern. Import statements are also compressed onto one line. The nested if-else in tryComplete() adds unnecessary complexity. While the code's purpose is documented, the physical layout makes it hard to follow. The logical organization is sound, but the formatting severely impairs scanning and comprehension. Javadoc comments exist but are positioned at awkward points due to the compressed formatting. Overall, the code would benefit from proper line breaks, consistent brace placement, and separation of concerns to improve readability.

Run 2

The code has severe readability issues. The package and imports are jumbled together on single lines. Multiple statements are crammed onto single lines, violating action granularity and reading flow. Constructor parameters and method bodies are compressed, making logical organization hard to follow. While intent is somewhat clear from the JavaDoc comments, the formatting undermines clarity. Nesting is shallow, which is good, but code length is misleadingly compact rather than concise. The overall structure lacks visual separation and conventional formatting, forcing the reader to parse dense text instead of scanning naturally. Readability is significantly degraded by poor layout, even though the underlying logic is simple.

Run 3

The code suffers from severe formatting issues that drastically hurt readability. Multiple statements are crammed onto single lines (e.g., class fields, constructors, and method bodies), and imports are jumbled. This violates the 'one action per line' and 'code structure' principles. While the code is logically concise and the intent could be understood with effort, the physical layout makes it very difficult to scan. Nesting is minimal, which is a plus, but the lack of whitespace and conventional line breaks creates unnecessary cognitive load. The reading flow is completely disrupted by the compressed formatting, forcing the reader to mentally parse dense blocks. Javadoc exists but is placed awkwardly within the compressed lines. The code requires reformatting before it can be practically reviewed or understood, earning it a low score.

Run 1

Code Structure: Fields, constructor, and lifecycle methods are logically organized, but compressed formatting obscures their boundaries. Nesting: Shallow, with only a simple if/else and straightforward lambdas. Clarity of intent: Descriptive names, documentation, and logging clearly explain completion and timeout handling. Code length: Appropriately short overall, though the expiration comment is redundant. Action granularity: Several imports, assignments, logging calls, and control-flow statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent brace placement, long lines, and documentation attached to closing braces interrupt otherwise natural top-to-bottom reading. The logic is understandable, but formatting substantially reduces readability.

Run 2

Code Structure: Fields, constructor, and lifecycle methods are logically organized, but compressed formatting obscures their boundaries. Nesting: Shallow nesting and simple stream operations make the control flow easy to understand. Clarity of intent: Descriptive names, documentation, and logging clearly explain completion and timeout behavior. Code length: The implementation is concise, although the else branch and repeated expiration comment add minor redundancy. Action granularity: Multiple imports, assignments, logging calls, and control statements share lines, making individual actions harder to scan. Reading flow: Inconsistent line breaks, inline braces, and documentation attached to closing braces interrupt otherwise natural top-to-bottom reading.

Run 3

Code Structure: Fields, constructor, and lifecycle methods are logically organized, but compressed formatting obscures their boundaries. Nesting: Shallow nesting and simple stream expressions keep control flow manageable. Clarity of intent: Descriptive names, documentation, and logging clearly explain completion checks, timeout handling, and callback execution. Code length: The implementation is concise, although the redundant else branch and repeated expiration comment add minor clutter. Action granularity: Multiple imports, assignments, logging calls, and control statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent line breaks, closing braces attached to documentation comments, and inline annotations interrupt otherwise natural top-to-bottom reading. Overall, the logic is understandable, but formatting significantly reduces readability.