Sample

int-7a7b6ed539e7-I02

Shorten method, parameter, and local names without collisions

Matched original source

Lines143

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.6790–1; higher is more readable
Dorn0.7580–1; higher is more readable
Mi0.4540–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro7.330–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.4440–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> select(Class<?> target, final MetadataLookup<T> metadata) { final Map<Method, T> method2 = new LinkedHashMap<>(); Set<Class<?>> handler = new LinkedHashSet<>(); Class<?> specific = null; if (!Proxy.isProxyClass(target)) { specific = ClassUtils.getUserClass(target); handler.add(specific); } handler.addAll(ClassUtils.getAllInterfacesForClassAsSet(target)); for (Class<?> current : handler) { final Class<?> target2 = (specific != null ? specific : current); ReflectionUtils.doWithMethods(current, method -> { Method specific2 = ClassUtils.getMostSpecificMethod(method, target2); T res = metadata.inspect(specific2); if (res != null) { Method bridged = BridgeMethodResolver.findBridgedMethod(specific2); if (bridged == specific2 || bridged == method || bridged.equals(specific2) || bridged.equals(method) || metadata.inspect(bridged) == null) { method2.put(specific2, res); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return method2; } /** * 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> select(Class<?> target3, final ReflectionUtils.MethodFilter method3) { return select(target3, (MetadataLookup<Boolean>) method -> (method3.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 select2(Method met, Class<?> target4) { if (met.getDeclaringClass().isAssignableFrom(target4)) { return met; } try { String method = met.getName(); Class<?>[] parameter = met.getParameterTypes(); for (Class<?> ifc : target4.getInterfaces()) { try { return ifc.getMethod(method, parameter); } catch (NoSuchMethodException ex) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return target4.getMethod(method, parameter); } catch (NoSuchMethodException ex) { 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.", met.getName(), met.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 ins(Method met2); } }

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.3765.02−124.246
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.916−7.374

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

Score0.679

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.808+1.586
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.96.639+0.755
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.97.986−0.485
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.06+0.363

Intercept 0.07 + feature contributions = 1.14 (log-odds).
Score = sigmoid(1.14) = 0.758.

Score0.454
Score33
Run 1

The code has decent high-level structure (class, methods, interface), but readability suffers from poor naming (method2, target3, method3, select2, met, met2), inconsistent naming patterns, and ambiguous variable names that obscure intent. Nesting is moderate, but the multi-line conditional with multiple `||` conditions is difficult to parse. Action granularity is acceptable overall, but some lines mix multiple actions (e.g., combining method resolution and lambda logic). Reading flow is disrupted by the abrupt variable numbering (target, target2, target3, target4) and duplicated logic in bridge-method resolution. The JavaDoc comments are helpful and clear, which partially mitigates the issues. Overall, the code functions but requires effort to understand due to naming and conditional complexity.

Run 2

The code has clear Javadoc and logical separation of methods, but readability is hampered by inconsistent and cryptic naming: method2, handler, target2/target3/target4, specific2, method3, met/met2. The select method mixes multiple operations within a single loop with long boolean conditions and deeply nested logic, reducing clarity. The second select method is concise but still has ambiguous parameter names. The select2 method is relatively straightforward but uses non-descriptive variable names as well. The file structure is typical, but overall clarity of intent and reading flow suffer due to naming and nested conditional logic.

Run 3

The code shows significant readability problems. Variable names are poor and inconsistent: 'target', 'target2', 'target3', 'target4', 'method', 'method2', 'method3', 'met', 'met2' - these numbered variants obscure intent. Method names like 'select2' and 'ins' are unclear. There's dead code: the variable 'specific' is only used in a null-check and assignment (target2 = specific != null ? specific : current), then never meaningfully used afterward, adding confusion. The main select method has moderate nesting with multiple conditionals and a complex bridged-method if statement combining four Boolean conditions on one line. Long lambda bodies reduce readability. The code does have logical grouping of methods and javadoc comments, which helps, but the cryptic naming, ambiguous purpose of variables, dead code, and inconsistent parameter/variable nomenclature make the implementation hard to follow and maintain. Structure and intent lose clarity due to these issues, outweighing the positive aspects of organizational structure and comments.

Run 1

Code Structure: Clearly separated methods and a small callback interface provide logical organization. Nesting: Moderate nesting in the traversal lambda and interface lookup adds complexity without becoming extreme. Clarity of intent: Detailed documentation helps, but vague numbered names such as method2, target3, and select2 obscure roles. Documentation parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's ins method, undermining confidence in the intended behavior. Code length: Mostly proportionate to the reflection logic, though verbose documentation and the long bridge-method condition increase reading effort. Action granularity: Most statements perform one action, but the filter overload combines adaptation, selection, and key extraction in one expression. Reading flow: Consistent formatting and sequential lookup steps help, while ambiguous identifiers, nested exception handling, and the compound bridge condition interrupt comprehension.

Run 2

Code Structure: The utility class is logically organized into selection methods and a callback interface. Nesting: Moderate nesting in the method-scanning lambda and interface lookup adds complexity but remains manageable. Clarity of intent: Detailed documentation helps, but vague numbered names such as select2, target4, and specific2 obscure roles. Documentation parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's ins method, making the intended API inconsistent. Code length: Reasonably concise for reflection and proxy handling, though documentation and the long exception message add bulk. Action granularity: Most lines perform one action; the filter overload and compound bridge-method condition require more unpacking. Reading flow: Consistent formatting and logical progression support readability, but inconsistent naming, nested exception handling, and the dense bridge-method predicate interrupt comprehension.

Run 3

Code Structure: Well-separated static methods and a callback interface provide logical organization. Nesting: Moderate nesting in the metadata-selection lambda and interface-search exception handling adds cognitive load. Clarity of intent: Documentation explains the purpose, but vague, numbered identifiers such as method2, target4, specific2, and select2 obscure roles. Javadoc parameter names do not match signatures, and calls to metadata.inspect conflict with the interface's declared ins method, making the intended callback usage confusing. Code length: Mostly proportionate to the reflection and proxy-handling logic, though documentation is verbose. Action granularity: Most lines perform one action; the chained selection expression and compound bridge-method condition are denser. Reading flow: Consistent formatting and sensible method ordering help, but inconsistent naming, mismatched documentation, and the long conditional interrupt otherwise natural progression.