Sample
Schnappinger/diarymanagement/TBA.Messages.Messages
Human rating uses the original dataset scale.
Scores
| Method | Score | Scale | Dataset rank (0–100) |
|---|---|---|---|
| Posnett | 0 | 0–1; higher is more readable | 58.9Δ 30.2 |
| Scalabrino | 0.891 | 0–1; higher is more readable | 87.3Δ 58.6 |
| Dorn | 0.193 | 0–1; higher is more readable | 41.3Δ 12.5 |
| Mi | 0.615 | 0–1; higher is more readable | 65.7Δ 37.0 |
| LLOC | 56 | Logical lines; fewer is more readable | 37.3Δ 8.6 |
| DeepSeek V4 Pro | 15 | 0–20; mean of three runs | 38.0Δ 9.2 |
| GPT-6.1 Sol | 16 | 0–20; mean of three runs | 38.9Δ 10.2 |
| BTTF | 0.34 | 0–1; higher is more readable | 25.4Δ 3.3 |
| Human | 3 | 1–4; original rating | 28.7 |
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. | 3104.218 | −102.439 |
| Source linesThe number of non-empty source lines. | 209 | +83.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.564 | −6.846 |
Intercept 8.87 + feature contributions = -16.815 (log-odds).
Score = sigmoid(-16.815) = 0.
| Score | 0.891 |
|---|
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. | 208 | −6.328 |
| Indentation frequencyHow rapidly indentation changes from line to line. | 131 | +3.794 |
| Number layout frequencyHow rapidly the number of numeric values per line changes through the code. | 131 | −2.585 |
| Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom. | 207.814 | +2.495 |
| Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right. | 84.545 | +0.56 |
| Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *. | 0.046 | +0.498 |
| 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. | 84.928 | +0.068 |
Intercept 0.07 + feature contributions = -1.429 (log-odds).
Score = sigmoid(-1.429) = 0.193.
| Score | 0.615 |
|---|
| Score | 56 |
|---|
Run 1
The code has a clear structure, with each method handling a specific task and Javadoc comments explaining intent. However, it suffers from inconsistent naming conventions (methods start with uppercase, variables with lowercase), and some comments are redundant or unhelpful. Nesting is mostly flat, but the Set() method has multiple early returns and validations that could be extracted. Clarity of intent is decent, but magic numbers like '43' and hardcoded string concatenation for the header reduce readability. Code length is reasonable, though some methods could be shortened. Action granularity is mostly one action per line, but the Get() method combines multiple string operations in a single expression. Reading flow is acceptable, though the use of 'messageLenPos' and substring calculations makes the logic harder to follow. Overall, it is maintainable but could be improved with better naming, constants for magic numbers, and clearer header parsing logic.
Run 2
The code is well-structured with clear separation of concerns and logical organization. The class serves as a message header handler, and its methods are focused and appropriately named. Nesting is minimal, with only one level in the validation blocks. Intent is generally clear through descriptive method names and Javadoc comments, though some magic numbers (like '43' in messageHeaderLen) could be better explained. Code length is appropriate, and most lines contain single, clear actions. The reading flow is natural, with methods ordered logically from construction to message processing. Minor readability issues include some inconsistent spacing in conditions (e.g., `messageType !='Q'`) and the use of string concatenation in FormatLen, which slightly reduces clarity. Overall, the code is quite readable and maintainable.
Run 3
The code has a clear logical structure and intent, with each method handling a distinct responsibility. Documentation is thorough, improving clarity. However, there are readability issues: inconsistent naming conventions (e.g., PascalCase methods), magic numbers like 43 and 2, and some methods are longer than necessary due to validation logic mixed with core operations. The nesting is mostly flat, which is good, but the Set method has multiple validation steps that could be extracted. Reading flow is generally natural, though action granularity could be improved by separating calculations and assignments onto separate lines. Overall, the code is understandable but would benefit from consistent naming, constants for magic numbers, and breaking complex methods into smaller ones.
Run 1
Code Structure: Fields, header serialization/parsing, and accessors are logically organized into focused methods. Nesting: Shallow conditionals and straightforward exception handling keep complexity low. Clarity of intent: Documentation and descriptive field names explain the protocol, but generic Get/Set names, unconventional capitalization, and unexplained substring offsets obscure details. Code length: Methods are concise, although repetitive Javadoc, redundant initialization, and unnecessary else blocks add bulk. Action granularity: Almost every line performs one action, making validation and message construction easy to follow. Reading flow: Processing generally follows a natural validation-then-construction or parsing sequence, but inconsistent spacing, verbose formatting expressions, and the mismatch between documented hexadecimal session IDs and length-only validation introduce friction.
Run 2
Code Structure: Methods logically separate header serialization, parsing, validation, and accessors, though validation is duplicated. Nesting: Mostly flat, with simple conditionals, early exceptions, and one straightforward try/catch. Clarity of intent: Descriptive fields and documentation explain the protocol, but generic Get/Set names, nonstandard capitalization, and unexplained substring offsets obscure details. Code length: Methods are short, but repetitive Javadoc, redundant initialization, and unnecessary else branches add bulk. Action granularity: Statements generally perform one action per line, making state changes and message construction easy to follow. Reading flow: Consistent indentation and sequential processing support natural reading; verbose comments, inconsistent spacing, and repeated header-length arithmetic interrupt it somewhat.
Run 3
Code Structure: Methods logically separate header serialization, parsing, validation, and accessors. Nesting: Mostly flat, with straightforward guards and shallow conditionals. Clarity of intent: Descriptive fields and documentation explain the protocol, but generic Get/Set names, unconventional capitalization, and unexplained substring offsets obscure details. Code length: Implementation is reasonably concise, although repetitive Javadoc, an empty constructor, and unnecessary initializations add clutter. Action granularity: Statements generally perform one action per line, making validation and message assembly easy to follow. Reading flow: Consistent indentation and sequential processing support natural reading, but inconsistent spacing, verbose formatting expressions, and duplicated validation interrupt it. The hard-coded header length and questionable parsing offset make the header layout harder to reason about.