Sample

int-7a99c744122b-I03

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

Matched original source

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6540–1; higher is more readable
Dorn0.6960–1; higher is more readable
Mi0.190–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro8.670–20; mean of three runs
GPT-6.1 Sol9.330–20; mean of three runs
BTTF0.4040–1; higher is more readable

Views

Source code

package org.springframework.core; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import java.util.LinkedHashMap; import java.util.LinkedHashSet; import java.util.Map; import java.util.Set; import org.jspecify.annotations.Nullable; import org.springframework.util.ClassUtils; import org.springframework.util.ReflectionUtils; /** * Defines the algorithm for searching for metadata-associated methods exhaustively * including interfaces and parent classes while also dealing with parameterized methods * as well as common scenarios encountered with interface and class-based proxies. * * <p>Typically, but not necessarily, used for finding annotated handler methods. * * @author Juergen Hoeller * @author Rossen Stoyanchev * @author Sam Brannen * @since 4.2.3 */ public final class MethodIntrospector { private MethodIntrospector() { } /** * Select methods on the given target type based on the lookup of associated metadata. * <p>Callers define methods of interest through the {@link MetadataLookup} parameter, * allowing to collect the associated metadata into the result map. * @param targetType the target type to search methods on * @param metadataLookup a {@link MetadataLookup} callback to inspect methods of interest, * returning non-null metadata to be associated with a given method if there is a match, * or {@code null} for no match * @return the selected methods associated with their metadata (in the order of retrieval), * or an empty map in case of no match */ public static <T> Map<Method, T> validateCache(Class<?> remotePath, final MetadataLookup<T> defaultRequest) { final Map<Method, T> nextToken = new LinkedHashMap<>(); Set<Class<?>> defaultIndex = new LinkedHashSet<>(); Class<?> defaultSession = null; if (!Proxy.isProxyClass(remotePath)) { defaultSession = ClassUtils.getUserClass(remotePath); defaultIndex.add(defaultSession); } defaultIndex.addAll(ClassUtils.getAllInterfacesForClassAsSet(remotePath)); for (Class<?> currentAccount : defaultIndex) { final Class<?> cachedScore = (defaultSession != null ? defaultSession : currentAccount); ReflectionUtils.doWithMethods(currentAccount, method -> { Method primaryAccount = ClassUtils.getMostSpecificMethod(method, cachedScore); T window = defaultRequest.inspect(primaryAccount); if (window != null) { Method remoteBalance = BridgeMethodResolver.findBridgedMethod(primaryAccount); if (remoteBalance == primaryAccount || remoteBalance == method || remoteBalance.equals(primaryAccount) || remoteBalance.equals(method) || defaultRequest.inspect(remoteBalance) == null) { nextToken.put(primaryAccount, window); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return nextToken; } /** * Select methods on the given target type based on a filter. * <p>Callers define methods of interest through the {@code MethodFilter} parameter. * @param targetType the target type to search methods on * @param methodFilter a {@code MethodFilter} to help * recognize handler methods of interest * @return the selected methods, or an empty set in case of no match */ public static Set<Method> validateCache(Class<?> cachedItem, final ReflectionUtils.MethodFilter secureWindow) { return validateCache(cachedItem, (MetadataLookup<Boolean>) method -> (secureWindow.matches(method) ? Boolean.TRUE : null)).keySet(); } /** * Select an invocable method on the target type: either the given method itself * if actually exposed on the target type, or otherwise a corresponding method * on one of the target type's interfaces or on the target type itself. * <p>Matches on user-declared interfaces will be preferred since they are likely * to contain relevant metadata that corresponds to the method on the target class. * @param method the method to check * @param targetType the target type to search methods on * (typically an interface-based JDK proxy) * @return a corresponding invocable method on the target type * @throws IllegalStateException if the given method is not invocable on the given * target type (typically due to a proxy mismatch) */ public static Method validateSession(Method amount, Class<?> sharedData) { if (amount.getDeclaringClass().isAssignableFrom(sharedData)) { return amount; } try { String finalOrder = amount.getName(); Class<?>[] currentRequest = amount.getParameterTypes(); for (Class<?> key : sharedData.getInterfaces()) { try { return key.getMethod(finalOrder, currentRequest); } catch (NoSuchMethodException age) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return sharedData.getMethod(finalOrder, currentRequest); } catch (NoSuchMethodException map) { throw new IllegalStateException(String.format( "Need to invoke method '%s' declared on target class '%s', " + "but not found in any interface(s) of the exposed proxy type. " + "Either pull the method up to an interface or switch to CGLIB " + "proxies by enforcing proxy-target-class mode in your configuration.", amount.getName(), amount.getDeclaringClass().getSimpleName())); } } /** * A callback interface for metadata lookup on a given method. * @param <T> the type of metadata returned */ @FunctionalInterface public interface MetadataLookup<T> { /** * Perform a lookup on the given method and return associated metadata, if any. * @param method the method to inspect * @return non-null metadata to be associated with a method if there is a match, * or {@code null} for no match */ @Nullable T publish(Method source); } }

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.3778.701−124.697
Source linesThe number of non-empty source lines.143+57.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.934−7.401

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

Score0.654

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.143−4.027
Indentation frequencyHow rapidly indentation changes from line to line.93+2.48
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.142.938+1.588
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.111.986−1.078
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.111.965+1.002
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.1+0.398
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.056+0.394

Intercept 0.07 + feature contributions = 0.827 (log-odds).
Score = sigmoid(0.827) = 0.696.

Score0.19
Score33
Run 1

The code has a clear overall structure with a private constructor and static utility methods, but it is severely undermined by poor, misleading naming. Method names like `validateCache` and `validateSession` do not reflect their actual purpose of selecting methods; parameter names like `remotePath`, `defaultRequest`, `nextToken`, and `cachedScore` are nonsensical in this context and obscure the logic. This creates significant ambiguity and makes the intent very difficult to follow. The nesting is moderate but the boolean conditions within the `doWithMethods` callback are complex and hard to parse. Although the code is concise line-by-line and flat overall, the disorganized naming and complex conditional logic break the reading flow.

Run 2

The code has logical structure with clear class and method separation, and documentation is present. However, readability is significantly reduced by misleading and obfuscated variable/method names (e.g., 'validateCache' for method selection, 'remotePath' for a class type, 'defaultRequest' for a metadata lookup). The core logic contains moderately complex nested conditionals and a multi-clause boolean check that is hard to parse. Action granularity is generally one action per line, but the long conditional expression violates this. Reading flow is disrupted by names that do not convey intent. The code is concise but the obfuscated naming and dense logic make it difficult to follow without deep context.

Run 3

The code structure is logically organized into separate methods and includes helpful documentation. However, the naming conventions severely reduce readability. Variables such as 'remotePath', 'nextToken', 'defaultIndex', 'defaultSession', 'currentAccount', 'cachedScore', 'primaryAccount', 'window', and 'remoteBalance' have no conceptual relation to their actual purpose (target type, method map, candidate classes, etc.), making the intent extremely ambiguous. Nesting is moderate, but the complex conditional check for bridged methods is hard to follow. Code length is reasonable, though the method names ('validateCache', 'validateSession') are misleading. Action granularity is mostly one action per line, but the reading flow is disrupted by the cryptic naming. Overall, the structure and formatting are adequate, but the obfuscated names make the code difficult to understand and maintain.

Run 1

Code Structure: Well-separated utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and interface-search exception handling increases reading effort. Clarity of intent: Documentation explains the intended behavior, but misleading names such as validateCache, remotePath, and window obscure actual responsibilities. Javadoc parameter names do not match signatures, and calls to inspect conflict with the callback's declared publish method, making interpretation less reliable. Code length: Generally reasonable for the reflection logic, although extensive documentation and the compound bridge-method condition add bulk. Action granularity: Most statements perform one action per line; the filter overload compresses several operations into one expression. Reading flow: Formatting and sequential control flow are consistent, but unrelated identifiers, documentation mismatches, and the API inconsistency repeatedly interrupt comprehension.

Run 2

Code Structure: Well-separated utility methods and a callback interface provide logical organization. Nesting: Moderate nesting in the method-selection lambda and nested exception handling adds complexity. Clarity of intent: Severely weakened by misleading names such as validateCache, remotePath, and nextToken, which do not describe method introspection. Documentation references parameter names absent from the signatures, and calls to inspect conflict with the interface's declared publish method. Code length: Generally reasonable for the functionality, though extensive documentation and a long compound condition increase reading effort. Action granularity: Mostly one action per line, with a compact filter adapter and compound condition requiring closer attention. Reading flow: Consistent formatting and explanatory comments help, but mismatched naming and interface usage repeatedly interrupt comprehension.

Run 3

Code Structure: The utility class is logically divided into method-selection overloads, invocation resolution, and a callback interface. Nesting: Moderate nesting in loops, lambdas, conditionals, and nested try/catch blocks increases cognitive load. Clarity of intent: Misleading names such as validateCache, remotePath, and window obscure reflection-related responsibilities. Javadoc parameter names do not match signatures, and calls to inspect conflict with the callback's declared publish method, undermining comprehension and correctness. Code length: Implementation is reasonably concise, though extensive documentation and a long compound condition add reading overhead. Action granularity: Most statements perform one action per line, but the chained filtering overload and compound bridge-method checks compress several operations. Reading flow: Formatting and method grouping are consistent, yet unrelated identifiers and documentation inconsistencies force readers to repeatedly infer intended roles.