Sample
int-a9199a0cb874-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.634 | 0–1; higher is more readable |
| Dorn | 0.091 | 0–1; higher is more readable |
| Mi | 0.119 | 0–1; higher is more readable |
| LLOC | 50 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10.67 | 0–20; mean of three runs |
| BTTF | 0.233 | 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. | 8352.302 | −275.626 |
| Source linesThe number of non-empty source lines. | 162 | +64.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.722 | −7.083 |
Intercept 8.87 + feature contributions = -209.039 (log-odds).
Score = sigmoid(-209.039) = 0.
| Score | 0.634 |
|---|
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. | 163 | −4.735 |
| 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 (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names. | 143.988 | −2.434 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 161.972 | +1.854 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 143.11 | +1.505 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.082 | +0.141 |
Intercept 0.07 + feature contributions = -2.297 (log-odds).
Score = sigmoid(-2.297) = 0.091.
| Score | 0.119 |
|---|
| Score | 50 |
|---|
Run 1
This code is heavily obfuscated with single-letter variable names (a, b, c, d, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A), method names (a(), b(), c(), d(), e(), f()), and parameters, making it nearly impossible to understand intent without deep analysis. The structure is disorganized: method `b()` mixes looping, connector creation, error handling, and callback logic with unclear control flow. Nesting is moderate but made worse by ambiguous variable names. Clarity of intent is extremely low—names give no semantic hints, and even the Javadoc refers to `c(String k)` in an unhelpful way. Code length is somewhat verbose, but the real issue is abstraction abuse: single-letter identifiers destroy readability. Action granularity is acceptable (one primary operation per line), but reading flow is unnatural and disorienting. A maintainer would struggle to trace data flow or purpose without renaming everything.
Run 2
The code suffers from severe readability issues. Function and variable names are meaningless single characters (a, b, c, d, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x, y, z, A), obscuring all intent. The parsing logic is moderately nested with multiple try-catch blocks and conditionals, but the naming destroys readability. Actions are mostly one per line, but the flow is impossible to follow without comments due to obfuscated identifiers. Import organization is logical and javadoc is clear, but these cannot compensate for the catastrophic loss of semantic information in identifiers.
Run 3
This code is effectively unreadable due to systematic obfuscation. Identifiers are meaningless across many variables and methods: the main class is 'ConnectStandalone' but has public methods like 'a()', 'b()', 'c()', 'd()', 'e()', and 'f()'. Local variables are mostly single letters like 'b', 'c', 'd', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z', 'A'. This destroys clarity of intent, reading flow, and code structure. Nesting is moderate but hidden within meaningless variable names. Action granularity is acceptable in places, but the cost of decoding variable names makes every line hard. Code length is normal, but the intentionally cryptic naming makes even simple logic ambiguous, requiring constant reverse-engineering of identifiers.
Run 1
Code Structure: Separate methods organize startup, configuration parsing, and worker construction logically. Nesting: Mostly shallow, with moderate nesting in connector creation and configuration validation. Clarity of intent: Single-letter method and variable names severely obscure roles and force readers to infer meaning from types and calls; documentation and descriptive library APIs partially compensate. Code length: Generally reasonable, though repeated mandatory-name validation and lengthy imports add overhead. Action granularity: Most statements perform one action per line, with conventional multiline calls; chained expressions require some additional interpretation. Reading flow: Sequential parsing fallbacks and consistent indentation provide a coherent flow, but opaque identifiers, missing import-group spacing, and documentation referring to a parameter name not used in the signature interrupt comprehension.
Run 2
Code Structure: Responsibilities are separated into methods, and configuration parsing follows clearly defined fallback stages. Nesting: Mostly moderate, though the connector loop, callback, and nested name-validation condition add complexity. Clarity of intent: The main weakness is pervasive single-letter method and variable names, which obscure roles and require readers to infer meaning from types and calls. Documentation, API names, and log messages partially compensate; the filePath documentation does not match parameter k. Code length: Reasonably concise for its functionality, with some repeated mandatory-name validation. Action granularity: Generally one statement per line, with readable formatting for longer calls. Reading flow: Startup, parsing, and component construction are coherent locally, but opaque identifiers, tightly packed imports, and inconsistent wrapping interrupt comprehension.
Run 3
Code Structure: Responsibilities are separated into methods, and configuration parsing follows a logical fallback sequence. Nesting: Mostly shallow, with moderate nesting in connector creation and configuration validation. Clarity of intent: Single-letter method and variable names severely obscure purpose; descriptive types, logging, and documentation partially compensate. The documented filePath parameter also differs from the actual parameter name. Code length: Reasonably concise for its responsibilities, although mandatory-name validation is duplicated and imports are visually dense. Action granularity: Most statements perform one action per line, with conventional multiline calls; some chained expressions require extra attention. Reading flow: Startup, parsing, and worker construction are internally coherent, but opaque identifiers force repeated cross-referencing, and inconsistent spacing and wrapping interrupt scanning.