Sample
pyint-b8e9dddb2fa4-SRC
Unmodified source class
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.759 | 0–1; higher is more readable |
| Mi | 0.682 | 0–1; higher is more readable |
| LLOC | 20 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.33 | 0–20; mean of three runs |
| GPT-6.1 Sol | 18 | 0–20; mean of three runs |
| BTTF | 0.179 | 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. | 742.8 | −24.512 |
| Source linesThe number of non-empty source lines. | 24 | +9.6 |
| 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.762 | −7.142 |
Intercept 8.87 + feature contributions = -13.185 (log-odds).
Score = sigmoid(-13.185) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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. | 46.92 | +1.678 |
| 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.08 | +0.165 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 25 | +0.151 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 24 | −0.13 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 24 | +0.093 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 23.708 | −0.078 |
Intercept 0.07 + feature contributions = 1.145 (log-odds).
Score = sigmoid(1.145) = 0.759.
| Score | 0.682 |
|---|
| Score | 20 |
|---|
Run 1
The code demonstrates good structure with logical imports and consistent method organization. However, the class `TagBytes` inherits from `JSONTag`, which is not defined in the provided snippet, creating ambiguity about the class hierarchy and incomplete context. The nesting is flat, with no deep conditional blocks. Action granularity is appropriate, with one action per line. The methods are concise and focused, with clear intent regarding base64 encoding/decoding for JSON serialization. However, the class lacks a docstring or comments explaining the purpose of the JSON tag pattern, and the `key = " b"` value is cryptic without additional context. The use of type hints and annotations supports readability, but the incomplete class definition (missing `__init__` or other methods from `JSONTag`) makes the code feel fragmented. Overall, the code is readable in isolation but would benefit from additional context about the parent class and over
Run 2
The code is highly readable with a clear, logical structure. It uses a class with a single responsibility (handling bytes serialization), flat nesting, and concise methods that each perform one action. Naming is explicit, and type hints improve clarity. Minor deductions for multiple imports per line and slightly terse method bodies, but overall flow and intent are excellent.
Run 3
The code is concise, well-structured, and highly readable. It uses clear imports with consistent ordering, a single-purpose class with a descriptive name, and type hints that express intent. Each method contains exactly one logical action, avoiding unnecessary nesting or complexity. The use of `__slots__` is explicitly stated and self-explanatory in this context. The only minor readability drawback is the lack of a module-level docstring or class-level comment explaining the purpose of `TagBytes` and its relationship to `JSONTag`, but the method names (`check`, `to_json`, `to_python`) make the contract sufficiently clear.
Run 1
Code Structure: The class logically groups type checking and bidirectional serialization, with imports separated from implementation. Nesting: Methods are flat and require no nested control flow. Clarity of intent: Class and method names clearly convey bytes-to-JSON conversion using Base64, though the opaque key " b" and externally defined JSONTag require context. Code length: The implementation is concise, but several imports are unused in this snippet. Action granularity: Each statement occupies its own line; the encode-and-decode chain is a compact, understandable conversion. Reading flow: Methods follow a natural check, serialize, deserialize sequence. Additional spacing between imports and the class would slightly improve presentation.
Run 2
Code Structure: The class logically groups byte checking and conversion methods, though several imports are unused and JSONTag is not defined or imported in the snippet. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Class and method names clearly convey byte serialization and deserialization; the opaque key " b" and absent base-class context slightly reduce clarity. Code length: The implementation is concise, but unused imports add clutter. Action granularity: Each statement performs a single clear action; the encode/decode chain remains easy to follow. Reading flow: Imports, class attributes, and methods appear in a natural order, with consistent formatting and useful type annotations.
Run 3
Code Structure: A compact class logically groups byte detection, JSON encoding, and decoding. Nesting: Methods are flat, with no nested control flow. Clarity of intent: Descriptive method names and standard Base64 functions make the purpose clear, though JSONTag is undefined in the snippet and the key " b" is unexplained. Code length: The implementation is concise, but several imports are unused in the shown code. Action granularity: Each statement occupies its own line; the encode/decode chain is short and easy to follow. Reading flow: Methods follow a natural check–serialize–deserialize sequence, with consistent formatting and type annotations. Additional spacing around the class and removal of unused imports would improve readability.