Sample
pyint-99802a916285-I01
Remove comments and docstrings
Scores
| Method | Score | Scale |
|---|---|---|
| Posnett | 0 | 0–1; higher is more readable |
| Dorn | 0.719 | 0–1; higher is more readable |
| Mi | 0.29 | 0–1; higher is more readable |
| LLOC | 15 | Logical lines; fewer is more readable |
| DeepSeek V4 Pro | 16.67 | 0–20; mean of three runs |
| GPT-6.1 Sol | 17.67 | 0–20; mean of three runs |
| BTTF | 0.601 | 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. | 702.096 | −23.169 |
| Source linesThe number of non-empty source lines. | 27 | +10.8 |
| 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.272 | −6.408 |
Intercept 8.87 + feature contributions = -9.907 (log-odds).
Score = sigmoid(-9.907) = 0.
Feature contributions
| Feature | Value | Contribution (log-odds) |
|---|---|---|
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 0 | −0.804 |
| 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. | 70.929 | +0.661 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 1 | +0.398 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.058 | +0.374 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 27 | +0.197 |
| Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code. | 27 | +0.08 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 26.875 | −0.034 |
Intercept 0.07 + feature contributions = 0.941 (log-odds).
Score = sigmoid(0.941) = 0.719.
| Score | 0.29 |
|---|
| Score | 15 |
|---|
Run 1
The code is mostly readable. It defines a single validator class with a clear purpose, uses attrs decorators for concise class setup, and formats the error message in a readable multi-line string. The __call__ method has balanced nesting (only one level deep) and performs one primary action: validating callability and raising an error if needed. The __repr__ method is short and clear. Minor improvements could include extracting the error message into a class-level constant or method to reduce the length of __call__, and adding a docstring to describe the validator's role. The imports are somewhat cluttered with an unused contextmanager import, which slightly hurts readability.
Run 2
The code is generally readable and well-structured. It has a clear purpose: defining a validator class for callable checking. The nesting is shallow with only one conditional and no deeply nested blocks. Intent is clear from the class name '_IsCallableValidator' and method names. The code is concise - no unnecessary repetition or boilerplate. Action granularity is mostly one action per line, though the message construction spans multiple lines for readability. Reading flow is natural: imports, class definition, call method, then repr. Minor deductions: the leading underscore suggests internal use but lacks documentation, the conditional could be inverted for early return (though current style is acceptable), and the multi-line string construction adds slight complexity. The imports appear partially unused in this snippet (operator, re) which could cause confusion.
Run 3
The code is highly readable with clear logical structure and flat nesting. The class has a single responsibility (validating callables), and the __call__ method flows naturally: check condition, build message, raise error. The error message construction is well-organized with clear placeholder names. One minor readability issue: the blank line after the method signature in __call__ is unnecessary, and the message variable could be inlined, but these are trivial. The code is concise, each action is on its own line, and the flow from validation to error raising is intuitive. Type hints are absent but not required given the project context.
Run 1
Code Structure: The validator class is logically organized, with validation and representation in separate methods, though several imports are unused in this snippet. Nesting: A single conditional keeps control flow shallow; nested formatting adds only minor visual complexity. Clarity of intent: Descriptive class and exception names, the callable check, and the detailed error message clearly communicate the purpose. Code length: The implementation is concise, although unused imports and an extra blank line add clutter. Action granularity: Each statement performs one clear action, and the multiline exception construction is easy to inspect. Reading flow: The progression from checking the value to raising an informative exception is natural; the decorators and abbreviated parameter names require some familiarity with the surrounding library.
Run 2
Code Structure: The validator class is logically organized into validation and representation methods, though several unused imports add clutter. Nesting: A single conditional keeps control flow shallow; nested formatting calls remain manageable. Clarity of intent: The class name, callable check, and descriptive exception make its purpose clear, although abbreviations such as inst and attr require some familiarity. Code length: The implementation is concise, with minor excess from unused imports and an unnecessary blank line. Action granularity: Statements perform distinct actions, and the exception construction is cleanly split across lines. Reading flow: The code proceeds naturally from checking the value to reporting failure, followed by a simple representation method.
Run 3
Code Structure: The validator class logically groups validation and representation methods, though several unused imports add clutter. Nesting: A single conditional keeps nesting shallow; the nested formatting call remains manageable. Clarity of intent: The class name, callable check, and descriptive exception clearly communicate the purpose, although abbreviated parameter names and unfamiliar decorator options require context. Code length: The implementation is concise, with only a stray blank line and unused imports detracting from economy. Action granularity: Statements generally perform one action each, and multiline formatting makes exception construction easy to scan. Reading flow: Imports, decoration, validation, and representation follow a natural order, with consistent indentation and readable line breaks.