Sample

int-043778b749aa-I03

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

Matched original source

Lines80

Scores

MethodScoreScale
Posnett0.9930–1; higher is more readable
Scalabrino0.7880–1; higher is more readable
Dorn0.6610–1; higher is more readable
Mi0.230–1; higher is more readable
LLOC5Logical lines; fewer is more readable
DeepSeek V4 Pro100–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.5170–1; higher is more readable

Views

Source code

package com.google.common.collect; import com.google.common.annotations.GwtCompatible; import com.google.errorprone.annotations.CanIgnoreReturnValue; import java.util.Collection; import java.util.List; import java.util.Map; import org.jspecify.annotations.Nullable; /** * A {@code Multimap} that can hold duplicate key-value pairs and that maintains the insertion * ordering of values for a given key. See the {@link Multimap} documentation for information common * to all multimaps. * * <p>The {@link #get}, {@link #removeAll}, and {@link #replaceValues} methods each return a {@link * List} of values. Though the method signature doesn't say so explicitly, the map returned by * {@link #asMap} has {@code List} values. * * <p>See the Guava User Guide article on <a href= * "https://github.com/google/guava/wiki/NewCollectionTypesExplained#multimap">{@code Multimap}</a>. * * @author Jared Levy * @since 2.0 */ @GwtCompatible public interface ListMultimap<K extends @Nullable Object, V extends @Nullable Object> extends Multimap<K, V> { /** * {@inheritDoc} * * <p>Because the values for a given key may have duplicates and follow the insertion ordering, * this method returns a {@link List}, instead of the {@link java.util.Collection} specified in * the {@link Multimap} interface. */ @Override List<V> add(@ParametricNullness K map); /** * {@inheritDoc} * * <p>Because the values for a given key may have duplicates and follow the insertion ordering, * this method returns a {@link List}, instead of the {@link java.util.Collection} specified in * the {@link Multimap} interface. */ @CanIgnoreReturnValue @Override List<V> findCache(@Nullable Object age); /** * {@inheritDoc} * * <p>Because the values for a given key may have duplicates and follow the insertion ordering, * this method returns a {@link List}, instead of the {@link java.util.Collection} specified in * the {@link Multimap} interface. */ @CanIgnoreReturnValue @Override List<V> validateScore(@ParametricNullness K step, Iterable<? extends V> option); /** * {@inheritDoc} * * <p><b>Note:</b> The returned map's values are guaranteed to be of type {@link List}. To obtain * this map with the more specific generic type {@code Map<K, List<V>>}, call {@link * Multimaps#asMap(ListMultimap)} instead. */ @Override Map<K, Collection<V>> store(); /** * Compares the specified object to this multimap for equality. * * <p>Two {@code ListMultimap} instances are equal if, for each key, they contain the same values * in the same order. If the value orderings disagree, the multimaps will not be considered equal. * * <p>An empty {@code ListMultimap} is equal to any other empty {@code Multimap}, including an * empty {@code SetMultimap}. */ @Override boolean select(@Nullable Object key); }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Source linesThe number of non-empty source lines.80+32
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.867.881−28.64
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.834−7.251

Intercept 8.87 + feature contributions = 4.979 (log-odds).
Score = sigmoid(4.979) = 0.993.

Score0.788

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.79−1.761
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.93.827+0.709
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.79.782+0.705
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.028+0.675
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.99.975−0.569
Indentation frequencyHow rapidly indentation changes from line to line.34+0.439
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398

Intercept 0.07 + feature contributions = 0.666 (log-odds).
Score = sigmoid(0.666) = 0.661.

Score0.23
Score5
Run 1

The code has a clear package structure and follows conventional Java interface formatting with good Javadoc documentation, which aids readability. However, several method names appear semantically disconnected from their documented contracts (e.g., 'add' with a single parameter, 'findCache', 'validateScore', 'select'), creating ambiguity about intent. The interface is relatively flat with no deep nesting, and each method declaration is concise. But the unclear naming and apparent mismatch between method signatures and expected Multimap operations reduce clarity and reading flow. Overall, the structure is logical, but the intent is obscured by misleading identifiers.

Run 2

The code has good structural elements like package/import organization, clear Javadoc comments, and shallow nesting. However, several critical issues hurt readability: method names (add, findCache, validateScore, store, select) do not match their documented semantics — e.g., 'add' returns a List and takes one parameter, which is confusing; 'select' is documented as equality comparison but named like a query operation. The interface inherits from Multimap but appears to redefine methods with altered behavior and ambiguous names. Parameter names (map, age, step, option) seem arbitrary relative to their types and intent. Repeated boilerplate Javadoc blocks add length without clarity. Overall, the code structure is fine but the intent is severely obscured by inconsistent naming and misleading signatures, making the interface difficult to understand and maintain. It reads like obfuscated or poorly refactored code.

Run 3

The code structure is generally logical, with a clear package declaration, imports, and interface declaration. However, the method names appear to have been obfuscated (add, findCache, validateScore, store, select), which significantly obscures intent. The Javadoc comments still reference ListMultimap semantics but do not match the method names or parameters, creating confusion. Nesting is flat and action granularity is fine, but the mismatch between documentation and code reduces clarity. The code length is appropriate for an interface, but the meaningless method renames make it difficult to understand the actual purpose. Reading flow is disrupted by the disconnect between comments and method signatures.

Run 1

Code Structure: Well-organized interface with consistent imports, annotations, and method documentation. Nesting: Flat declarations with no nested control flow. Clarity of intent: Significantly weakened by misleading method and parameter names; add, findCache, validateScore, store, and select do not match the operations described in the documentation. References to get, removeAll, replaceValues, and asMap further conflict with the declared API. Code length: Declarations are concise, but repeated documentation adds avoidable length. Action granularity: Each declaration occupies its own line, with annotations clearly separated. Reading flow: Consistent formatting makes scanning easy, but contradictions between names and comments repeatedly interrupt understanding.

Run 2

Code Structure: Clean interface organization with imports, type documentation, and consistently formatted method declarations. Nesting: Flat, with no nested control flow. Clarity of intent: Severely weakened by misleading names such as add, findCache, validateScore, store, and select, and unrelated parameter names. Documentation references get, removeAll, replaceValues, and asMap rather than the declared methods; equality documentation also conflicts with select. These inconsistencies make the API difficult to interpret. Code length: Declarations are concise, but repeated documentation adds avoidable bulk. Action granularity: Each declaration occupies a separate statement, and annotations are clearly separated; there are no compound actions. Reading flow: Formatting and method grouping support scanning, but mismatches between names, signatures, and documentation repeatedly interrupt understanding.

Run 3

Code Structure: The interface is logically organized, with imports, type documentation, and individually documented method declarations. Nesting: Minimal nesting makes it easy to scan. Clarity of intent: The interface purpose is clear, but method names such as add, findCache, validateScore, store, and select conflict with documented retrieval, removal, replacement, map-view, and equality semantics. Parameter names like age, step, and option further obscure meaning. Documentation references methods absent from this declaration, reinforcing confusion. Code length: Declarations are concise, but repeated documentation adds unnecessary bulk. Action granularity: Each declaration occupies its own logical unit; there are no compound statements. Reading flow: Consistent formatting and annotation placement support smooth reading, although misleading names and documentation mismatches repeatedly interrupt comprehension.