Sample

int-d501db420bc3-I10

Remove about 40% of line-break groups while retaining structure

Matched original source

Lines107

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.4410–1; higher is more readable
Dorn0.0350–1; higher is more readable
Mi00–1; higher is more readable
LLOC33Logical lines; fewer is more readable
DeepSeek V4 Pro50–20; mean of three runs
GPT-6.1 Sol120–20; mean of three runs
BTTF0.3420–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> selectMethods(Class<?> targetType, final MetadataLookup<T> metadataLookup) { final Map<Method, T> methodMap = new LinkedHashMap<>(); Set<Class<?>> handlerTypes = new LinkedHashSet<>(); Class<?> specificHandlerType = null; if (!Proxy.isProxyClass(targetType)) { specificHandlerType = ClassUtils.getUserClass(targetType); handlerTypes.add(specificHandlerType); } handlerTypes.addAll(ClassUtils.getAllInterfacesForClassAsSet(targetType)); for (Class<?> currentHandlerType : handlerTypes) { final Class<?> targetClass = (specificHandlerType != null ? specificHandlerType : currentHandlerType); ReflectionUtils.doWithMethods(currentHandlerType, method -> { Method specificMethod = ClassUtils.getMostSpecificMethod(method, targetClass); T result = metadataLookup.inspect(specificMethod); if (result != null) { Method bridgedMethod = BridgeMethodResolver.findBridgedMethod(specificMethod); if (bridgedMethod == specificMethod || bridgedMethod == method || bridgedMethod.equals(specificMethod) || bridgedMethod.equals(method) || metadataLookup.inspect(bridgedMethod) == null) { methodMap.put(specificMethod, result); } } }, ReflectionUtils.USER_DECLARED_METHODS); } return methodMap; } /** * 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> selectMethods(Class<?> targetType, final ReflectionUtils.MethodFilter methodFilter) { return selectMethods(targetType, (MetadataLookup<Boolean>) method -> (methodFilter.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 selectInvocableMethod(Method method, Class<?> targetType) { if (method.getDeclaringClass().isAssignableFrom(targetType)) { return method; } try { String methodName = method.getName(); Class<?>[] parameterTypes = method.getParameterTypes(); for (Class<?> ifc : targetType.getInterfaces()) { try { return ifc.getMethod(methodName, parameterTypes); } catch (NoSuchMethodException ex) { // Alright, not on this interface then... } } // A final desperate attempt on the proxy class itself... return targetType.getMethod(methodName, parameterTypes); } 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.", method.getName(), method.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 inspect(Method method); } }

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.3736.929−123.319
Source linesThe number of non-empty source lines.107+42.8
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.905−7.358

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

Score0.441

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.251.972−7.007
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.251.981+3.261
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.107−2.752
Indentation frequencyHow rapidly indentation changes from line to line.57+1.234
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.106.85+1.084
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.395

Intercept 0.07 + feature contributions = -3.317 (log-odds).
Score = sigmoid(-3.317) = 0.035.

Score0
Score33
Run 1

The code is highly unreadable due to severe formatting issues. Multiple statements are crammed onto single lines, including imports, method signatures, and entire conditional blocks. This violates action granularity and reading flow. Deeply nested conditionals with complex boolean logic, like the bridge method comparison chain, further obscure intent. While the class structure and method names suggest a logical organization, the visual clutter destroys readability. The long, convoluted condition and lack of vertical spacing make it hard to follow execution paths. Javadoc comments are present but are mangled into the code lines. Overall, the code requires significant reformatting to be understandable.

Run 2

The code has serious readability issues. The package declaration and imports are crammed together on single lines, and Javadoc comments are interleaved with method signatures rather than placed above them. This disrupts the natural reading flow and makes the structure difficult to scan. The selectMethods method contains a deeply nested lambda with a complex multi-line boolean condition that is hard to parse. Some lines pack multiple statements (e.g., the Proxy.isProxyClass check), and the selectInvocableMethod method mixes loops, try-catch blocks, and a return statement in a disorganized way. While some parts have reasonable naming and logic is technically sound, the formatting and lack of consistent line breaks make the code unnecessarily difficult to read. Action granularity is inconsistent, and the overall layout feels tangled rather than logically organized.

Run 3

This code is extremely unreadable due to severe formatting issues. The package and imports are collapsed onto single lines, making them difficult to scan. Javadoc comments are concatenated with method signatures, eliminating visual separation. Multiple statements are placed on the same line throughout, especially in methods like selectMethods and selectInvocableMethod, violating the 'one action per line' principle. The deeply nested lambda inside ReflectionUtils.doWithMethods combines multiple boolean checks and a complex if-statement in a single expression, severely hurting comprehension. The vertical structure is almost nonexistent, with method boundaries obscured. While the underlying logic might be reasonable, the presentation is chaotic and forces the reader to mentally parse dense blocks of code. This appears to be the result of aggressive minification rather than purposeful code organization, making it nearly unreadable in its current form.

Run 1

Code Structure: Cohesive utility class with clearly separated method-selection responsibilities and a small callback interface. Nesting: Moderate depth in the loop/lambda/conditional chain and nested exception handling adds complexity. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose, although bridge-method checks require specialized knowledge. Code length: Implementation is reasonably concise; documentation is lengthy but useful, and the compound bridge condition is cumbersome. Action granularity: Several imports, declarations, assignments, control statements, and returns share lines, substantially reducing scanability. Reading flow: Logical execution order is undermined by inconsistent formatting, inline method bodies, and comments attached to closing braces. Consistent line breaks and indentation would materially improve readability without changing the design.

Run 2

Code Structure: A focused utility class with distinct methods and a callback interface provides logical organization. Nesting: Moderate nesting in loops, lambdas, conditionals, and try/catch blocks adds complexity without becoming excessive. Clarity of intent: Descriptive names and thorough Javadoc explain the purpose, though proxy handling and the compound bridge-method condition require careful reading. Code length: Implementation is reasonably concise; extensive documentation adds useful context rather than unnecessary logic. Action granularity: Several lines combine imports, declarations, conditionals, and multiple statements, obscuring individual actions. Reading flow: Inconsistent formatting, compressed method bodies, and comments attached to closing braces disrupt otherwise coherent control flow. Overall, clear design and documentation are undermined substantially by presentation.

Run 3

Code Structure: Cohesive utility class with logically separated selection methods and a callback interface, but compressed formatting obscures boundaries. Nesting: Moderate depth in the loop/lambda/conditional sequence and nested exception handling increases cognitive load. Clarity of intent: Descriptive method names, meaningful variables, and thorough Javadocs explain the purpose; the bridge-method condition is comparatively difficult to interpret. Code length: Implementation is reasonably concise for its functionality, although documentation occupies substantial space and the compound condition is lengthy. Action granularity: Several lines combine imports, declarations, branches, and multiple statements, undermining scanability. Reading flow: The conceptual progression is sensible, but inconsistent line breaks, inline braces, and comments attached to closing braces repeatedly interrupt natural reading.