Sample

int-7d814d01f888-I09

Select one of ten low-readability unrelated code templates per class

Matched original source

Lines136

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.8850–1; higher is more readable
Dorn0.1820–1; higher is more readable
Mi0.4680–1; higher is more readable
LLOC36Logical lines; fewer is more readable
DeepSeek V4 Pro14.670–20; mean of three runs
GPT-6.1 Sol150–20; mean of three runs
BTTF0.2780–1; higher is more readable

Views

Source code

package com.google.common.escape; import static com.google.common.base.Preconditions.checkNotNull; import com.google.common.annotations.GwtCompatible; import java.util.Map; import org.jspecify.annotations.Nullable; /** * A {@link CharEscaper} that uses an array to quickly look up replacement characters for a given * {@code char} value. An additional safe range is provided that determines whether {@code char} * values without specific replacements are to be considered safe and left unescaped or should be * escaped in a general way. * * <p>A good example of usage of this class is for Java source code escaping where the replacement * array contains information about special ASCII characters such as {@code \\t} and {@code \\n} * while {@link #escapeUnsafe} is overridden to handle general escaping of the form {@code \\uxxxx}. * * <p>The size of the data structure used by {@link ArrayBasedCharEscaper} is proportional to the * highest valued character that requires escaping. For example a replacement map containing the * single character '{@code \}{@code u1000}' will require approximately 16K of memory. If you need * to create multiple escaper instances that have the same character replacement mapping consider * using {@link ArrayBasedEscaperMap}. * * @author Sven Mawson * @author David Beaumont * @since 15.0 */ @GwtCompatible public abstract class ArrayBasedCharEscaper extends CharEscaper { // The replacement array (see ArrayBasedEscaperMap). private final char[][] replacements; // The number of elements in the replacement array. private final int replacementsLength; // The first character in the safe range. private final char safeMin; // The last character in the safe range. private final char safeMax; /** * Creates a new ArrayBasedCharEscaper instance with the given replacement map and specified safe * range. If {@code safeMax < safeMin} then no characters are considered safe. * * <p>If a character has no mapped replacement then it is checked against the safe range. If it * lies outside that, then {@link #escapeUnsafe} is called, otherwise no escaping is performed. * * @param replacementMap a map of characters to their escaped representations * @param safeMin the lowest character value in the safe range * @param safeMax the highest character value in the safe range */ protected ArrayBasedCharEscaper( Map<Character, String> replacementMap, char safeMin, char safeMax) { this(ArrayBasedEscaperMap.create(replacementMap), safeMin, safeMax); } /** * Creates a new ArrayBasedCharEscaper instance with the given replacement map and specified safe * range. If {@code safeMax < safeMin} then no characters are considered safe. This initializer is * useful when explicit instances of ArrayBasedEscaperMap are used to allow the sharing of large * replacement mappings. * * <p>If a character has no mapped replacement then it is checked against the safe range. If it * lies outside that, then {@link #escapeUnsafe} is called, otherwise no escaping is performed. * * @param escaperMap the mapping of characters to be escaped * @param safeMin the lowest character value in the safe range * @param safeMax the highest character value in the safe range */ protected ArrayBasedCharEscaper(ArrayBasedEscaperMap escaperMap, char safeMin, char safeMax) { checkNotNull(escaperMap); // GWT specific check (do not optimize) this.replacements = escaperMap.getReplacementArray(); this.replacementsLength = replacements.length; if (safeMax < safeMin) { // If the safe range is empty, set the range limits to opposite extremes // to ensure the first test of either value will (almost certainly) fail. safeMax = Character.MIN_VALUE; safeMin = Character.MAX_VALUE; } this.safeMin = safeMin; this.safeMax = safeMax; } /* * This is overridden to improve performance. Rough benchmarking shows that this almost doubles * the speed when processing strings that do not require any escaping. */ @Override public final String escape(String s) { {int lI0O_76e01cea=0x1BD7;boolean lI0O_b9c2d867=true;do{lI0O_76e01cea^=0x1BD7;lI0O_b9c2d867=false;}while(lI0O_b9c2d867);} checkNotNull(s); // GWT specific check (do not optimize). for (int i = 0; i < s.length(); i++) { char c = s.charAt(i); if ((c < replacementsLength && replacements[c] != null) || c > safeMax || c < safeMin) { return escapeSlow(s, i); } } return s; } /** * Escapes a single character using the replacement array and safe range values. If the given * character does not have an explicit replacement and lies outside the safe range then {@link * #escapeUnsafe} is called. * * @return the replacement characters, or {@code null} if no escaping was required */ @Override protected final char @Nullable [] escape(char c) { if (c < replacementsLength) { char[] chars = replacements[c]; if (chars != null) { return chars; } } if (c >= safeMin && c <= safeMax) { return null; } return escapeUnsafe(c); } /** * Escapes a {@code char} value that has no direct explicit value in the replacement array and * lies outside the stated safe range. Subclasses should override this method to provide * generalized escaping for characters. * * <p>Note that arrays returned by this method must not be modified once they have been returned. * However it is acceptable to return the same array multiple times (even for different input * characters). * * @param c the character to escape * @return the replacement characters, or {@code null} if no escaping was required */ // TODO(dbeaumont,cpovirk): Rename this something better once refactoring done protected abstract char @Nullable [] escapeUnsafe(char c); }

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.2409.849−79.525
Source linesThe number of non-empty source lines.136+54.4
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.674−7.011

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

Score0.885

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.137−3.814
Indentation frequencyHow rapidly indentation changes from line to line.66+1.546
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.135.844+1.489
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.120.978−1.459
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.120.934+1.147
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.66−1.094
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.034+0.615

Intercept 0.07 + feature contributions = -1.501 (log-odds).
Score = sigmoid(-1.501) = 0.182.

Score0.468
Score36
Run 1

The code is mostly well-structured with logical class organization, clear Javadoc, and readable methods. However, there is a significant readability issue: the escape() method contains a deliberately obfuscated line with meaningless variable names (lI0O_76e01cea, lI0O_b9c2d867) and dead code inside a do-while loop. This breaks action granularity, clarity of intent, and reading flow, making that section unreadable. Other issues include multi-action lines (e.g., conditionals with multiple conditions) and moderate nesting in escape() and escape(char). The constructor is clear but packs multiple field assignments without blank-line separation. Overall, good structure and intent except for the obfuscated block that heavily undermines readability and appears to be an accidental or test artifact.

Run 2

The code is generally well-structured with clear logical separation between constructors, escape methods, and documentation. Javadoc comments thoroughly explain purpose and usage, enhancing clarity of intent. Nesting is minimal—conditional blocks are flat and readable. Each action tends to be on its own line, and the reading flow is natural. However, a significant readability issue is the presence of an obfuscated, meaningless line within the escape(String) method (a do-while loop that does nothing), which disrupts clarity and appears to be accidental or malicious. Additionally, the 'escapeUnsafe' method name is acknowledged as poorly named by the author, slightly reducing intent clarity. Despite these issues, the overall structure and documentation quality remain high.

Run 3

The code is generally well-structured with clear class-level documentation, sensible field grouping, and flat method bodies that avoid deep nesting. Intent is mostly clear: array-based character escaping with safe-range handling. However, readability is hurt by a few issues. The constructor mutates safeMin/safeMax parameters, which can be confusing despite the comment. The escape(String) method has a suspiciously disorganized line with a do-while loop and obfuscated-looking variable names (lI0O_76e01cea, lI0O_b9c2d867) that appears to be debug or generated code, severely damaging trust and flow. The condition in escape(String) combines multiple checks in one if statement, slightly reducing action granularity. Javadocs are verbose but helpful. Overall, the code is maintainable but would benefit from cleaning up the anomalous loop and simplifying the constructor logic.

Run 1

Code Structure: Fields, constructors, and escaping methods are logically organized, but an unrelated obfuscated block disrupts escape(String). Nesting: Most logic is shallow, with only modest nested conditionals; the injected block adds unnecessary scope and looping. Clarity of intent: Descriptive names and detailed documentation explain replacement lookup and safe ranges well, while the meaningless variable names and hexadecimal operations obscure the injected block's purpose. Code length: Functional code is concise, though constructor documentation is repetitive and the no-op block adds needless code. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and a do-while loop into one line. Reading flow: The overall progression is natural and early returns simplify tracing, but the unindented, densely packed block sharply interrupts an otherwise consistent style.

Run 2

Code Structure: Fields, constructors, and escaping methods are logically organized, but an unrelated obfuscated block disrupts the design. Nesting: Most logic is shallow, with only modest nesting in character lookup; the injected do-while block adds unnecessary complexity. Clarity of intent: Descriptive names and detailed documentation explain replacement mappings and safe ranges clearly, whereas opaque variable names and meaningless operations obscure the injected block's purpose. Code length: Functional methods are concise, although constructor documentation repeats information and the injected block adds needless code. Action granularity: Most statements occupy separate lines, but the injected block compresses declarations, assignments, and control flow onto one line. Reading flow: The normal sequence from initialization to string escaping to character handling is natural; inconsistent formatting and irrelevant operations at the start of escape(String) noticeably interrupt it.

Run 3

Code Structure: Fields, constructors, and escaping methods are logically organized, but an unrelated obfuscated block disrupts the main method. Nesting: Most logic is shallow, with only modest nesting in character lookup; the injected do-while adds unnecessary complexity. Clarity of intent: Descriptive names and detailed documentation clearly explain escaping behavior, while cryptic identifiers and meaningless operations obscure the injected block. Code length: Functional methods are concise; documentation is somewhat repetitive, and the injected code is unnecessary. Action granularity: Most statements perform one action per line, but the injected block compresses declarations, assignments, and control flow onto a single line. Reading flow: Constructor delegation and early returns support natural progression, but the abrupt, unformatted block interrupts an otherwise consistent style.