Sample

int-6dc8bb7d137c-I04

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

Matched original source

Lines178

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8110–1; higher is more readable
Dorn0.1640–1; higher is more readable
Mi0.2910–1; higher is more readable
LLOC29Logical lines; fewer is more readable
DeepSeek V4 Pro2.670–20; mean of three runs
GPT-6.1 Sol11.330–20; mean of three runs
BTTF0.5040–1; higher is more readable

Views

Source code

package io.netty.channel.nio; import io.netty.channel.Channel; import io.netty.channel.DefaultSelectStrategyFactory; import io.netty.channel.EventLoopTaskQueueFactory; import io.netty.channel.IoEventLoop; import io.netty.channel.IoEventLoopGroup; import io.netty.channel.IoHandlerFactory; import io.netty.channel.MultiThreadIoEventLoopGroup; import io.netty.channel.SelectStrategyFactory; import io.netty.channel.SingleThreadEventLoop; import io.netty.util.concurrent.EventExecutor; import io.netty.util.concurrent.EventExecutorChooserFactory; import io.netty.util.concurrent.RejectedExecutionHandler; import io.netty.util.concurrent.RejectedExecutionHandlers; import io.netty.util.internal.logging.InternalLogger; import io.netty.util.internal.logging.InternalLoggerFactory; import java.nio.channels.Selector; import java.nio.channels.spi.SelectorProvider; import java.util.concurrent.Executor; import java.util.concurrent.ThreadFactory; /** * {@link MultiThreadIoEventLoopGroup} implementation which is used for NIO {@link Selector} based {@link Channel}s. * * @deprecated Use {@link MultiThreadIoEventLoopGroup} with {@link NioIoHandler#newFactory()}. */ @Deprecated public class NioEventLoopGroup extends MultiThreadIoEventLoopGroup implements IoEventLoopGroup { private static final InternalLogger LOGGER = InternalLoggerFactory.getInstance(NioEventLoopGroup.class); /** * Create a new instance using the default number of threads, the default {@link ThreadFactory} and * the {@link SelectorProvider} which is returned by {@link SelectorProvider#provider()}. */ public NioEventLoopGroup() { this(0); } /** * Create a new instance using the specified number of threads, {@link ThreadFactory} and the * {@link SelectorProvider} which is returned by {@link SelectorProvider#provider()}. */ public NioEventLoopGroup(int a) { this(a, (Executor) null); } /** * Create a new instance using the default number of threads, the given {@link ThreadFactory} and the * {@link SelectorProvider} which is returned by {@link SelectorProvider#provider()}. */ public NioEventLoopGroup(ThreadFactory b) { this(0, b, SelectorProvider.provider()); } /** * Create a new instance using the specified number of threads, the given {@link ThreadFactory} and the * {@link SelectorProvider} which is returned by {@link SelectorProvider#provider()}. */ public NioEventLoopGroup(int c, ThreadFactory d) { this(c, d, SelectorProvider.provider()); } public NioEventLoopGroup(int f, Executor g) { this(f, g, SelectorProvider.provider()); } /** * Create a new instance using the specified number of threads, the given {@link ThreadFactory} and the given * {@link SelectorProvider}. */ public NioEventLoopGroup( int h, ThreadFactory i, final SelectorProvider j) { this(h, i, j, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int k, ThreadFactory l, final SelectorProvider m, final SelectStrategyFactory n) { super(k, l, NioIoHandler.newFactory(m, n), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup( int o, Executor p, final SelectorProvider q) { this(o, p, q, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int r, Executor s, final SelectorProvider t, final SelectStrategyFactory u) { super(r, s, NioIoHandler.newFactory(t, u), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int v, Executor w, EventExecutorChooserFactory x, final SelectorProvider y, final SelectStrategyFactory z) { super(v, w, NioIoHandler.newFactory(y, z), x, RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int A, Executor B, EventExecutorChooserFactory C, final SelectorProvider D, final SelectStrategyFactory E, final RejectedExecutionHandler F) { super(A, B, NioIoHandler.newFactory(D, E), C, F); } public NioEventLoopGroup(int G, Executor H, EventExecutorChooserFactory I, final SelectorProvider J, final SelectStrategyFactory K, final RejectedExecutionHandler L, final EventLoopTaskQueueFactory M) { super(G, H, NioIoHandler.newFactory(J, K), I, L, M); } /** * @param nThreads the number of threads that will be used by this instance. * @param executor the Executor to use, or {@code null} if default one should be used. * @param chooserFactory the {@link EventExecutorChooserFactory} to use. * @param selectorProvider the {@link SelectorProvider} to use. * @param selectStrategyFactory the {@link SelectStrategyFactory} to use. * @param rejectedExecutionHandler the {@link RejectedExecutionHandler} to use. * @param taskQueueFactory the {@link EventLoopTaskQueueFactory} to use for * {@link SingleThreadEventLoop#execute(Runnable)}, * or {@code null} if default one should be used. * @param tailTaskQueueFactory the {@link EventLoopTaskQueueFactory} to use for * {@link SingleThreadEventLoop#executeAfterEventLoopIteration(Runnable)}, * or {@code null} if default one should be used. */ public NioEventLoopGroup(int N, Executor O, EventExecutorChooserFactory P, SelectorProvider Q, SelectStrategyFactory R, RejectedExecutionHandler S, EventLoopTaskQueueFactory T, EventLoopTaskQueueFactory U) { super(N, O, NioIoHandler.newFactory(Q, R), P, S, T, U); } /** * This method is a no-op. * * @deprecated */ @Deprecated public void a(int V) { LOGGER.debug("NioEventLoopGroup.setIoRatio(int) logic was removed, this is a no-op"); } /** * Replaces the current {@link Selector}s of the child event loops with newly created {@link Selector}s to work * around the infamous epoll 100% CPU bug. */ public void b() { for (EventExecutor e: this) { ((NioEventLoop) e).rebuildSelector(); } } @Override protected IoEventLoop c(Executor W, IoHandlerFactory X, Object... Y) { RejectedExecutionHandler Z = (RejectedExecutionHandler) Y[0]; EventLoopTaskQueueFactory aa = null; EventLoopTaskQueueFactory ab = null; int ac = Y.length; if (ac > 1) { aa = (EventLoopTaskQueueFactory) Y[1]; } if (ac > 2) { ab = (EventLoopTaskQueueFactory) Y[2]; } return new NioEventLoop( this, W, X, aa, ab, Z); } }

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.5661.452−186.828
Source linesThe number of non-empty source lines.178+71.2
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.617−6.925

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

Score0.811

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.178−5.266
Indentation frequencyHow rapidly indentation changes from line to line.139+4.071
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.139−2.769
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.177.923+2.077
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.115.978−1.247
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.113.402+1.025
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.055+0.411

Intercept 0.07 + feature contributions = -1.628 (log-odds).
Score = sigmoid(-1.628) = 0.164.

Score0.291
Score29
Run 1

This code is functionally Netty's NioEventLoopGroup but has been deliberately obfuscated by renaming parameters to meaningless sequence letters (a, b, c... A, B, C...) and methods to single letters (a(), b(), c()). This destroys clarity of intent and reading flow. The constructor overloading is excessive (9 constructors), creating repetitive code, though some repetition is typical for Netty-style builder classes. Nesting is shallow, and action granularity is mostly one action per line, but these are undermined by the naming. JavaDoc remains for original parameter names, creating a mismatch with the code. The structure is logical but the obfuscation makes it extremely hard to follow.

Run 2

This code is severely degraded by deliberate obfuscation. Variable names (a, b, c... A, B, C...) are meaningless single letters, destroying readability. Method names like a(), b(), c() obscure intent entirely. The code has reasonable structure and flat nesting, but clarity, intent, and natural reading flow are critically compromised. The parameter Javadoc lists meaningful names that do not match the actual parameters, adding confusion. Constructor chaining is logical but hard to follow due to naming. Overall, the code is technically valid but practically unreadable.

Run 3

This code is extremely unreadable. Variable names are single letters (a, b, c, A, B, X...) providing zero semantic value, completely violating clarity of intent. The method names a(), b(), c() are meaningless. There is deep constructor chaining with 8 overloaded constructors, creating tangled and hard-to-follow code. The 'a' method receives an unexplained int parameter only to log a no-op message - extremely confusing. Parameter names are sequential alphabet letters with no meaning (N, O, P, Q...). The 'c' method has magic array indexing (Y[0], Y[1], Y[2]) to extract arguments from Object varargs - a severe anti-pattern that obscures intent and type safety. Action granularity is poor as multiple concepts are packed into single lines. Reading flow is completely unnatural. This appears to be deliberately obfuscated code that renders a potentially simple event loop group wrapper nearly incomprehensible.

Run 1

Code Structure: Logically organized into constructors and event-loop operations, with consistent delegation rather than tangled logic. Nesting: Very shallow; only a loop and simple conditionals. Clarity of intent: Severely weakened by single-letter parameter, variable, and method names. Types and comments provide context, but Javadoc parameter names do not match the signatures. Code length: Numerous constructor overloads and repetitive documentation make the class lengthy, although individual implementations are concise. Action granularity: Generally one statement per line, with straightforward assignments and calls. Reading flow: Constructor grouping and whitespace help, but inconsistent wrapping, long argument lists, cryptic identifiers, and positional Object-varargs casts require repeated cross-referencing. Overall, clean control flow is substantially undermined by poor naming.

Run 2

Code Structure: Constructors are logically grouped and delegate consistently, followed by operational methods, but extensive overloads add repetition. Nesting: Very shallow; only a loop and two independent conditionals make control flow easy to follow. Clarity of intent: Class documentation and descriptive types help, but single-letter parameter names and methods a, b, and c obscure responsibilities. Javadoc parameter names do not match the actual signature, further reducing clarity. Code length: Individual methods are concise, but repeated constructor boilerplate and similar documentation make the class lengthy to scan. Action granularity: Most statements perform one action per line; wrapped constructor calls remain understandable. Reading flow: Constructor delegation provides a predictable progression, but inconsistent wrapping, opaque identifiers, and positional Object-varargs extraction interrupt natural reading and require readers to infer argument roles.

Run 3

Code Structure: Constructors are grouped logically and delegate consistently, followed by operational methods, but numerous overloads add repetition. Nesting: Very shallow; the loop and conditionals are straightforward. Clarity of intent: Types, documentation, and library calls convey purpose, but single-letter parameter names and methods a, b, and c obscure meaning. Javadoc parameter names do not match the actual signature, further reducing clarity. Code length: Individual methods are concise, though repeated constructors and documentation make the class lengthy to scan. Action granularity: Statements generally perform one action each, with clear separation of assignments, checks, and calls. Reading flow: Constructor delegation and linear control flow are natural, but inconsistent wrapping, opaque identifiers, and positional Object varargs require readers to infer roles and trace arguments.