Sample
pyint-f07c5c591d9c-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.722 | 0–1; higher is more readable |
| Mi | 0.608 | 0–1; higher is more readable |
| LLOC | 145 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 2.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 10 | 0–20; mean of three runs |
| BTTF | 0.142 | 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. | 9090.297 | −299.98 |
| Source linesThe number of non-empty source lines. | 298 | +119.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.385 | −6.577 |
Intercept 8.87 + feature contributions = -178.487 (log-odds).
Score = sigmoid(-178.487) = 0.
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. | 299 | −9.55 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 198 | +6.111 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 297.941 | +3.755 |
| 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. | 117.97 | −1.332 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 117.973 | +1.099 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.055 | +0.404 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
Intercept 0.07 + feature contributions = 0.956 (log-odds).
Score = sigmoid(0.956) = 0.722.
| Score | 0.608 |
|---|
| Score | 145 |
|---|
Run 1
The code is extremely difficult to read due to pervasive obfuscation. Method names are single letters (a, b, q) replacing descriptive names like get, set, or get_dict. Parameter names are arbitrary (t, u, v, w, K, L, aa) rather than meaningful (name, domain, path, value). Local variables are also single letters (A, B, C, ag, ah). This destroys clarity of intent and reading flow. The structure and nesting are not inherently tangled, and methods generally do one action per line, but the cryptographic naming makes every line require reverse-engineering. Even docstrings, while present, cannot compensate because the code itself is unreadable without constant mental mapping. The use of comments like 'we will eventually return this as long as no cookie conflict' adds minor clarity, but the overall effect is overwhelmingly negative for maintainability and collaboration.
Run 2
The code is severely unreadable due to deliberate obfuscation. Method names are reduced to meaningless single letters (a, b, q, n, etc.), and all local variables follow the same pattern (A-Z, aa-aj). This destroys clarity of intent, making it impossible to understand what each method does without reading its docstring. While the underlying structure is similar to the original RequestsCookieJar, the renaming removes semantic meaning. Nesting and structure are moderate, inherited from the original code, but action granularity and reading flow are undermined by opaque identifiers. Code length is reasonable, but the obfuscation renders it unreadable.
Run 3
The code is severely unreadable due to deliberate obfuscation. All method and parameter names are meaningless single letters (a, b, t, u, v, z, A, B), obliterating clarity of intent. Action granularity and reading flow are destroyed because readers must constantly map cryptic symbols to their documented purposes. While the original structure—imports, class docstring, grouped methods—exists, the renaming makes it feel tangled. Nesting is moderate but harder to follow when conditions use opaque variables. Code length is concise line-wise, but each line demands heavy cognitive lookup. The informative docstrings are the only saving grace, providing a partial decoding key, but code comprehension still requires constant cross-referencing. This is effectively unreadable in practice despite a reasonable underlying layout.
Run 1
Code Structure: Methods are logically separated within a cohesive cookie-jar class, with useful docstrings and type annotations. Nesting: Most methods are shallow, but p and q contain three to four nested conditions that complicate lookup logic. Clarity of intent: Single-letter method names and arbitrary variable names severely obscure purpose; docstrings help, but reference original names that no longer match the code. Code length: Individual methods are generally concise, although repetitive wrappers and lengthy documentation increase the reading burden. Action granularity: Statements mostly perform one action per line; the assignment expression in n slightly combines operations. Reading flow: Consistent formatting and method grouping help, but opaque cross-method calls, mismatched documentation, and irregular import ordering interrupt natural comprehension.
Run 2
Code Structure: Methods are logically separated within a cohesive cookie-jar class, although import organization is inconsistent. Nesting: Most methods are shallow, but cookie lookup methods use three to four nested conditions that could be flattened. Clarity of intent: Type hints and detailed docstrings explain behavior, but opaque method and variable names severely obscure intent; documentation references meaningful names that no longer match the implementation. Code length: Individual methods are mostly concise, although repetitive wrappers and lengthy docstrings increase scanning effort. Action granularity: Statements generally perform one action per line, with few compressed expressions. Reading flow: Consistent formatting and grouping of related operations help, but tracing calls such as self.q(), self.n(), and self.s() requires repeatedly consulting definitions. Overall, sound structural organization is substantially undermined by pervasive non-descriptive naming.
Run 3
Code Structure: Methods are logically grouped within a single class, with clear separation of mapping operations, lookup, and serialization. Nesting: Most methods are shallow, but lookup methods p and q contain several nested conditions that impede scanning. Clarity of intent: Docstrings and type annotations explain functionality, but opaque method and variable names severely obscure intent; documentation also references names absent from the implementation. Code length: Individual methods are generally concise, although repetitive wrappers and lengthy docstrings increase overall reading effort. Action granularity: Most lines perform one action; the assignment expression in n slightly increases cognitive load. Reading flow: Consistent formatting and familiar special methods help, but deciphering letter-based identifiers and translating cross-references repeatedly interrupts comprehension.