Sample

int-7d989917dd33-I04

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

Matched original source

Lines197

Scores

MethodScoreScale
Posnett00–1; higher is more readable
Scalabrino0.7460–1; higher is more readable
Dorn0.0910–1; higher is more readable
Mi0.0510–1; higher is more readable
LLOC103Logical lines; fewer is more readable
DeepSeek V4 Pro3.670–20; mean of three runs
GPT-6.1 Sol9.330–20; mean of three runs
BTTF0.1390–1; higher is more readable

Views

Source code

package org.apache.kafka.common.security.ssl; import java.io.IOException; import java.util.ArrayList; import java.util.List; import java.util.Locale; import java.util.regex.Matcher; import java.util.regex.Pattern; import static org.apache.kafka.common.config.internals.BrokerSecurityConfigs.DEFAULT_SSL_PRINCIPAL_MAPPING_RULES; public class SslPrincipalMapper { private static final String RULE_PATTERN = "(DEFAULT)|RULE:((\\\\.|[^\\\\/])*)/((\\\\.|[^\\\\/])*)/([LU]?).*?|(.*?)"; private static final Pattern RULE_SPLITTER = Pattern.compile("\\s*(" + RULE_PATTERN + ")\\s*(,\\s*|$)"); private static final Pattern RULE_PARSER = Pattern.compile(RULE_PATTERN); private final List<Rule> rules; public SslPrincipalMapper(String a) { this.rules = c(b(a)); } public static SslPrincipalMapper a(String b) { return new SslPrincipalMapper(b); } private static List<String> b(String c) { if (c == null) { c = DEFAULT_SSL_PRINCIPAL_MAPPING_RULES; } List<String> d = new ArrayList<>(); Matcher e = RULE_SPLITTER.matcher(c.trim()); while (e.find()) { d.add(e.group(1)); } return d; } private static List<Rule> c(List<String> f) { List<Rule> g = new ArrayList<>(); for (String h : f) { Matcher i = RULE_PARSER.matcher(h); if (!i.lookingAt()) { throw new IllegalArgumentException("Invalid rule: " + h); } if (h.length() != i.end()) { throw new IllegalArgumentException("Invalid rule: `" + h + "`, unmatched substring: `" + h.substring(i.end()) + "`"); } // empty rules are ignored if (i.group(1) != null) { g.add(new Rule()); } else if (i.group(2) != null) { g.add(new Rule(i.group(2), i.group(4), "L".equals(i.group(6)), "U".equals(i.group(6)))); } } return g; } public String d(String j) throws IOException { for (Rule k : rules) { String l = k.apply(j); if (l != null) { return l; } } throw new NoMatchingRule("No rules apply to " + j + ", rules " + rules); } @Override public String e() { return "SslPrincipalMapper(rules = " + rules + ")"; } public static class NoMatchingRule extends IOException { NoMatchingRule(String n) { super(n); } } private static class Rule { private static final Pattern BACK_REFERENCE_PATTERN = Pattern.compile("\\$(\\d+)"); private final boolean isDefault; private final Pattern pattern; private final String replacement; private final boolean toLowerCase; private final boolean toUpperCase; Rule() { isDefault = true; pattern = null; replacement = null; toLowerCase = false; toUpperCase = false; } Rule(String o, String p, boolean q, boolean r) { isDefault = false; this.pattern = o == null ? null : Pattern.compile(o); this.replacement = p; this.toLowerCase = q; this.toUpperCase = r; } String a(String s) { if (isDefault) { return s; } String t = null; final Matcher m = pattern.matcher(s); if (m.matches()) { t = s.replaceAll(pattern.pattern(), b(replacement, m.groupCount())); } if (toLowerCase && t != null) { t = t.toLowerCase(Locale.ENGLISH); } else if (toUpperCase && t != null) { t = t.toUpperCase(Locale.ENGLISH); } return t; } //If we find a back reference that is not valid, then we will treat it as a literal string. For example, if we have 3 capturing //groups and the Replacement Value has the value is "$1@$4", then we want to treat the $4 as a literal "$4", rather //than attempting to use it as a back reference. //This method was taken from Apache Nifi project : org.apache.nifi.authorization.util.IdentityMappingUtil private String b(final String u, final int v) { if (v == 0) { return u; } String w = u; final Matcher x = BACK_REFERENCE_PATTERN.matcher(w); while (x.find()) { final String y = x.group(1); if (y.startsWith("0")) { continue; } int z = Integer.parseInt(y); // if we have a replacement value like $123, and we have less than 123 capturing groups, then // we want to truncate the 3 and use capturing group 12; if we have less than 12 capturing groups, // then we want to truncate the 2 and use capturing group 1; if we don't have a capturing group then // we want to truncate the 1 and get 0. while (z > v && z >= 10) { z /= 10; } if (z > v) { final StringBuilder A = new StringBuilder(w.length() + 1); final int B = x.start(1); A.append(w, 0, B - 1); A.append("\\"); A.append(w.substring(B - 1)); w = A.toString(); } } return w; } @Override public String c() { StringBuilder C = new StringBuilder(); if (isDefault) { C.append("DEFAULT"); } else { C.append("RULE:"); if (pattern != null) { C.append(pattern); } if (replacement != null) { C.append("/"); C.append(replacement); } if (toLowerCase) { C.append("/L"); } else if (toUpperCase) { C.append("/U"); } } return C.toString(); } } }

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.7707.779−254.357
Source linesThe number of non-empty source lines.197+78.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.329−6.494

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

Score0.746

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.198−5.974
Indentation frequencyHow rapidly indentation changes from line to line.188+5.766
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.188−3.893
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.196.86+2.342
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.134.98−2.052
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.134.929+1.373
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.09+0.063

Intercept 0.07 + feature contributions = -2.306 (log-odds).
Score = sigmoid(-2.306) = 0.091.

Score0.051
Score103
Run 1

This code has severely degraded readability due to obfuscated naming. Single-letter variables (a, b, c, d, e, j, k, l, etc.) make it nearly impossible to discern intent without extensive tracing. Method names like a(), b(), c(), d(), e() are meaningless and violate clarity of intent. The code structure is logical (parsing, rule application), but the naming obscures it. Nesting is moderate, but some methods (like b() within Rule) are overly long with cryptic logic. Action granularity is mostly one action per line, but the dense regex and back-reference handling reduce comprehension. Reading flow is impeded by the need to constantly map letters to their roles. While the original code may have been reasonably structured, this obfuscation drops it to the low end of the readability scale.

Run 2

The code is highly obfuscated and unreadable. Method and variable names are reduced to single letters (a, b, c, d, e, j, k, l, s, t, u, v, w, x, y, z, A, B, C), making intent completely unclear. The double-nested loop in method 'b' with obscure back-reference handling is difficult to follow. Action granularity is poor—multiple operations are chained or embedded. The regex patterns are complex and unexplained. The method 'a' inside Rule handles matching, replacement, and case conversion in one block. Comments explain only one method, leaving the rest ambiguous. Reading flow is unnatural due to the arbitrary method ordering and cryptic names. While the structure is logically segmented into classes, the obfuscation defeats readability. This code would be nearly impossible to maintain without external documentation.

Run 3

This code is extremely difficult to read due to single-letter variable and method names throughout (a, b, c, d, e, j, k, l, etc.), which obscure all intent. The regex pattern for rules is highly complex and uncommented. While the structure follows a logical flow and nesting is moderate, the naming completely defeats clarity. The obfuscated names appear to be a deliberate renaming (likely from decompiled or de-identified code), making it impossible to understand purpose without significant effort. Comments exist for the back-reference logic, but the surrounding code remains unintelligible. Length is reasonable, but granularity and reading flow are severely degraded by meaningless identifiers. Even though the class structure itself is coherent (parsing, mapping, applying rules), the lack of descriptive names makes the code effectively unreadable.

Run 1

Code Structure: Responsibilities are reasonably separated into rule splitting, parsing, mapping, and a nested Rule class. Nesting: Mostly shallow, with moderate nesting in back-reference handling. Clarity of intent: Severely weakened by single-letter method and variable names, dense regexes, and unexplained capture-group indices; descriptive fields and comments partially compensate. The call to k.apply conflicts with Rule's method a, and renamed methods marked @Override further confuse intent. Code length: Generally proportional to functionality, although verbose comments and repetitive string-building add bulk. Action granularity: Most lines perform one action, making individual operations easy to follow. Reading flow: Method ordering and early returns provide a logical progression, but opaque identifiers force repeated cross-referencing, while inconsistent spacing and alignment interrupt scanning.

Run 2

Code Structure: Responsibilities are reasonably separated into rule splitting, parsing, mapping, and a nested Rule class. Nesting: Mostly shallow, although back-reference handling adds nested loops and conditionals. Clarity of intent: Severely weakened by single-letter method and variable names, opaque regex capture-group indices, and inconsistencies such as calling apply when the method is named a and annotating e/c with @Override. Descriptive fields and explanatory comments partly compensate. Code length: Generally appropriate for the functionality, but verbose comments and repetitive string-building add bulk. Action granularity: Most lines perform one action, making individual operations easy to follow. Reading flow: The overall progression is logical, but cryptic naming, dense regex literals, uneven formatting, and mismatched method names force readers to repeatedly infer relationships.

Run 3

Code Structure: Responsibilities are reasonably separated into rule splitting, parsing, mapping, and a nested Rule class, but inconsistent method references undermine coherence. Nesting: Mostly shallow, with moderate nesting in back-reference handling and rule formatting. Clarity of intent: Single-letter method and variable names obscure purpose; complex regexes and numbered capture groups require substantial interpretation. Comments and descriptive fields provide some guidance. The call to k.apply lacks a corresponding method, and renamed methods incorrectly retain @Override, further confusing intent. Code length: Generally proportionate to the task, though verbose comments and repeated string-building operations add bulk. Action granularity: Most lines perform one action, making individual operations easy to scan. Reading flow: The overall progression is logical, but cryptic naming, inconsistent indentation, and unexplained regex structure interrupt comprehension.