Sample

int-4d4c35bf9917-I04

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

Matched original source

Lines159

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.3740–1; higher is more readable
Dorn0.1790–1; higher is more readable
Mi0.1710–1; higher is more readable
LLOC49Logical lines; fewer is more readable
DeepSeek V4 Pro3.330–20; mean of three runs
GPT-6.1 Sol100–20; mean of three runs
BTTF0.2440–1; higher is more readable

Views

Source code

package org.springframework.test.context.bean.override.convention; import java.lang.annotation.Annotation; import java.lang.reflect.Field; import java.lang.reflect.Method; import java.lang.reflect.Modifier; import java.util.ArrayList; import java.util.Collection; import java.util.LinkedHashSet; import java.util.List; import java.util.Set; import java.util.stream.Collectors; import org.springframework.core.MethodIntrospector; import org.springframework.core.ResolvableType; import org.springframework.test.context.TestContextAnnotationUtils; import org.springframework.test.context.bean.override.BeanOverrideProcessor; import org.springframework.test.context.bean.override.BeanOverrideStrategy; import org.springframework.util.Assert; import org.springframework.util.ClassUtils; import org.springframework.util.ReflectionUtils; import org.springframework.util.ReflectionUtils.MethodFilter; import static org.springframework.test.context.bean.override.BeanOverrideStrategy.REPLACE; import static org.springframework.test.context.bean.override.BeanOverrideStrategy.REPLACE_OR_CREATE; /** * {@link BeanOverrideProcessor} implementation for {@link TestBean @TestBean} * support, which creates a {@link TestBeanOverrideHandler} for annotated * fields in a given class and ensures that a corresponding static factory method * exists, according to the {@linkplain TestBean documented conventions}. * * @author Simon Baslé * @author Sam Brannen * @author Stephane Nicoll * @since 6.2 */ class TestBeanOverrideProcessor implements BeanOverrideProcessor { @Override public TestBeanOverrideHandler a(Annotation a, Class<?> b, Field c) { if (!(a instanceof TestBean testBean)) { throw new IllegalStateException("Invalid annotation passed to %s: expected @TestBean on field %s.%s" .formatted(getClass().getSimpleName(), c.getDeclaringClass().getName(), c.getName())); } String d = (!testBean.name().isBlank() ? testBean.name() : null); String e = testBean.methodName(); BeanOverrideStrategy f = (testBean.enforceOverride() ? REPLACE : REPLACE_OR_CREATE); Method g; if (!e.isBlank()) { // If the user specified an explicit method name, search for that. g = b(c.getDeclaringClass(), c.getType(), e); } else { // Otherwise, search for candidate factory methods whose names match either // the field name or the explicit bean name (if any). List<String> h = new ArrayList<>(); h.add(c.getName()); if (d != null) { h.add(d); } g = b(c.getDeclaringClass(), c.getType(), h); } return new TestBeanOverrideHandler( c, ResolvableType.forField(c, b), d, testBean.contextName(), f, g); } /** * Find a test bean factory {@link Method} for the given {@link Class}. * <p>Delegates to {@link #findTestBeanFactoryMethod(Class, Class, Collection)}. */ Method b(Class<?> i, Class<?> j, String... k) { return b(i, j, List.of(k)); } /** * Find a test bean factory {@link Method} for the given {@link Class}, which * meets the following criteria. * <ul> * <li>The method is static.</li> * <li>The method does not accept any arguments.</li> * <li>The method's return type matches the supplied {@code methodReturnType}.</li> * <li>The method's name is one of the supplied {@code methodNames}.</li> * </ul> * <p>This method traverses up the type hierarchy of the given class in search * of the factory method, beginning with the class itself and then searching * implemented interfaces and superclasses. If a factory method is not found * in the type hierarchy, this method will also search the enclosing class * hierarchy if the class is a nested class. * <p>If multiple factory methods are found that match the search criteria, * an exception is thrown. * @param clazz the class in which to search for the factory method * @param methodReturnType the return type for the factory method * @param methodNames a set of supported names for the factory method * @return the corresponding factory method * @throws IllegalStateException if a matching factory method cannot * be found or multiple methods match */ Method b(Class<?> l, Class<?> m, Collection<String> n) { Assert.notEmpty(n, "At least one candidate method name is required"); Set<Method> o = new LinkedHashSet<>(); Set<String> p = new LinkedHashSet<>(n); // Process fully-qualified method names first. for (String q : n) { int r = q.lastIndexOf('#'); if (r != -1) { String s = q.substring(0, r).trim(); Assert.hasText(s, () -> "No class name present in fully-qualified method name: " + q); String t = q.substring(r + 1).trim(); Assert.hasText(t, () -> "No method name present in fully-qualified method name: " + q); Class<?> u; try { u = ClassUtils.forName(s, getClass().getClassLoader()); } catch (ClassNotFoundException | LinkageError v) { throw new IllegalStateException( "Failed to load class for fully-qualified method name: " + q, v); } Method w = ReflectionUtils.findMethod(u, t); Assert.state(w != null && Modifier.isStatic(w.getModifiers()) && m.isAssignableFrom(w.getReturnType()), () -> "No static method found named %s in %s with return type %s".formatted( t, s, m.getName())); o.add(w); p.remove(q); } } Set<String> x = new LinkedHashSet<>(p); MethodFilter y = method -> (Modifier.isStatic(method.getModifiers()) && x.contains(method.getName()) && m.isAssignableFrom(method.getReturnType())); c(o, l, y); String z = x.stream() .map(name -> name + "()").collect(Collectors.joining(" or ")); Assert.state(!o.isEmpty(), () -> "No static method found named %s in %s with return type %s".formatted( z, l.getName(), m.getName())); long A = o.stream().map(Method::getName).distinct().count(); Assert.state(A == 1, () -> "Found %d competing static methods named %s in %s with return type %s".formatted( A, z, l.getName(), m.getName())); return o.iterator().next(); } private static Set<Method> c(Set<Method> B, Class<?> C, MethodFilter D) { B.addAll(MethodIntrospector.selectMethods(C, D)); if (B.isEmpty() && TestContextAnnotationUtils.searchEnclosingClass(C)) { c(B, C.getEnclosingClass(), D); } return B; } }

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.7696.915−253.998
Source linesThe number of non-empty source lines.159+63.6
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.5.088−7.632

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

Score0.374

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.160−4.629
Indentation frequencyHow rapidly indentation changes from line to line.120+3.414
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.120−2.333
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.158.923+1.812
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.102.956+0.857
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.102.944−0.695
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.099−0.018

Intercept 0.07 + feature contributions = -1.522 (log-odds).
Score = sigmoid(-1.522) = 0.179.

Score0.171
Score49
Run 1

This code is heavily obfuscated with single-letter variable names (a, b, c, d, etc.) that completely obscure a method's purpose. While the structure itself is somewhat logical, the naming destroys clarity of intent, forcing the reader to constantly backtrack to decipher what each variable represents. The method overloads use identical names (b, c), making it impossible to distinguish their roles without reading the entire body. Reading flow is unnatural because concepts like 'testBean', 'field', 'methodName', and 'strategy' are replaced with meaningless letters. Nesting is moderate, but action granularity is sometimes violated by combining operations in one line. The only saving grace is the Javadoc on one method and consistent formatting, but that does not compensate for the unreadable symbolic naming throughout.

Run 2

This code is extremely unreadable due to deliberate obfuscation. All meaningful variable and method names have been replaced with single letters (a, b, c, d, etc.), which completely obscures intent. The method name 'a' is used for the main processor method, 'b' for factory method lookup, and 'c' for recursive traversal—none convey purpose. The code is deeply nested with multiple conditional branches and loops, violating the nesting criterion. Multiple operations per line (e.g., string substring with trim and assertion) break action granularity. While the logic appears structured, the single-letter naming makes it impossible to follow without constant mental mapping. The only readable parts are the Javadoc comments, which hint at original intent, but they cannot compensate for the obfuscated code. This appears intentionally degraded for testing evaluation.

Run 3

The code's structure and comments are coherent, but readability is severely undermined by meaningless variable names (a, b, c, d, e, f, g, etc.) used throughout methods, parameters, and local scopes. This obscures intent and forces the reader to infer types and roles. Method overloading with single-letter names like b() and c() adds confusion. Although nesting is moderate and actions are mostly one per line, the naming turns every expression into a puzzle. The original method names and parameters were clearly renamed, which destroys clarity despite logical organization and helpful Javadoc.

Run 1

Code Structure: Responsibilities are sensibly separated into handler creation, factory-method lookup, and recursive enclosing-class search. Nesting: Generally moderate, though the fully qualified name loop combines conditionals and exception handling. Clarity of intent: Single-letter method and variable names severely obscure roles and require constant tracing; descriptive API calls, comments, and error messages partially compensate. Documentation references original method and parameter names that no longer match the code, adding confusion. Code length: Reasonably concise for the reflection and validation involved, although documentation occupies substantial space. Action granularity: Most lines perform one operation, with some dense predicates and chained expressions. Reading flow: Processing follows a logical sequence from annotation validation through candidate discovery to final selection, but opaque names and multiline assertions repeatedly interrupt comprehension.

Run 2

Code Structure: Responsibilities are separated into annotation processing, factory-method lookup, and recursive enclosing-class search, though the main lookup method handles several concerns. Nesting: Generally moderate, with a loop containing conditionals and try/catch; recursion is compact. Clarity of intent: Single-letter method and variable names severely obscure roles and require repeated cross-referencing. Comments and error messages help, but Javadoc references and parameter names no longer match the code. Code length: Mostly justified by validation and reflection logic, although lengthy documentation contrasts with opaque implementation names. Action granularity: Most lines perform one action; compound predicates and chained stream operations remain reasonably formatted. Reading flow: Execution follows a logical progression from validation through discovery to selection, but cryptic identifiers and inconsistent documentation interrupt comprehension.

Run 3

Code Structure: Responsibilities are sensibly separated into handler creation, factory-method lookup, and recursive class searching, although the main lookup method is relatively dense. Nesting: Mostly shallow, with manageable loops, conditionals, and one try/catch. Clarity of intent: Single-letter method and variable names severely obscure roles and require repeated tracing; descriptive comments, types, and error messages partially compensate. Javadoc references and parameter names do not match the renamed methods and parameters, further reducing clarity. Code length: Implementation is reasonably concise for its functionality, though documentation is extensive relative to the code. Action granularity: Generally one statement per line, with some compound predicates and chained stream operations that demand closer attention. Reading flow: The overall progression is logical, but cryptic identifiers, wrapped assertions, and sparse separation around imports disrupt smooth reading.