Sample

int-66921c6c7039-I10

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

DatasetJava transformations

Lines124

Scores

Method	Score	Scale
Posnett	0	0–1; higher is more readable
Scalabrino	0.56	0–1; higher is more readable
Dorn	0.003	0–1; higher is more readable
Mi	0.007	0–1; higher is more readable
LLOC	29	Logical lines; fewer is more readable
DeepSeek V4 Pro	5	0–20; mean of three runs
GPT-6.1 Sol	11	0–20; mean of three runs
BTTF	0.405	0–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 nThreads) { this(nThreads, (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 threadFactory) { this(0, threadFactory, 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 nThreads, ThreadFactory threadFactory) { this(nThreads, threadFactory, SelectorProvider.provider()); } public NioEventLoopGroup(int nThreads, Executor executor) { this(nThreads, executor, SelectorProvider.provider()); } /** * Create a new instance using the specified number of threads, the given {@link ThreadFactory} and the given * {@link SelectorProvider}. */ public NioEventLoopGroup( int nThreads, ThreadFactory threadFactory, final SelectorProvider selectorProvider) { this(nThreads, threadFactory, selectorProvider, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int nThreads, ThreadFactory threadFactory, final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory) { super(nThreads, threadFactory, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup( int nThreads, Executor executor, final SelectorProvider selectorProvider) { this(nThreads, executor, selectorProvider, DefaultSelectStrategyFactory.INSTANCE); } public NioEventLoopGroup(int nThreads, Executor executor, final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory) { super(nThreads, executor, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory) { super(nThreads, executor, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), chooserFactory, RejectedExecutionHandlers.reject()); } public NioEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory, final RejectedExecutionHandler rejectedExecutionHandler) { super(nThreads, executor, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), chooserFactory, rejectedExecutionHandler); } public NioEventLoopGroup(int nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, final SelectorProvider selectorProvider, final SelectStrategyFactory selectStrategyFactory, final RejectedExecutionHandler rejectedExecutionHandler, final EventLoopTaskQueueFactory taskQueueFactory) { super(nThreads, executor, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), chooserFactory, rejectedExecutionHandler, taskQueueFactory); } /** * @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 nThreads, Executor executor, EventExecutorChooserFactory chooserFactory, SelectorProvider selectorProvider, SelectStrategyFactory selectStrategyFactory, RejectedExecutionHandler rejectedExecutionHandler, EventLoopTaskQueueFactory taskQueueFactory, EventLoopTaskQueueFactory tailTaskQueueFactory) { super(nThreads, executor, NioIoHandler.newFactory(selectorProvider, selectStrategyFactory), chooserFactory, rejectedExecutionHandler, taskQueueFactory, tailTaskQueueFactory); } /** * This method is a no-op. * * @deprecated */ @Deprecated public void setIoRatio(int ioRatio) { 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 rebuildSelectors() { for (EventExecutor e: this) { ((NioEventLoop) e).rebuildSelector(); } } @Override protected IoEventLoop newChild(Executor executor, IoHandlerFactory ioHandlerFactory, Object... args) { RejectedExecutionHandler rejectedExecutionHandler = (RejectedExecutionHandler) args[0]; EventLoopTaskQueueFactory taskQueueFactory = null; EventLoopTaskQueueFactory tailTaskQueueFactory = null; int argsLength = args.length; if (argsLength > 1) { taskQueueFactory = (EventLoopTaskQueueFactory) args[1]; } if (argsLength > 2) { tailTaskQueueFactory = (EventLoopTaskQueueFactory) args[2]; } return new NioEventLoop( this, executor, ioHandlerFactory, taskQueueFactory, tailTaskQueueFactory, rejectedExecutionHandler); } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature	Value	Contribution (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.	5279.93	−174.238
Source linesThe number of non-empty source lines.	124	+49.6
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.708	−7.062

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

Score	0.56

Feature contributions

Feature	Value	Contribution (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.	299.976	−9.041
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.	300	+4.036
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.	124	−3.354
Indentation frequencyHow rapidly indentation changes from line to line.	85	+2.203
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.	85	−1.53
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.	123.924	+1.322
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.	0.047	+0.483

Intercept 0.07 + feature contributions = -5.81 (log-odds).
Score = sigmoid(-5.81) = 0.003.

Score	0.007

Score	29

Run 1

The code is difficult to read due to severe formatting problems. Multiple constructors and methods are placed on the same line as previous closing braces, and several import statements share lines. This breaks the natural reading flow and makes it hard to scan the class structure. Many constructors are also undocumented or have comments awkwardly positioned. The `newChild` method uses multiple `args[]` accesses and null initializations, making intent unclear. While the logic itself follows a typical Netty event loop group pattern, the tangled layout, packed lines, and inconsistent spacing significantly reduce readability.

Run 2

This code demonstrates poor readability due to severely compressed formatting. The structure is mangled: Javadoc comments and multiple constructors are placed on single lines, making it nearly impossible to scan. Nesting is minimal but only because code is flattened horizontally. Clarity of intent is significantly harmed—parameter meanings are clear from Javadoc but the visual presentation is chaotic. Code length is verbose in terms of constructor overloads, yet each is compressed onto one line, eliminating normal vertical structure. Action granularity is broken: multiple actions (e.g., super() calls, assignment chains, loops) are crammed onto single lines. Reading flow is highly unnatural; the eye must constantly jump across long, dense lines. The class is a straightforward Netty event loop group, but the formatting obscures functionality. Only the final constructor and newChild method border on readable, but still violate standard Java conventions and consistency.

Run 3

This code is significantly marred by formatting that violates conventional Java style: multiple methods are placed on single lines, and Javadoc comments are collapsed directly before method signatures without line breaks. This makes scanning the class structure difficult and leads to extremely long lines. While the underlying logic (constructor delegation, rebuildSelectors loop, newChild argument unpacking) is relatively simple, the presentation obscures intent and creates a tangled reading flow. Nesting is minimal, and action granularity is mostly one action per line in method bodies, but the class-level layout destroys readability. Fixing the formatting—placing each method and its Javadoc on separate lines with proper indentation—would immediately raise the score substantially, likely to around 17 or 18. As written, it is readable only with active effort to parse the compressed structure.

Run 1

1. Code Structure: Constructors are grouped logically and delegate consistently, followed by operational methods, but compressed formatting obscures boundaries. 2. Nesting: Shallow; simple conditionals and one loop are easy to understand. 3. Clarity of intent: Descriptive names, types, and Javadoc explain most behavior; positional Object... arguments and casts in newChild are less explicit. 4. Code length: Individual methods are concise, but numerous similar constructor overloads and repetitive documentation increase scanning effort. 5. Action granularity: Multiple imports, declarations, and method boundaries share lines, undermining the one-action-per-line convention. 6. Reading flow: Inconsistent indentation, long signatures, and comments attached to closing braces interrupt otherwise natural progression. Overall, straightforward logic remains readable, but poor presentation substantially reduces accessibility.

Run 2

Code Structure: Constructors are logically grouped, followed by operational methods, but compressed formatting obscures boundaries. Nesting: Shallow loops and conditionals keep control flow simple. Clarity of intent: Descriptive class, method, and parameter names plus Javadoc explain the purpose; positional Object... arguments and casts in newChild are less clear. Code length: Individual methods are short, though numerous constructor overloads and repetitive documentation increase scanning effort. Action granularity: Multiple imports, declarations, and statements share lines, undermining one-action-per-line readability. Reading flow: Constructor delegation is coherent, but inconsistent indentation, long signatures, and closing braces joined to subsequent declarations or comments repeatedly interrupt reading. Overall, the underlying design is understandable, but presentation substantially reduces readability.

Run 3

Code Structure: Constructors are logically grouped before operational methods, but compressed formatting obscures boundaries. Nesting: Shallow conditionals and a single loop keep control flow simple. Clarity of intent: Descriptive class, method, and parameter names plus Javadocs explain the purpose; positional Object... arguments and casts in newChild are less clear. Code length: Delegation keeps constructor bodies short, though numerous overloads and repetitive documentation increase scanning effort. Action granularity: Multiple imports, declarations, and statements share lines, making individual actions harder to distinguish. Reading flow: Inconsistent wrapping, comments attached to closing braces, and method declarations sharing lines disrupt otherwise natural top-to-bottom organization. Overall, the underlying logic is straightforward, but poor formatting substantially reduces readability.