Sample

int-90125ab10ff0-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines31

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.880–1; higher is more readable
Dorn0.5380–1; higher is more readable
Mi0.2570–1; higher is more readable
LLOC3Logical lines; fewer is more readable
DeepSeek V4 Pro18.330–20; mean of three runs
GPT-6.1 Sol190–20; mean of three runs
BTTF0.6480–1; higher is more readable

Views

Source code

package io.netty.util; import io.netty.microbench.util.AbstractMicrobenchmark; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.Measurement; import org.openjdk.jmh.annotations.OutputTimeUnit; import org.openjdk.jmh.annotations.Param; import org.openjdk.jmh.annotations.Threads; import org.openjdk.jmh.annotations.Warmup; import java.util.concurrent.TimeUnit; @Threads(1) @Warmup(iterations = 3) @Measurement(iterations = 3) @OutputTimeUnit(TimeUnit.MICROSECONDS) public class GetIpV6ByNameBenchmark extends AbstractMicrobenchmark { @Param({ "::", "::1234:2345", "1234:2345::3456:7890", "fe80::bdad:7a67:6fcd:fa89", "fe80:bdad:7a67:6fcd::fa89", "1234:2345:3456:4567:5678:6789:0:7890" }) private String ip; @Benchmark public byte[] get() { return NetUtil.getIPv6ByName(ip, true); } }

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.927.923−30.621
Source linesThe number of non-empty source lines.31+12.4
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5.172−7.759

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

Score0.88

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.0−0.804
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.67.969+0.786
Indentation frequencyHow rapidly indentation changes from line to line.31+0.335
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.31−0.291
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.30.942+0.023
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.095+0.022
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.29+0.01

Intercept 0.07 + feature contributions = 0.151 (log-odds).
Score = sigmoid(0.151) = 0.538.

Score0.257
Score3
Run 1

The code is highly readable. It has a clean, logical structure with a single class and one benchmark method. Nesting is minimal, with only a Param annotation containing multiple string literals. The intent is clear: benchmarking IPv6 name resolution for various address formats. Code length is concise and appropriate. Each action (annotation, field, method) is on a separate line, aiding granularity and readability. Reading flow is natural, from package and imports to annotations, field, and method. The only minor deduction is the long list of IPv6 addresses in the Param annotation, which could be slightly denser but is still very clear.

Run 2

The code is highly readable. Structure is logical: imports are specific, class annotations are grouped, and the benchmark method is isolated. Nesting is minimal—only one method with a single return. Intent is clear: a JMH microbenchmark for IPv6 name resolution with varied address formats. Code length is concise; no unnecessary code exists. Action granularity is appropriate: field declaration, annotations, and the single-line return are distinct. Reading flow is natural, moving from setup to execution. Minor deductions: the @Param array slightly reduces visual scannability, and no inline comment explains the 'true' boolean parameter, but overall clarity remains high.

Run 3

The code is well-structured and highly readable. It uses clear annotations to define benchmark parameters, making intent obvious. Nesting is minimal, with a single method containing one clear action. The parameter list is concise and directly relevant to the test cases being benchmarked. Action granularity is excellent—one operation per line. Reading flow is logical, moving from package declaration to class definition, fields, and method. Overall, this is a clean, focused example of a JMH microbenchmark with no unnecessary complexity.

Run 1

Code Structure: Logically organized into imports, benchmark configuration, test inputs, and a single benchmark method. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name, JMH annotations, and IPv6 parameters clearly establish the benchmark's purpose; however, the generic method name 'get' and unexplained boolean argument 'true' slightly reduce clarity. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each declaration and the return operation occupies its own line. Reading flow: Natural top-to-bottom progression, though a blank line after the package declaration and clearer import grouping would improve formatting.

Run 2

Code Structure: Logically organized into imports, benchmark configuration, input parameters, and a benchmark method. Nesting: Very shallow, with no nested control flow. Clarity of intent: The class name and JMH annotations clearly identify an IPv6 parsing benchmark; however, the method name get is generic, and the boolean argument true does not explain its purpose. Code length: Concise, with no unnecessary logic or repetition. Action granularity: Each import, declaration, and return occupies its own line. Reading flow: Natural top-to-bottom progression, supported by consistent indentation and spacing within the class; separating the package declaration and import groups with blank lines would improve readability slightly.

Run 3

Code Structure: Logically organized into imports, benchmark configuration, input parameters, and a benchmark method. Nesting: Minimal, with no nested control flow. Clarity of intent: The class name, annotations, and IPv6 inputs clearly identify the benchmark's purpose; however, get() is generic and the boolean argument true is unexplained. Code length: Concise, containing only essential benchmark setup and execution. Action granularity: Each annotation, declaration, and return statement serves a distinct purpose, with one executable action on its line. Reading flow: Natural top-to-bottom progression; blank lines between the package and imports and clearer import grouping would slightly improve readability.