Sample
pyint-93a76910d7f8-I09
Select one of ten low-readability unrelated code templates per class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.075 | 0–1; higher is more readable |
| Mi | 0.572 | 0–1; higher is more readable |
| LLOC | 165 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 9.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 14 | 0–20; mean of three runs |
| BTTF | 0.285 | 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. | 10190.59 | −336.289 |
| Source linesThe number of non-empty source lines. | 250 | +100 |
| 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.514 | −6.772 |
Intercept 8.87 + feature contributions = -234.191 (log-odds).
Score = sigmoid(-234.191) = 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. | 251 | −7.851 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 224 | +7.011 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 224 | −4.719 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 249.919 | +3.084 |
| 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. | 121.972 | −1.501 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 121.996 | +1.164 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.074 | +0.223 |
Intercept 0.07 + feature contributions = -2.519 (log-odds).
Score = sigmoid(-2.519) = 0.075.
| Score | 0.572 |
|---|
| Score | 165 |
|---|
Run 1
The code is generally readable with clear intent, good structure, and mostly flat nesting. However, it suffers from a suspicious obfuscated block in the SHA-256 hash function (dead code with meaningless variables) that significantly hurts readability. The build_digest_header method is quite long and could be broken down, and the use of comments like 'XXX' mixed with dense string formatting makes some sections harder to follow. Type hints and documentation are helpful, though some variables (e.g., 'KD', 'entdig') are unclear without context. Overall, it is understandable but has notable readability issues.
Run 2
The code is difficult to read due to several issues. The class structure is reasonable, but the build_digest_header method is excessively long and contains deeply nested conditional logic for algorithm selection. Variable names like lI0O_df050148 and lI0O_1c11e7d0 are obfuscated and meaningless, severely impacting clarity. The code mixes type hints with complex logic, and there are unclear comments marked as 'XXX not implemented yet'. Multiple operations are packed into single lines, particularly in string concatenations and assignment chains. The reading flow is disrupted by poorly named variables and unclear purpose in some blocks. While the class-level documentation is helpful, the internal method implementation lacks clarity. The use of type annotations is good, but the overall readability is poor due to obfuscated variable names, excessive method length, and complex nested conditional logic.
Run 3
The code has decent class-level structure with type hints and docstrings, but readability suffers from several issues. The build_digest_header method is excessively long (80+ lines) and mixes concerns like algorithm selection, nonce generation, and header construction. The odd variable names like 'lI0O_df050148' and 'lI0O_1c11e7d0' are cryptic and serve no purpose, likely obfuscation. Deep nesting occurs in conditional branches for digest algorithms and the qop logic. Action granularity is poor in places - multiple statements per line using semicolons or unpacking. The reading flow is disrupted by unnecessary comments and 'XXX' markers that don't clarify intent. Missing imports like 'Response' and 'PreparedRequest' would break the code. The 'KD' lambda-like function is awkwardly named. While some parts show good organization (thread-local state initialization), the overall method length, cryptic variables, and unclear flow make this difficult to read and maintain.
Run 1
Code Structure: Methods logically separate initialization, digest generation, response handling, and comparison, but build_digest_header combines many responsibilities. Nesting: Mostly moderate, with early returns helping; nested hashing functions and conditionals add complexity. Clarity of intent: Descriptive method names, annotations, and comments explain authentication behavior, but abbreviated variables, stale comments, and the meaningless SHA-256 loop with obfuscated names undermine clarity. Code length: Some length is justified by the protocol, but repeated hashing wrappers, verbose thread-local accesses, and dead calculations are unnecessary. Action granularity: Generally one action per line, though tuple assignment and assignment expressions combine operations. Reading flow: Authentication proceeds in a sensible sequence, but algorithm-selection boilerplate, irrelevant calculations, and repeated state management interrupt it.
Run 2
Code Structure: Methods logically separate initialization, digest generation, response handling, and request hooks, but digest generation combines many responsibilities. Nesting: Mostly moderate, with deeper nesting in algorithm helpers and retry handling. Clarity of intent: Descriptive method names, annotations, and comments help; cryptic protocol variables, misleading comments, and meaningless obfuscated SHA-256 calculations hinder understanding. Code length: Repeated hash helpers, unused imports, and dead calculations add unnecessary length. Action granularity: Most lines perform one action, although the obfuscated multiple assignment and compound expressions reduce clarity. Reading flow: Authentication follows a coherent sequence, but long methods, repetitive thread-local accesses, and unexplained state transitions interrupt it.
Run 3
Code Structure: Methods separate initialization, digest generation, response handling, and comparison logically, though digest generation combines many responsibilities. Nesting: Mostly moderate, with extra depth from nested hash functions and retry handling. Clarity of intent: Descriptive method names, annotations, and comments explain authentication behavior, but cryptic variables and pointless obfuscated calculations in sha256_utf8 undermine clarity. Code length: Repeated encoding/hash wrappers, verbose thread-local access, unused imports, and dead digest scaffolding add unnecessary length. Action granularity: Generally one operation per line, making state changes and request preparation easy to follow. Reading flow: Authentication proceeds in a sensible sequence with helpful early returns, but stale comments, minimal docstrings, protocol-specific abbreviations, and the irrelevant SHA-256 loop interrupt comprehension.