Sample
pyint-ba8634181a0b-I03
Replace names with length-matched meaningful but unrelated identifiers
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.105 | 0–1; higher is more readable |
| Mi | 0.583 | 0–1; higher is more readable |
| LLOC | 73 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 3.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 9.33 | 0–20; mean of three runs |
| BTTF | 0.405 | 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. | 5634.53 | −185.939 |
| Source linesThe number of non-empty source lines. | 270 | +108 |
| 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.41 | −6.616 |
Intercept 8.87 + feature contributions = -75.685 (log-odds).
Score = sigmoid(-75.685) = 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. | 271 | −8.559 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 196 | +6.042 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 196 | −4.077 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 269.967 | +3.364 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 90.978 | +0.663 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.041 | +0.541 |
| 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. | 90.959 | −0.187 |
Intercept 0.07 + feature contributions = -2.143 (log-odds).
Score = sigmoid(-2.143) = 0.105.
| Score | 0.583 |
|---|
| Score | 73 |
|---|
Run 1
The code is extremely difficult to read due to deliberate obfuscation. Variable names like 'user', 'feature', 'localUser', 'node', 'map', 'date', 'step', 'operation', 'customer', 'flag', 'nextIndex', 'request', 'key', 'region', 'count', 'localData', 'activeNode', 'state', 'pendingAccount' are meaningless in context. Action granularity is poor as multiple complex operations are chained together per line. The nesting is moderate but intent is completely unclear. Code structure is disorganized with no logical grouping, and the reading flow is unnatural. While some docstrings exist, the code itself is nearly incomprehensible without extensive reverse-engineering. This appears intentionally obfuscated rather than genuinely readable.
Run 2
The code is severely unreadable due to completely obfuscated variable names and misleading identifiers. The __init__ method uses names like 'user', 'feature', 'localUser', 'node', 'map', 'date', 'step', 'operation' that have no relation to their actual purpose (name, default, validator, repr, eq, hash, etc.). This destroys clarity of intent and makes the code impossible to understand without external documentation. The class-level docstring describes proper attribute names, but the implementation deliberately obscures them. Method names are also misleading (validateAddress instead of from_counting_attr, create instead of evolve, readState instead of _setattrs). The code has multiple actions per line and confusing logic like 'state is None if pendingAccount is None else pendingAccount'. While the overall structure is flat, the deliberate obfuscation of names, confusing aliasing (key, region, count, localData), and unclear parameter relationships make this code nearly unreadable despite being syntactically valid Python.
Run 3
The code is severely obfuscated and unreadable. Variable names like 'user', 'feature', 'localUser', 'node', 'map', 'date', 'step' have no semantic connection to their actual purposes (name, default, validator, repr, eq, hash, etc.). The constructor's parameter list is completely disconnected from the __slots__ definition, making it impossible to understand the data model. Method names like 'validateAddress', 'create', and 'readState' obscure their actual functions (classmethod constructor, evolve-like copy, state restoration). The frequent use of generic terms ('map', 'key', 'region', 'count', 'localData', 'pendingAccount') for critical attribute operations destroys clarity of intent. While the code has relatively flat nesting and one action per line, these positives are negated by the misleading naming throughout. The reading flow is broken as readers must constantly mentally map obfuscated names to their actual meanings. Only the docstrings and type hints on new methods provide some clarity, but they are inconsistent with the obfuscated parameter names.
Run 1
Code Structure: Methods are logically grouped within a single class, but create() calls _setattrs while the apparent implementation is named readState, making relationships confusing. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Severely weakened by misleading names such as validateAddress, primaryStatus, and pendingAccount, which do not match attribute-management responsibilities. Comments and docstrings help, but sometimes reference names absent from the signatures. Code length: Extensive documentation is useful, although the long constructor, repetitive assignments, and many positional arguments increase reading effort. Action granularity: Generally good, with one assignment or operation per statement and clearly separated steps. Reading flow: Formatting is consistent, but readers must repeatedly translate arbitrary parameter names into meaningful slot names; the lengthy positional constructor call and awkwardly wrapped expressions further interrupt comprehension.
Run 2
Code Structure: Methods are logically grouped within a single class, but create() calls _setattrs(), whereas the apparent implementation is named readState(), disrupting coherence. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Severely weakened by misleading names such as validateAddress, primaryStatus, and defaultBalance, and constructor parameters unrelated to the attributes they populate. Documentation helps explain the class but does not match several implementation names. Code length: Reasonable for the functionality, though lengthy documentation and repetitive assignments increase scanning effort. Action granularity: Generally strong, with one operation per line; the four-value assignment and long positional constructor call require extra interpretation. Reading flow: Consistent formatting and useful comments help, but arbitrary naming, positional argument mapping, and awkward line breaks interrupt comprehension.
Run 3
Code Structure: Methods separate initialization, copying, and serialization logically, but create calls _setattrs while the apparent corresponding method is named readState, disrupting coherence. Nesting: Mostly shallow, with manageable conditionals and loops. Clarity of intent: Documentation explains the class well, but misleading names such as validateAddress, primaryStatus, and defaultBalance obscure attribute-related operations; constructor parameters do not match the fields they populate. Code length: Reasonable for its responsibilities, though extensive documentation and repetitive assignments increase scanning effort. Action granularity: Generally one action per line, with a few dense expressions and a four-variable assignment. Reading flow: Consistent formatting and explanatory comments help, but the long positional constructor call, inconsistent naming conventions, and awkwardly wrapped expressions force readers to repeatedly trace parameter-to-field mappings.