Sample
pyint-7490bdc299c4-I04
Replace names with deterministic minifier-style shortest identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.022 | 0–1; higher is more readable |
| Mi | 0.802 | 0–1; higher is more readable |
| LLOC | 188 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 8.67 | 0–20; mean of three runs |
| BTTF | 0.212 | 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. | 16134.97 | −532.454 |
| Source linesThe number of non-empty source lines. | 461 | +184.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.082 | −6.123 |
Intercept 8.87 + feature contributions = -345.307 (log-odds).
Score = sigmoid(-345.307) = 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. | 462 | −15.322 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 418 | +13.721 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 418 | −9.171 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 460.875 | +6.032 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.177 | +0.586 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.063 | +0.328 |
| 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. | 86.974 | −0.019 |
Intercept 0.07 + feature contributions = -3.774 (log-odds).
Score = sigmoid(-3.774) = 0.022.
| Score | 0.802 |
|---|
| Score | 188 |
|---|
Run 1
This code is severely unreadable due to systematic obfuscation of all identifiers. Variables are renamed to meaningless single letters (B, C, D, E, F...) and methods to single letters (a, b, c, d...), completely destroying clarity of intent. The original Django ForeignObject code is well-structured, but this obfuscated version makes it impossible to understand what parameters like 'B' or 'C' represent (presumably to, on_delete, from_fields, to_fields). Method names like 'd()' or 'e()' give no indication of their purpose (checking composite primary keys, unique constraints). Complex list comprehensions and generator expressions combined with meaningless variable names (like 'aa' for unique constraints) make the code impenetrable. The nesting and code length are reasonable, but the complete lack of semantic meaning in identifiers makes this code effectively unreadable. Even with expert Django knowledge, mapping obfuscated names to their intended meaning requires significant effort. The imports remain readable, but the core logic is incomprehensible without a lookup table for what each single-letter identifier represents.
Run 2
This code is extremely unreadable due to pervasive obfuscation. The use of single-letter variables (B, C, D, etc.) throughout the entire class destroys any clarity of intent, making it impossible to understand what parameters represent. Method names (a, b, c, d, e) provide zero semantic meaning. The code length is inflated by verbose operations like tuple comprehensions and error messages, while simultaneously being hard to follow due to multiple actions per line (e.g., 'M.__dict__.pop(..., None)'). Nesting is moderate but compounded by the variable naming, making logical flow nearly impossible to trace. The reading flow is completely disorganized—you must constantly refer back to method definitions to understand what's happening. Even though the original Django code likely had clear structure, this version has destroyed it through systematic renaming, turning readable framework code into an opaque puzzle.
Run 3
This code is severely unreadable due to deliberate obfuscation. The developer replaced all meaningful names (parameters, methods, variables) with single letters or sequential placeholders (B, C, D, aG, aH, etc.), making it impossible to understand intent without cross-referencing original Django source code. Method names like 'c', 'd', 'e', 'l', 'm' provide zero semantic meaning. The code structure is technically organized but the logic flow is completely obscured. While nesting is moderate and line lengths are acceptable, the lack of descriptive identifiers violates every principle of self-documenting code. The reading flow is disorienting and requires constant mental mapping. This would be extremely difficult to maintain or debug, even for experienced Django developers, because the abstraction has been stripped away entirely. The only readability elements that remain are the docstrings and comments, but they cannot compensate for the catastrophic naming issues.
Run 1
Code Structure: Methods separate validation, field resolution, path construction, and descriptor setup logically. Nesting: Mostly moderate, with early returns reducing depth, though validation and deconstruction contain nested branches. Clarity of intent: Severely weakened by opaque method names (a–A) and variable names (B, aC, etc.); descriptive attributes, comments, and docstrings only partially compensate. Code length: Long but generally justified by responsibilities; some short expressions are unnecessarily spread across lines, and the import list adds clutter. Action granularity: Usually one operation per statement, with readable multiline calls and comprehensions. Reading flow: Consistent formatting and method grouping help, but tracing calls through cryptic names is difficult. Docstrings reference names absent from the renamed methods, and reverse_join is passed to a method whose parameter is named aI, creating additional confusion.
Run 2
Code Structure: Logically grouped into a relation-field class with focused methods and cached properties, although the large import block adds clutter. Nesting: Mostly shallow, with early returns helping readability; validation and deconstruction contain moderately nested branches. Clarity of intent: Severely weakened by opaque method names (a, b, etc.) and variable names (aA, aB, etc.). Comments, docstrings, and descriptive framework attributes partially compensate. Code length: Substantial but largely justified by functionality; some unnecessarily expanded expressions and imports slow scanning. Action granularity: Generally one action per line, with cleanly formatted calls and comprehensions. Reading flow: Consistent formatting and method grouping help, but understanding dependencies requires repeatedly tracing cryptic names. References to original names in docstrings and keyword arguments that do not match renamed parameters further disrupt comprehension.
Run 3
Code Structure: Responsibilities are separated into methods, properties, and validation helpers, giving the class a logical organization. Nesting: Mostly moderate, with early returns reducing complexity, though validation and deconstruction contain several nested branches. Clarity of intent: The main weakness is pervasive single-letter method and variable names, which obscure relationships and require repeated cross-referencing. Comments, docstrings, and descriptive attribute names partially compensate. Code length: Much of the length reflects legitimate framework logic, but extensive wrapping, boilerplate, and numerous tiny opaque helpers make it harder to scan. Action granularity: Generally one action per line, with readable multiline calls and comprehensions. Reading flow: Formatting is consistent and related functionality is grouped, but abbreviated names interrupt comprehension; docstrings reference descriptive method names absent from the snippet, and inconsistent keyword naming further confuses navigation. Overall, structurally disciplined but substantially weakened by unclear naming.