Sample
Select one of ten high-readability unrelated code templates per class
| Method | Score | Scale |
|---|---|---|
| Posnett | 0.405 | 0–1; higher is more readable |
| Dorn | 0.918 | 0–1; higher is more readable |
| Mi | 0.496 | 0–1; higher is more readable |
| LLOC | 6 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 17.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 16.67 | 0–20; mean of three runs |
| BTTF | 0.837 | 0–1; higher is more readable |
Loading feature diagnosis…
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| 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.853 | −7.279 |
| Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones. | 144.754 | −4.777 |
| Source linesThe number of non-empty source lines. | 7 | +2.8 |
Intercept 8.87 + feature contributions = -0.386 (log-odds).
Score = sigmoid(-0.386) = 0.405.
| 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. | 59.875 | +1.129 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 8 | +0.753 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.024 | +0.713 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 7 | −0.495 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 6.705 | −0.316 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 60 | +0.164 |
Intercept 0.07 + feature contributions = 2.416 (log-odds).
Score = sigmoid(2.416) = 0.918.
| Score | 0.496 |
|---|
| Score | 6 |
|---|
The code is well-structured and highly readable. It uses a clear import block with forward compatibility and type-checking support. Class definition is concise with a docstring that clearly states intent. Nesting is virtually nonexistent, and each import/logical action is on its own line. One minor deduction for lack of context: the class is empty but inherits from `RequestException`, and `CompatJSONDecodeError` import is not used in the shown snippet, making purpose slightly ambiguous without surrounding code. Overall, very clean.
The code is clear and well-structured. It begins with standard imports (`__future__`, `typing`, third-party, local module), establishing a logical organization. The class definition is concise and purpose-driven, with a docstring that clearly states its intent. Nesting is non-existent, keeping the code flat and readable. Each line performs a single logical action—imports on separate lines, one class definition, one docstring. The reading flow is natural, moving from general setup to specific class definition. Minor deductions: imports of typing elements (`TYPE_CHECKING`, `Any`) and the alias `BaseHTTPError` are unused in the shown snippet, slightly reducing clarity of intent, though they may be part of a larger module. Overall, the code is concise, unambiguous, and very readable.
The code is highly readable. It has a clear, logical structure with imports grouped from standard future, typing, third-party, and local modules. Nesting is minimal, with only a simple class definition. The intent is unambiguous: defining an HTTP error exception. It is concise, avoiding unnecessary code. Action granularity is appropriate, with one import per line and a clear class declaration. The reading flow is natural, moving from imports to class definition. Minor deductions could be for the alias names, which are slightly verbose but justified for clarity.
Code Structure: Imports and the exception class are logically organized, though the visible base class RequestException is not imported or defined. Nesting: Minimal, with only a class body. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but unused imports and aliases add unexplained context. Code length: Very concise, although several imports appear unnecessary in this snippet. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward from imports to class definition; grouping imports and adding standard blank-line spacing before the class would improve readability.
Code Structure: Imports precede a focused exception class, giving the snippet a logical organization. Nesting: There is no nested control flow. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but RequestException is not defined or imported in the snippet, and the purpose of the other imports is unclear. Code length: Very concise, though several imports appear unused. Action granularity: Each import and declaration occupies its own line. Reading flow: Straightforward top-to-bottom flow, slightly weakened by unexplained dependencies and insufficient blank-line separation before the top-level class.
Code Structure: Imports followed by a single exception class are logically organized, though RequestException is not defined or imported in the snippet. Nesting: Minimal, with only the class body indented. Clarity of intent: The class name and docstring clearly identify an HTTP exception, but unused imports and aliases add ambiguity. Code length: Very concise, although several imports appear unnecessary for the shown code. Action granularity: Each line contains one declaration or import, making individual elements easy to scan. Reading flow: The top-to-bottom flow is natural; clearer import grouping and an explicit RequestException import would improve readability.