Sample
int-6dc8bb7d137c-I04
Replace method, parameter, and local names with deterministic ProGuard-style short identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Scalabrino | 0.811 | 0–1; higher is more readable |
| Dorn | 0.164 | 0–1; higher is more readable |
| Mi | 0.291 | 0–1; higher is more readable |
| LLOC | 29 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 2.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 11.33 | 0–20; mean of three runs |
| BTTF | 0.504 | 0–1; higher is more readable |
Views
Loading feature diagnosis…
Source regions
Feature contributions
Feature contributions
| Feature | Value | Contribution (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. | 5661.452 | −186.828 |
| Source linesThe number of non-empty source lines. | 178 | +71.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.617 | −6.925 |
Intercept 8.87 + feature contributions = -113.683 (log-odds).
Score = sigmoid(-113.683) = 0.
| Score | 0.811 |
|---|
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 178 | −5.266 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 139 | +4.071 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 139 | −2.769 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 177.923 | +2.077 |
| 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. | 115.978 | −1.247 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 113.402 | +1.025 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.411 |
Intercept 0.07 + feature contributions = -1.628 (log-odds).
Score = sigmoid(-1.628) = 0.164.
| Score | 0.291 |
|---|
| Score | 29 |
|---|
Run 1
This code is functionally Netty's NioEventLoopGroup but has been deliberately obfuscated by renaming parameters to meaningless sequence letters (a, b, c... A, B, C...) and methods to single letters (a(), b(), c()). This destroys clarity of intent and reading flow. The constructor overloading is excessive (9 constructors), creating repetitive code, though some repetition is typical for Netty-style builder classes. Nesting is shallow, and action granularity is mostly one action per line, but these are undermined by the naming. JavaDoc remains for original parameter names, creating a mismatch with the code. The structure is logical but the obfuscation makes it extremely hard to follow.
Run 2
This code is severely degraded by deliberate obfuscation. Variable names (a, b, c... A, B, C...) are meaningless single letters, destroying readability. Method names like a(), b(), c() obscure intent entirely. The code has reasonable structure and flat nesting, but clarity, intent, and natural reading flow are critically compromised. The parameter Javadoc lists meaningful names that do not match the actual parameters, adding confusion. Constructor chaining is logical but hard to follow due to naming. Overall, the code is technically valid but practically unreadable.
Run 3
This code is extremely unreadable. Variable names are single letters (a, b, c, A, B, X...) providing zero semantic value, completely violating clarity of intent. The method names a(), b(), c() are meaningless. There is deep constructor chaining with 8 overloaded constructors, creating tangled and hard-to-follow code. The 'a' method receives an unexplained int parameter only to log a no-op message - extremely confusing. Parameter names are sequential alphabet letters with no meaning (N, O, P, Q...). The 'c' method has magic array indexing (Y[0], Y[1], Y[2]) to extract arguments from Object varargs - a severe anti-pattern that obscures intent and type safety. Action granularity is poor as multiple concepts are packed into single lines. Reading flow is completely unnatural. This appears to be deliberately obfuscated code that renders a potentially simple event loop group wrapper nearly incomprehensible.
Run 1
Code Structure: Logically organized into constructors and event-loop operations, with consistent delegation rather than tangled logic. Nesting: Very shallow; only a loop and simple conditionals. Clarity of intent: Severely weakened by single-letter parameter, variable, and method names. Types and comments provide context, but Javadoc parameter names do not match the signatures. Code length: Numerous constructor overloads and repetitive documentation make the class lengthy, although individual implementations are concise. Action granularity: Generally one statement per line, with straightforward assignments and calls. Reading flow: Constructor grouping and whitespace help, but inconsistent wrapping, long argument lists, cryptic identifiers, and positional Object-varargs casts require repeated cross-referencing. Overall, clean control flow is substantially undermined by poor naming.
Run 2
Code Structure: Constructors are logically grouped and delegate consistently, followed by operational methods, but extensive overloads add repetition. Nesting: Very shallow; only a loop and two independent conditionals make control flow easy to follow. Clarity of intent: Class documentation and descriptive types help, but single-letter parameter names and methods a, b, and c obscure responsibilities. Javadoc parameter names do not match the actual signature, further reducing clarity. Code length: Individual methods are concise, but repeated constructor boilerplate and similar documentation make the class lengthy to scan. Action granularity: Most statements perform one action per line; wrapped constructor calls remain understandable. Reading flow: Constructor delegation provides a predictable progression, but inconsistent wrapping, opaque identifiers, and positional Object-varargs extraction interrupt natural reading and require readers to infer argument roles.
Run 3
Code Structure: Constructors are grouped logically and delegate consistently, followed by operational methods, but numerous overloads add repetition. Nesting: Very shallow; the loop and conditionals are straightforward. Clarity of intent: Types, documentation, and library calls convey purpose, but single-letter parameter names and methods a, b, and c obscure meaning. Javadoc parameter names do not match the actual signature, further reducing clarity. Code length: Individual methods are concise, though repeated constructors and documentation make the class lengthy to scan. Action granularity: Statements generally perform one action each, with clear separation of assignments, checks, and calls. Reading flow: Constructor delegation and linear control flow are natural, but inconsistent wrapping, opaque identifiers, and positional Object varargs require readers to infer roles and trace arguments.