Sample

int-ffea6c6df720-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines162

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8350–1; higher is more readable
Dorn0.6640–1; higher is more readable
Mi0.0840–1; higher is more readable
LLOC50Logical lines; fewer is more readable
DeepSeek V4 Pro50–20; mean of three runs
GPT-6.1 Sol13.330–20; mean of three runs
BTTF0.530–1; higher is more readable

Views

Source code

package io.netty.util.concurrent; import io.netty.util.internal.ObjectUtil; /** * <p>A promise combiner monitors the outcome of a number of discrete futures, then notifies a final, aggregate promise * when all of the combined futures are finished. The aggregate promise will succeed if and only if all of the combined * futures succeed. If any of the combined futures fail, the aggregate promise will fail. The cause failure for the * aggregate promise will be the failure for one of the failed combined futures; if more than one of the combined * futures fails, exactly which cause of failure will be assigned to the aggregate promise is undefined.</p> * * <p>Callers may populate a promise combiner with any number of futures to be combined via the * {@link PromiseCombiner#add(Future)} and {@link PromiseCombiner#addAll(Future[])} methods. When all futures to be * combined have been added, callers must provide an aggregate promise to be notified when all combined promises have * finished via the {@link PromiseCombiner#finish(Promise)} method.</p> * * <p>This implementation is <strong>NOT</strong> thread-safe and all methods must be called * from the {@link EventExecutor} thread.</p> */ public final class PromiseCombiner { private int expectedCount; private int doneCount; private Promise<Void> aggregatePromise; private Throwable cause; private final GenericFutureListener<Future<?>> listener = new GenericFutureListener<Future<?>>() { @Override public void operation(final Future<?> fut) { if (executor.inEventLoop()) { operation2(fut); } else { executor.execute(new Runnable() { @Override public void run() { operation2(fut); } }); } } private void operation2(Future<?> fut2) { assert executor.inEventLoop(); ++doneCount; if (!fut2.isSuccess() && cause == null) { cause = fut2.cause(); } if (doneCount == expectedCount && aggregatePromise != null) { try2(); } } }; private final EventExecutor executor; /** * Deprecated use {@link PromiseCombiner#PromiseCombiner(EventExecutor)}. */ @Deprecated public PromiseCombiner() { this(ImmediateEventExecutor.INSTANCE); } /** * The {@link EventExecutor} to use for notifications. You must call {@link #add(Future)}, {@link #addAll(Future[])} * and {@link #finish(Promise)} from within the {@link EventExecutor} thread. * * @param executor the {@link EventExecutor} to use for notifications. */ public PromiseCombiner(EventExecutor exe) { this.executor = ObjectUtil.checkNotNull(exe, "executor"); } /** * Adds a new promise to be combined. New promises may be added until an aggregate promise is added via the * {@link PromiseCombiner#finish(Promise)} method. * * @param promise the promise to add to this promise combiner * * @deprecated Replaced by {@link PromiseCombiner#add(Future)}. */ @Deprecated public void add(Promise pro) { add((Future) pro); } /** * Adds a new future to be combined. New futures may be added until an aggregate promise is added via the * {@link PromiseCombiner#finish(Promise)} method. * * @param future the future to add to this promise combiner */ @SuppressWarnings({ "unchecked", "rawtypes" }) public void add(Future fut3) { check2(); check(); ++expectedCount; fut3.addListener(listener); } /** * Adds new promises to be combined. New promises may be added until an aggregate promise is added via the * {@link PromiseCombiner#finish(Promise)} method. * * @param promises the promises to add to this promise combiner * * @deprecated Replaced by {@link PromiseCombiner#addAll(Future[])} */ @Deprecated public void add2(Promise... pro2) { add2((Future[]) pro2); } /** * Adds new futures to be combined. New futures may be added until an aggregate promise is added via the * {@link PromiseCombiner#finish(Promise)} method. * * @param futures the futures to add to this promise combiner */ @SuppressWarnings({ "unchecked", "rawtypes" }) public void add2(Future... fut4) { for (Future fut5 : fut4) { this.add(fut5); } } /** * <p>Sets the promise to be notified when all combined futures have finished. If all combined futures succeed, * then the aggregate promise will succeed. If one or more combined futures fails, then the aggregate promise will * fail with the cause of one of the failed futures. If more than one combined future fails, then exactly which * failure will be assigned to the aggregate promise is undefined.</p> * * <p>After this method is called, no more futures may be added via the {@link PromiseCombiner#add(Future)} or * {@link PromiseCombiner#addAll(Future[])} methods.</p> * * @param aggregatePromise the promise to notify when all combined futures have finished */ public void fin(Promise<Void> aggregate) { ObjectUtil.checkNotNull(aggregate, "aggregatePromise"); check(); if (this.aggregatePromise != null) { throw new IllegalStateException("Already finished"); } this.aggregatePromise = aggregate; if (doneCount == expectedCount) { try2(); } } private void check() { if (!executor.inEventLoop()) { throw new IllegalStateException("Must be called from EventExecutor thread"); } } private boolean try2() { return (cause == null) ? aggregatePromise.trySuccess(null) : aggregatePromise.tryFailure(cause); } private void check2() { if (aggregatePromise != null) { throw new IllegalStateException("Adding promises is not allowed after finished adding"); } } }

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.3108.102−102.567
Source linesThe number of non-empty source lines.162+64.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.574−6.862

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

Score0.835

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.163−4.735
Indentation frequencyHow rapidly indentation changes from line to line.107+2.964
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.161.893+1.853
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.119.963−1.416
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.115.656+1.062
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.047+0.487
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.683 (log-odds).
Score = sigmoid(0.683) = 0.664.

Score0.084
Score50
Run 1

The code has several readability issues. The class has a clear purpose documented in comments, but the implementation undermines this clarity. Method names are cryptic: 'add2', 'fin', 'try2', 'check', 'check2' - these do not convey intent. Variable names like 'fut', 'fut2', 'fut3', 'fut4', 'fut5' are ambiguous and progressively numbered rather than descriptively named. The listener's operation() method has an extra unnecessary nesting layer with operation2(), and action granularity is poor - multiple operations are crammed into single lines (e.g., ++doneCount; if condition; etc.). The code structure mixes concerns: field declarations are split by method definitions, and the anonymous inner class appears before the constructor. There's redundant code like the deprecated add(Promise) just casting to add(Future). The 'fin' method name is abbreviated strangely. Overall, while the documentation is thorough, the code itself requires significant effort to understand control flow and intent.

Run 2

The code is poorly readable due to confusing naming conventions (e.g., `add2`, `try2`, `fin`, `fut3`, `fut4`, `fut5`, `check`, `check2`), inconsistent method names, and unclear control flow. The listener logic is split between `operation` and `operation2`, creating unnecessary indirection. Field declarations are intermixed with methods in a non-logical order, and there is no clear separation of concerns. While the class has a useful Javadoc and the core logic is short, the naming and structure make intent hard to follow. Nesting is low, but action granularity and reading flow suffer from inconsistent naming and deprecated overloads with raw types. Overall, the code requires significant effort to understand and would benefit from clear, descriptive names and better organization.

Run 3

The code shows poor readability due to several structural and semantic problems. While the class-level Javadoc is thorough, the actual implementation is confusing: method names are misleading ('add2' should be 'addAll', 'fin' should be 'finish', 'try2' is vague, 'check'/'check2' are unclear), parameter names are meaningless ('fut3', 'fut4', 'pro2'), and the listener's logic is needlessly fragmented into 'operation' and 'operation2'. The code mixes actions per line, contains redundant event-loop checks, and has unnaturally ordered fields and methods. The deprecation annotations add noise without clarity. The nested anonymous classes increase cognitive load, and error handling is spread across multiple helper methods. Though the code is functional, its naming, structure, and flow make it hard to follow and maintain.

Run 1

Code Structure: Fields, constructors, public methods, and validation helpers are logically organized, with completion handling separated from registration. Nesting: Most methods are flat, but the listener containing an anonymous Runnable creates a moderately nested section. Clarity of intent: Descriptive state fields and extensive documentation explain the aggregation behavior, but names such as check2, try2, operation2, fin, and fut3 obscure individual responsibilities. Documentation references addAll and finish although the implemented methods are add2 and fin, making navigation confusing. Code length: Implementation methods are concise; repeated documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Registration, completion counting, and aggregate notification form a coherent lifecycle, but generic helper names and mismatched documentation force readers to jump between methods to understand details.

Run 2

Code Structure: Responsibilities are logically divided among registration, completion tracking, validation, and aggregate notification methods. Nesting: Most methods are shallow, although the anonymous listener containing an anonymous Runnable adds visual complexity. Clarity of intent: Class documentation and descriptive state fields explain the purpose, but names such as operation2, try2, check2, fin, and fut3 obscure individual responsibilities. Documentation references addAll and finish even though the actual methods are add2 and fin, further confusing readers. Code length: Methods are concise, but repetitive documentation and deprecated overloads lengthen the class. Action granularity: Statements generally perform one action per line, making updates and checks easy to follow. Reading flow: Registration and completion logic are reasonably organized, but understanding asynchronous behavior requires jumping between the listener and several vaguely named helpers.

Run 3

Code Structure: Responsibilities are reasonably separated into listener handling, adding futures, finalization, and validation helpers. Nesting: Most methods are shallow, although the anonymous listener and nested Runnable create a more deeply indented section. Clarity of intent: Class documentation and descriptive state fields explain the purpose, but names such as operation2, try2, check2, fin, and fut3 obscure individual actions. Documentation references addAll and finish, while implementations are named add2 and fin; several parameter tags also mismatch actual names. Code length: Method bodies are concise, but extensive repetitive documentation and deprecated overloads increase reading effort. Action granularity: Statements generally perform one action per line, making state changes easy to identify. Reading flow: Formatting and method grouping are consistent, but understanding lifecycle checks and completion requires jumping between ambiguously named helpers and callback code.