Sample
pyint-360af88aded6-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.271 | 0–1; higher is more readable |
| Mi | 0.628 | 0–1; higher is more readable |
| LLOC | 54 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17 | 0–20; mean of three runs |
| BTTF | 0.38 | 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. | 2910.288 | −96.039 |
| Source linesThe number of non-empty source lines. | 106 | +42.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.331 | −6.497 |
Intercept 8.87 + feature contributions = -51.266 (log-odds).
Score = sigmoid(-51.266) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Indentation frequencyHow rapidly indentation changes from line to line. | 106 | +2.929 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 103 | −2.611 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 106 | −2.012 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 105.75 | +1.068 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.22 |
| 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. | 82.972 | +0.151 |
Intercept 0.07 + feature contributions = -0.988 (log-odds).
Score = sigmoid(-0.988) = 0.271.
| Score | 0.628 |
|---|
| Score | 54 |
|---|
Run 1
The code is well-structured and follows Django's established patterns, making it highly readable for someone familiar with the framework. Class organization is logical with clear separation between public methods (`make_token`, `check_token`) and private helpers. Nesting is minimal—the deepest nesting occurs in `check_token` with a try/except and a for loop, which remains manageable. Intent is clear throughout, with method names accurately describing their behavior. Code length is appropriate: each method is concise and focused without unnecessary verbosity. Action granularity is excellent—most lines perform a single operation, and the token generation logic is split into digestible steps. The reading flow is natural, with token creation check logic flowing sequentially from parsing to validation. Minor drawbacks include some trailing whitespace and the compact string formatting in `_make_token_with_timestamp`, but these are negligible. Overall, this is professionally written code that balances clarity with conciseness.
Run 2
The code is well-structured with clear separation of concerns and logical organization. Methods are concise and focused, with one primary action per line. Nesting is minimal—primarily in check_token, where a try/except and a for loop are used but remain readable. The intent is clear, with descriptive method names like _make_token_with_timestamp and check_token. Comments are sparse but helpful, marking key algorithms or fallback loops. The code avoids unnecessary length; helper methods prevent duplication. The reading flow is natural, following a top-down progression from token generation to validation. Minor friction includes the use of `secret` vs `secret_fallbacks` properties and some inline formatting in `_make_token_with_timestamp`, but overall readability is high.
Run 3
The code is generally well-structured, with clear separation of concerns between token generation, validation, and hashing. Methods are concise, focused, and named descriptively. The use of properties for secret and secret_fallbacks keeps access clean. Error handling in check_token is appropriately flat and early-return style, avoiding deep nesting. The for-else pattern is used correctly, though it may be slightly unfamiliar to some readers. Minor readability issues include excessive comments, unusual line breaks around the hexdigest call, and multiple actions in a few lines (e.g., unpacking token.split and comparing timestamps in the same line). Overall, the code is maintainable, predictable, and readable.
Run 1
Code Structure: Well-organized class with focused methods separating configuration, token creation, validation, and hashing. Nesting: Shallow overall; guard clauses and early returns keep validation easy to follow. Clarity of intent: Descriptive method and variable names convey purpose, but missing documentation leaves hashing choices, timestamp origin, and fallback behavior unexplained. Code length: Mostly concise, though property boilerplate and excessive blank lines add visual bulk. Action granularity: Statements generally perform one clear action each; chained HMAC generation and slicing are slightly denser. Reading flow: Validation follows a natural parse, verify, and expiry-check sequence. The loop-else construct requires familiarity, and the awkward multiline hexadecimal slice interrupts an otherwise smooth flow.
Run 2
Code Structure: Well-organized class with focused methods separating configuration, token generation, validation, and hashing. Nesting: Shallow control flow and early returns keep validation easy to follow, although the loop-else construct requires familiarity. Clarity of intent: Descriptive method names communicate purpose, but missing docstrings leave the epoch, hash slicing, and timestamp normalization unexplained. Code length: Mostly concise; property accessors add some boilerplate, and excessive blank lines introduce visual noise. Action granularity: Statements generally perform one action each, with multiline expressions remaining cohesive. Reading flow: Validation proceeds naturally from input checks through parsing, signature verification, and expiration. Awkward formatting of the hexdigest slice interrupts an otherwise readable flow.
Run 3
Code Structure: The class separates configuration, token creation, validation, hashing, and time handling into focused methods. Nesting: Early returns keep validation mostly flat; the loop and conditional introduce only modest nesting. Clarity of intent: Descriptive method and variable names convey the purpose, but the unexplained epoch, alternating-character hash slice, and timestamp normalization require inference. Code length: Mostly concise, although property boilerplate and excessive blank lines add visual overhead. Action granularity: Statements generally perform one action each, with multiline expressions remaining logically cohesive. Reading flow: Validation proceeds naturally from input checks through parsing, signature verification, and expiration checks. The loop-else construct and awkwardly wrapped hexdigest slice slightly interrupt that flow.