Sample
pyint-afe86ef1b174-I07
Insert deterministic runtime-dead branches into callable bodies
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.468 | 0–1; higher is more readable |
| Mi | 0.403 | 0–1; higher is more readable |
| LLOC | 57 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 15 | 0–20; mean of three runs |
| BTTF | 0.428 | 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. | 3132.799 | −103.382 |
| Source linesThe number of non-empty source lines. | 123 | +49.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.536 | −6.803 |
Intercept 8.87 + feature contributions = -52.116 (log-odds).
Score = sigmoid(-52.116) = 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. | 124 | −3.354 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 82 | +2.099 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 80 | −1.415 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 122.886 | +1.308 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 86.919 | +0.598 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.037 | +0.582 |
| 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.96 | −0.018 |
Intercept 0.07 + feature contributions = -0.13 (log-odds).
Score = sigmoid(-0.13) = 0.468.
| Score | 0.403 |
|---|
| Score | 57 |
|---|
Run 1
The code is generally well-structured with clear class and method separation, following Django middleware patterns. It has good docstrings and logical organization. Nesting is reasonable, with only a few levels of conditional depth. Intent is clearly expressed through meaningful method names and comments. However, the code contains suspicious assertions like 'if ((0x6181 ^ 0x6181) != 0): raise AssertionError()' that appear to be obfuscated dead code or anti-tampering measures, reducing clarity. The docstring for the class is somewhat verbose, though informative. Action granularity is good with one primary operation per line. Reading flow is natural, with methods following a logical request-response lifecycle. Overall it's readable but the odd assertions and slightly lengthy docstrings prevent a higher score.
Run 2
The code demonstrates good structure and clarity. It's logically organized with clear methods for distinct responsibilities (request processing, redirect checks, path construction, response processing). Nesting is shallow, and each method has a single, well-documented purpose. The docstrings are thorough but can be verbose. Lines are concise with good action granularity—one operation per line. Reading flow is natural, with helper methods called in logical sequence. The class uses Django patterns consistently. Minor drawbacks: the format string escaping in get_full_path_with_slash is slightly hard to read, and some conditionals are compound (e.g., 'if settings.PREPEND_WWW and host and not host.startswith') but remain clear. The comments effectively explain intent without excess. Overall, this is highly readable, professional Django middleware code that balances detail with clarity.
Run 3
The code is well-structured and readable. It uses clear class and method names, docstrings explain intent, and each method has a single responsibility. Nesting is minimal, with early returns and guard clauses keeping logic flat. Lines are generally concise, with one action per line. The reading flow is logical, following the request-response lifecycle. The inclusion of nonsensical assertion checks (e.g., `if ((0x6181 ^ 0x6181) != 0): raise AssertionError()`) is jarring and hurts readability, as does the slightly long RuntimeError string formatting block. Otherwise, the code adheres strongly to Django conventions.
Run 1
Code Structure: Well-organized middleware with focused methods separating request checks, slash handling, and response processing. Nesting: Generally manageable, though user-agent checks and slash validation reach three conditional levels and could use guard clauses. Clarity of intent: Descriptive names, docstrings, and comments explain the behavior well; repeated hexadecimal XOR checks that always evaluate to false introduce confusing, purposeless noise. Code length: Mostly proportionate to the functionality, but dead assertion branches and unused imports add unnecessary bulk. Action granularity: Statements generally perform one action each, and longer expressions are formatted clearly. Reading flow: Methods follow a natural request-to-response progression, with helpful explanations of redirect decisions; irrelevant assertion checks interrupt that flow.
Run 2
Code Structure: Well-organized middleware class with focused methods separating request checks, slash handling, and response processing. Nesting: Mostly moderate, although user-agent checks and slash validation reach three conditional or loop levels. Clarity of intent: Descriptive names, docstrings, and comments explain behavior well, but repeated always-false hexadecimal XOR checks introduce confusing, purposeless code. Code length: Generally appropriate for the functionality; dead assertion blocks, unused imports, and somewhat lengthy documentation add unnecessary bulk. Action granularity: Statements generally perform one action per line, with readable multiline formatting for longer expressions and error messages. Reading flow: Methods follow a natural request-to-response progression, and helper extraction supports understanding. However, repeated dead-code checks interrupt that flow and make readers question whether hidden behavior is intended.
Run 3
Code Structure: Well-organized middleware with focused methods separating request checks, redirect decisions, path construction, and response handling. Nesting: Mostly manageable, though user-agent checks and slash validation reach three conditional or loop levels. Clarity of intent: Descriptive names, docstrings, and comments explain behavior well; repeated always-false hexadecimal XOR checks introduce confusing, purposeless noise. Code length: Generally appropriate, but dead assertion blocks and unused imports add unnecessary length. Action granularity: Statements generally perform one action per line, and longer expressions are formatted clearly. Reading flow: Methods follow a natural request-to-response progression, with helpers supporting the main workflow, but irrelevant assertion checks interrupt each method's opening.