Sample

int-24a84ab8f1e0-I04

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

Matched original source

Lines16

Scores

MethodScoreScale
Posnett0.8960–1; higher is more readable
Scalabrino10–1; higher is more readable
Dorn0.8450–1; higher is more readable
Mi0.7740–1; higher is more readable
LLOC3Logical lines; fewer is more readable
DeepSeek V4 Pro7.330–20; mean of three runs
GPT-6.1 Sol13.670–20; mean of three runs
BTTF0.6350–1; higher is more readable

Views

Source code

package com.google.common.cache; import com.google.common.annotations.GwtCompatible; /** * Abstract interface for objects that can concurrently add longs. * * @author Louis Wasserman */ @GwtCompatible interface LongAddable { void a(); void b(long a); long c(); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
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.683−7.024
Source linesThe number of non-empty source lines.16+6.4
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.184.477−6.088

Intercept 8.87 + feature contributions = 2.158 (log-odds).
Score = sigmoid(2.158) = 0.896.

Score1

Feature contributions

FeatureValueContribution
(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.65.941+0.872
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.17+0.434
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Indentation frequencyHow rapidly indentation changes from line to line.12−0.322
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.66+0.26
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.15.91−0.187
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.08+0.169

Intercept 0.07 + feature contributions = 1.695 (log-odds).
Score = sigmoid(1.695) = 0.845.

Score0.774
Score3
Run 1

The code is an interface with three method signatures: a(), b(long), and c(). While the structure is minimal and flat, the method names are completely opaque, giving no indication of their purpose (likely increment, add, and sum based on the class comment, but this is not expressed in the code). This violates clarity of intent. Additionally, the parameter and method names use single letters, which significantly hurts readability and maintainability. Although the code is concise, the lack of descriptive naming makes it effectively unreadable without external documentation. There is no unnecessary nesting or length, but the ambiguity of every identifier dominates all other considerations.

Run 2

The code structure is logically organized with package, import, annotation, and interface declaration in proper order. Nesting is nonexistent, so it excels there. However, clarity of intent is severely poor: the methods are named 'a', 'b', and 'c' with a parameter 'a', giving no semantic meaning beyond the single-line Javadoc mentioning 'add longs'. A reader cannot infer method purposes without external metadata. Code length is concise, but this brevity sacrifices readability. Action granularity is good since each method declaration occupies one line, but the meaningless names undermine it. Reading flow is disrupted by cryptic identifiers. Proper naming (e.g., 'increment', 'add', 'sum') would dramatically improve clarity. The class-level comment is helpful but insufficient to offset the obfuscated method names.

Run 3

The code is structurally clean with a clear package, single import, and a concise Javadoc comment. There is no nesting, and the interface has only three methods, keeping it flat and short. However, the method names (a(), b(), c()) are completely opaque, which severely undermines clarity of intent and reading flow. Parameter naming is also poor (e.g., 'long a'), making it impossible to infer purpose without documentation or external context. Action granularity is fine since each method is a single line, but the ambiguous naming drags the overall readability down significantly.

Run 1

Code Structure: The package, import, documentation, annotation, and interface are logically organized. Nesting: Minimal nesting makes the code easy to scan. Clarity of intent: The interface name and documentation suggest concurrent long accumulation, but method names a, b, and c and parameter name a obscure individual operations. Code length: Concise, with no unnecessary implementation or boilerplate. Action granularity: Each method declaration occupies its own line. Reading flow: Declaration order and spacing are natural, although a blank line between the package and import would improve formatting. Ambiguous method names are the main readability weakness.

Run 2

Code Structure: The package, import, documentation, annotation, and interface are logically organized. Nesting: There is no unnecessary nesting. Clarity of intent: The documentation identifies the general purpose, but method names a, b, and c and parameter name a obscure individual operations; descriptive names such as increment, add, and sum would improve readability. Code length: The interface is concise with no redundant code. Action granularity: Each method declaration occupies its own line. Reading flow: The conventional layout and spacing make scanning easy, although ambiguous naming interrupts understanding.

Run 3

Code Structure: The package, import, documentation, annotation, and interface are logically organized. Nesting: There is only a single interface scope, so nesting is minimal. Clarity of intent: The interface name and documentation establish a concurrent long-addition purpose, but method names a, b, and c and parameter name a conceal individual operations and return semantics. Code length: The snippet is concise with no unnecessary implementation or boilerplate. Action granularity: Each method declaration occupies its own line. Reading flow: Conventional Java ordering and spacing make the code easy to scan, though understanding the API requires guessing what the methods do.