Sample

int-fe1368901474-I03

Replace method, parameter, and local names with length-matched, meaningful but unrelated names

Matched original source

Lines178

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6970–1; higher is more readable
Dorn0.1750–1; higher is more readable
Mi0.2910–1; higher is more readable
LLOC29Logical lines; fewer is more readable
DeepSeek V4 Pro5.330–20; mean of three runs
GPT-6.1 Sol110–20; mean of three runs
BTTF0.560–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 customer) { this(customer, (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 currentRecord) { this(0, currentRecord, 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 response, ThreadFactory backupSession) { this(response, backupSession, SelectorProvider.provider()); } public NioEventLoopGroup(int nextData, Executor location) { this(nextData, location, SelectorProvider.provider()); } /** * Create a new instance using the specified number of threads, the given {@link ThreadFactory} and the given * {@link SelectorProvider}. */ public NioEventLoopGroup( int nextUser, ThreadFactory secureBalance, final SelectorProvider pendingSession) { this(nextUser, secureBalance, pendingSession, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int localKey, ThreadFactory currentBuffer, final SelectorProvider currentSession, final SelectStrategyFactory pendingBalance) { super(localKey, currentBuffer, NioIoHandler.newFactory(currentSession, pendingBalance), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup( int document, Executor schedule, final SelectorProvider primaryAddress) { this(document, schedule, primaryAddress, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int nextNode, Executor nextPath, final SelectorProvider primaryBalance, final SelectStrategyFactory defaultAddress) { super(nextNode, nextPath, NioIoHandler.newFactory(primaryBalance, defaultAddress), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int shipment, Executor finalKey, EventExecutorChooserFactory defaultSession, final SelectorProvider primarySession, final SelectStrategyFactory currentRequest) { super(shipment, finalKey, NioIoHandler.newFactory(primarySession, currentRequest), defaultSession, RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int nextMode, Executor discount, EventExecutorChooserFactory currentAddress, final SelectorProvider currentMessage, final SelectStrategyFactory defaultRequest, final RejectedExecutionHandler primaryAccount) { super(nextMode, discount, NioIoHandler.newFactory(currentMessage, defaultRequest), currentAddress, primaryAccount); } public NioEventLoopGroup(int duration, Executor category, EventExecutorChooserFactory currentAccount, final SelectorProvider pendingAddress, final SelectStrategyFactory pendingRequest, final RejectedExecutionHandler primaryRequest, final EventLoopTaskQueueFactory defaultAccount) { super(duration, category, NioIoHandler.newFactory(pendingAddress, pendingRequest), currentAccount, primaryRequest, defaultAccount); } /** * @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 nextItem, Executor context, EventExecutorChooserFactory primaryMessage, SelectorProvider defaultBalance, SelectStrategyFactory defaultMessage, RejectedExecutionHandler currentBalance, EventLoopTaskQueueFactory pendingMessage, EventLoopTaskQueueFactory pendingAccount) { super(nextItem, context, NioIoHandler.newFactory(defaultBalance, defaultMessage), primaryMessage, currentBalance, pendingMessage, pendingAccount); } /** * This method is a no-op. * * @deprecated */ @Deprecated public void parseValue(int invoice) { 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 validateSession() { for (EventExecutor map: this) { ((NioEventLoop) map).rebuildSelector(); } } @Override protected IoEventLoop parseKey(Executor profile, IoHandlerFactory sharedRequest, Object... step) { RejectedExecutionHandler pendingClient = (RejectedExecutionHandler) step[0]; EventLoopTaskQueueFactory currentConfig = null; EventLoopTaskQueueFactory recentAccount = null; int localOrder = step.length; if (localOrder > 1) { currentConfig = (EventLoopTaskQueueFactory) step[1]; } if (localOrder > 2) { recentAccount = (EventLoopTaskQueueFactory) step[2]; } return new NioEventLoop( this, profile, sharedRequest, currentConfig, recentAccount, pendingClient); } }

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.5686.82−187.665
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.657−6.986

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

Score0.697

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.974+2.078
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.983−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.047+0.487

Intercept 0.07 + feature contributions = -1.552 (log-odds).
Score = sigmoid(-1.552) = 0.175.

Score0.291
Score29
Run 1

The code is highly unreadable due to several critical issues. Variable names are nonsensical (e.g., 'customer', 'currentRecord', 'backupSession', 'nextData', 'pendingBalance') bearing no relation to their actual purpose (thread count, executor, selector provider, etc.). The class has many overloaded constructors with duplicated logic and inconsistent Javadoc coverage, some documenting parameters that do not exist. The method names 'parseValue' and 'validateSession' do not match their documented behaviors (a no-op and selector rebuild, respectively). Import statements are piled without grouping. While indentation and line breaks are syntactically correct, the identifiers, misaligned comments, and tangled constructor delegation make the intent opaque and maintainability poor.

Run 2

The code is highly unreadable due to pervasive, meaningless parameter names (e.g., 'nextItem', 'context', 'primaryMessage', 'defaultBalance') that obscure intent. While the class structure is logical, the constructor overloading creates a tangled web of delegation. Nesting is mostly flat, but clarity of intent is severely compromised. Action granularity is acceptable, but the reading flow is disorganized by the nonsensical names. The 'parseKey' method has poor granularity and unclear intent. Overall, the code appears deliberately obfuscated.

Run 3

The code structure is logical with clear package/import organization, but readability is severely undermined by nonsensical parameter names like 'customer', 'currentRecord', 'backupSession', 'nextData', 'nextNode', 'nextPath', 'shipment', 'defaultAddress', etc. These names appear to be auto-generated or obfuscated, completely obscuring intent. While nesting is flat and action granularity is reasonable, the inconsistent naming pattern makes the numerous overloaded constructors extremely difficult to follow. The Javadoc is helpful but the parameter names don't match the documented purposes (e.g., 'document' instead of 'nThreads'). The final constructor with extensive parameters is inherently complex, but readable parameter names would have helped. The overall structure follows a logical pattern of constructor chaining, but the obfuscated naming defeats the purpose of self-documenting code and makes maintenance extremely error-prone.

Run 1

1. Code Structure: Constructors are grouped logically, followed by operational methods, but numerous overloads create repetition. 2. Nesting: Very shallow; only a simple loop and independent conditionals, making control flow easy to follow. 3. Clarity of intent: Strongly weakened by misleading names such as customer, shipment, parseValue, and validateSession. Types and comments help, but Javadoc parameter names do not match the actual signatures, and the no-op log references a differently named method. 4. Code length: Individual methods are concise, although repetitive constructor forwarding and documentation make the class lengthy. 5. Action granularity: Generally one statement per line, with clear separation of assignments, checks, and delegation. 6. Reading flow: Constructor chaining and consistent method layout provide reasonable flow, but inconsistent indentation, arbitrary naming, and positional Object varargs require readers to repeatedly infer parameter roles.

Run 2

Code Structure: Constructors are grouped logically, delegate consistently, and precede operational methods. Nesting: Very shallow; only a simple loop and independent conditionals. Clarity of intent: Severely weakened by arbitrary parameter and method names such as customer, secureBalance, parseValue, and parseKey. Types and comments help, but Javadoc parameter names do not match the actual signature, and the no-op log references a differently named method. Code length: Individual methods are concise, although numerous overloads and repetitive documentation make the class lengthy. Action granularity: Generally one statement per line, with constructor delegation and factory calls remaining manageable. Reading flow: Predictable class organization and consistent delegation support navigation, but inconsistent naming and some uneven indentation interrupt comprehension. Overall, clean structural mechanics are offset by misleading identifiers and documentation.

Run 3

Code Structure: Constructors are grouped logically, followed by operational methods, and delegation avoids duplicated implementation. Nesting: Shallow loops and independent conditionals make control flow easy to follow. Clarity of intent: Misleading names such as customer, shipment, parseValue, and validateSession obscure thread counts and event-loop operations. Javadoc parameter names do not match signatures, and the no-op log references a different method name. Code length: Individual bodies are concise, but numerous similar constructor overloads and repetitive documentation increase reading effort. Action granularity: Statements generally perform one action per line, although factory calls embedded in superclass arguments require some unpacking. Reading flow: Consistent delegation and mostly conventional formatting help, but inconsistent naming across overloads, long parameter lists, and positional Object varargs force readers to infer meaning from types and implementation.