Sample

int-3ca58e177f20-I04

Replace method, parameter, and local names with deterministic ProGuard-style short identifiers

Matched original source

Lines162

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8690–1; higher is more readable
Dorn0.6610–1; higher is more readable
Mi0.1020–1; higher is more readable
LLOC50Logical lines; fewer is more readable
DeepSeek V4 Pro3.670–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.4030–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 a(final Future<?> a) { if (executor.inEventLoop()) { c(a); } else { executor.execute(new Runnable() { @Override public void b() { c(a); } }); } } private void c(Future<?> b) { assert executor.inEventLoop(); ++doneCount; if (!b.isSuccess() && cause == null) { cause = b.cause(); } if (doneCount == expectedCount && aggregatePromise != null) { h(); } } }; 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 c) { this.executor = ObjectUtil.checkNotNull(c, "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 d(Promise d) { d((Future) d); } /** * 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 d(Future e) { i(); g(); ++expectedCount; e.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 e(Promise... f) { e((Future[]) f); } /** * 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 e(Future... g) { for (Future h : g) { this.d(h); } } /** * <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 f(Promise<Void> i) { ObjectUtil.checkNotNull(i, "aggregatePromise"); g(); if (this.aggregatePromise != null) { throw new IllegalStateException("Already finished"); } this.aggregatePromise = i; if (doneCount == expectedCount) { h(); } } private void g() { if (!executor.inEventLoop()) { throw new IllegalStateException("Must be called from EventExecutor thread"); } } private boolean h() { return (cause == null) ? aggregatePromise.trySuccess(null) : aggregatePromise.tryFailure(cause); } private void i() { 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.3041.069−100.355
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.542−6.813

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

Score0.869

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.744+1.851
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.982−1.417
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.048+0.475
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.668 (log-odds).
Score = sigmoid(0.668) = 0.661.

Score0.102
Score50
Run 1

The code is highly unreadable due to obfuscated method and parameter names (a, b, c, d, e, f, g, h, i), which make the code's intent unclear despite helpful Javadoc comments. The nesting is moderately deep within the listener, but the real problem is the poor naming: method 'c' handles future completion, 'd' adds futures, etc. This violates clarity of intent and reading flow. The structure is otherwise logical, with private helper methods to reduce duplication and keep actions granular. However, the class-level listener references executor before its declaration, and the deprecated methods add noise. There are also inconsistent naming conventions and overly terse parameter names throughout. The code is concise but at the cost of understandability, making it difficult to follow without closely reading the comments or original source.

Run 2

This code is severely unreadable due to obfuscated naming (methods a, b, c, d, e, f, g, h, i and parameters a, b, c, d, e, f, g, h, i), which obscures intent entirely. The listener logic is nested two levels deep with an anonymous inner class and a Runnable. While the class-level structure is logical (fields, constructors, public API, private helpers), the actual method names provide no semantic meaning. Reading flow is disrupted because readers must constantly map meaningless identifiers to their purpose. Action granularity is mostly acceptable, but the one-letter names force mental backtracking. The documentation is clear, but it cannot compensate for the cryptic code. The logic itself is straightforward, but the naming violates core readability principles, making the code much harder to understand than necessary. This appears to be deliberately obfuscated or minified source, not production-quality readable code.

Run 3

The code is severely obfuscated due to minified method and parameter names (a, b, c, d, e, f, g, h, i). While the Javadoc provides some clarity, the actual implementation is nearly impossible to read without reverse-engineering the single-letter identifiers. Code structure is disjointed: the listener is declared before the executor field it depends on, and methods are scattered (d/f public methods, private helpers g/h/i interleaved). Nesting is moderate but the anonymous inner class with three one-letter methods obscures intent. Action granularity is mostly one operation per line, but meaningless names destroy comprehension. Reading flow is unnatural—readers must constantly map letters to concepts. The deprecated overloads and type casts add noise. Although the class is logically small, the naming makes it effectively unreadable for maintenance or review.

Run 1

Code Structure: Fields, listener logic, constructors, public operations, and private checks are logically organized into small methods. Nesting: Most methods are shallow, although the listener's anonymous Runnable adds visual nesting. Clarity of intent: Descriptive state fields and extensive documentation explain aggregation, but single-letter method and parameter names obscure operations. Documentation references add, addAll, and finish rather than the actual names, further confusing navigation. Code length: Implementation methods are concise; lengthy, repetitive documentation and deprecated overloads increase reading overhead. Action granularity: Statements generally perform one action per line, making state updates and validation easy to follow. Reading flow: Consistent formatting and straightforward conditionals help, but calls such as i(), g(), and h() require repeated lookups to understand the lifecycle.

Run 2

Code Structure: Fields, listener logic, public operations, and validation helpers are logically organized into focused methods. Nesting: Most methods are flat, although the listener's anonymous Runnable introduces moderate nesting. Clarity of intent: Descriptive state fields and extensive documentation explain the overall purpose, but single-letter method and parameter names obscure individual operations. Documentation references names such as add and finish that do not match the actual methods, further confusing navigation. Code length: Implementation methods are concise; documentation and deprecated overloads add substantial but mostly useful length. Action granularity: Statements generally perform one action per line, making state changes easy to follow. Reading flow: Formatting and straightforward conditionals help, but calls such as i(), g(), and h() force readers to repeatedly inspect helper definitions.

Run 3

Code Structure: State, listener handling, constructors, and helper methods are logically organized and responsibilities are separated. Nesting: Most methods are flat, although the anonymous listener containing an anonymous Runnable adds localized depth. Clarity of intent: Descriptive state fields and extensive documentation explain the overall purpose, but single-letter method and parameter names obscure individual operations. Documentation references names such as add and finish that do not match the actual methods, further hindering comprehension. Code length: Implementation methods are concise; repeated documentation and deprecated overloads add some reading overhead. Action granularity: Statements generally perform one action per line, making state updates and validation easy to distinguish. Reading flow: Formatting and short methods support scanning, but opaque helper calls such as i(), g(), and h() require frequent navigation to understand the execution sequence.