Sample

Dorn/python/46

Human rating uses the original dataset scale.

DatasetDorn
Human3.61
Lines10

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett0.0010–1; higher is more readable
58.2Δ 13.4
Dorn0.7290–1; higher is more readable
68.5Δ 3.1
Mi0.2540–1; higher is more readable
24.8Δ 46.8
LLOC8Logical lines; fewer is more readable
63.9Δ 7.7
DeepSeek V4 Pro14.330–20; mean of three runs
69.9Δ 1.7
GPT-6.1 Sol150–20; mean of three runs
52.8Δ 18.8
BTTF0.520–1; higher is more readable
49.9Δ 21.7
Human3.611–5; original rating
71.6

Views

Download official ZIP ↗

Select the downloaded ZIP or its extracted folder. Files stay in your browser.

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(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.398.354−13.146
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.835−7.252
Source linesThe number of non-empty source lines.10+4

Intercept 8.87 + feature contributions = -7.528 (log-odds).
Score = sigmoid(-7.528) = 0.001.

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.10+0.682
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.77+0.438
Indentation frequencyHow rapidly indentation changes from line to line.9−0.426
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.77+0.404
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.9.808−0.273
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.10+0.191
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.107−0.095

Intercept 0.07 + feature contributions = 0.992 (log-odds).
Score = sigmoid(0.992) = 0.729.

Score0.254
Score8
Run 1

The code shows moderate readability but has several issues. The snippet appears to be part of a class (indicated by self references) but lacks surrounding context, making intent harder to determine. Structure is logical for the operations shown - keyboard input simulation, window closing, and child window search - but the snippet is incomplete. Nesting is flat, which is good. The close() method is clear and well-documented. The findChildren method has a clear docstring but the implementation is cut off. Action granularity is generally one action per line, which aids readability. However, the keyboard input section is somewhat cryptic without comments explaining the KEYEVENTF_KEYUP flag or the tuple structure. The magic number '0' for key down is not explained. Method naming follows camelCase which is inconsistent with Python conventions (should be snake_case). Overall, the code is understandable but could benefit from better naming conventions, explanatory comments for low-level operations, and more context.

Run 2

The code is generally readable but has some issues. The structure is logical with clear method separation, and the docstrings help explain purpose. However, the excerpt starts mid-function with an indented block, making the context unclear. The nested tuple structure in 'inputs.append' requires parsing effort, and the action granularity could be improved by separating the keyboard input construction from the append operation. The 'findChildren' method signature is clear, but the return value isn't shown, limiting full evaluation. Overall, the code demonstrates reasonable organization but could benefit from more explicit variable naming and breaking down complex tuple operations into intermediate steps for better clarity.

Run 3

The code is mostly readable with clear intent and reasonable structure. Methods are short and focused, with docstrings explaining purpose. The findChildren method signature clearly states parameters. However, there are minor issues: the first two lines lack surrounding context (likely from a loop), which makes action granularity unclear. The close method is concise and well-named. Nesting is minimal. Variable naming like 'si', 'hwnd', 'klass' is somewhat abbreviated but typical for Windows API code. Overall, it's clean but could benefit from slightly more descriptive naming and context for the input handling section.

Run 1

Code Structure: Operations are grouped into methods, but the snippet begins mid-block and ends with an incomplete method, limiting structural clarity. Nesting: Visible nesting is shallow and easy to follow. Clarity of intent: Keyboard input dispatch and window closing are understandable; docstrings clarify method purposes, though abbreviations such as si and klass require context. Code length: Concise, with no obvious unnecessary expansion. Action granularity: Each line performs a single clear action. Reading flow: The sequence of keyboard events, dispatch, and subsequent method definitions is natural, but the truncated boundaries interrupt comprehension.

Run 2

Code Structure: Methods are clearly separated, but the fragment starts mid-block and ends at an incomplete method, limiting structural clarity. Nesting: Visible nesting is shallow and manageable. Clarity of intent: The close method and its docstring are clear; keyboard constants communicate press/release behavior, though 'si' and 'klass' require context. Code length: Concise, with no obvious unnecessary code. Action granularity: Each statement performs one primary action. Reading flow: Straightforward within each method, but the abrupt beginning and unfinished findChildren method interrupt continuity.

Run 3

Code Structure: The visible methods are logically separated, but the snippet starts mid-block and ends with an incomplete method, limiting structural clarity. Nesting: Visible nesting is shallow and easy to follow. Clarity of intent: Method names, docstrings, and named constants clearly communicate keyboard input, window closing, and child lookup; abbreviations such as si and klass require context. Code length: The code is concise without obvious unnecessary statements. Action granularity: Each line performs a single clear action. Reading flow: Blank lines and straightforward statements support natural reading, although the truncated boundaries interrupt comprehension.