Source code
package def.dom;
public class MouseEvent extends UIEvent {
public java.lang.Boolean altKey;
public int button;
public int buttons;
public double clientX;
public double clientY;
public java.lang.Boolean ctrlKey;
public Element fromElement;
public double layerX;
public double layerY;
public java.lang.Boolean metaKey;
public double movementX;
public double movementY;
public double offsetX;
public double offsetY;
public double pageX;
public double pageY;
public EventTarget relatedTarget;
public double screenX;
public double screenY;
public java.lang.Boolean shiftKey;
public Element toElement;
public int which;
public double x;
public double y;
native public java.lang.Boolean getModifierState(java.lang.String keyArg);
native public void initMouseEvent(java.lang.String typeArg, java.lang.Boolean canBubbleArg, java.lang.Boolean cancelableArg, Window viewArg, double detailArg, double screenXArg, double screenYArg, double clientXArg, double clientYArg, java.lang.Boolean ctrlKeyArg, java.lang.Boolean altKeyArg, java.lang.Boolean shiftKeyArg, java.lang.Boolean metaKeyArg, double buttonArg, EventTarget relatedTargetArg);
public static MouseEvent prototype;
public MouseEvent(java.lang.String typeArg, MouseEventInit eventInitDict){}
public MouseEvent(java.lang.String typeArg){}
protected MouseEvent(){}
}
Run 1
The code has a clear, logical structure as a domain model class, listing many related properties and methods. However, readability is significantly harmed by extremely long method signatures—especially the initMouseEvent method—that cram multiple parameters onto a single line, making it difficult to visually parse. Action granularity suffers because multiple parameters share one line rather than one per line, and the reading flow is disrupted by the long parameter list. Nesting is flat and clarity of intent is decent, but the use of fully qualified java.lang.Boolean and java.lang.String types adds unnecessary verbosity. Overall, the organization is predictable and straightforward, but formatting and verbosity prevent it from being highly readable.
Run 2
The code has a clear, logical structure: all fields grouped together, followed by methods and constructors, making it easy to scan. It is flat with no nesting, which aids readability. Naming is explicit and follows typical DOM API conventions, so intent is clear for developers familiar with the domain. However, readability is reduced by very long method signatures (e.g., initMouseEvent) that contain many parameters, making them hard to parse quickly. Action granularity is generally one field or method per line, which is good. The reading flow is natural from fields to methods, but the excessively verbose fully qualified names like java.lang.Boolean add noise. Some redundancy (e.g., multiple constructors with empty bodies) could be simplified, but overall the code is fairly readable but suffers from dense parameter lists.
Run 3
The code is a straightforward DOM type declaration with excellent structure: fields are grouped logically and ordered by type, with a single field per line. Nesting is minimal (class-level only), and clarity of intent is high—each field and method maps clearly to the MouseEvent specification. The two long method signatures (getModifierState and initMouseEvent) slightly reduce readability due to their horizontal length, but this is common in API bindings. Action granularity is appropriate, and reading flow is natural, though the constructor overloads at the bottom could be grouped more explicitly with comments. Overall, highly readable for a generated or boilerplate DOM class.
Run 1
Code Structure: A straightforward event-binding class, with fields followed by methods and constructors; the prototype field slightly interrupts this organization. Nesting: Flat, with no nested logic. Clarity of intent: Familiar mouse-event property names and inheritance make the purpose clear, though overlapping coordinates and legacy fields lack explanations. Code length: Concise overall, but fully qualified types add visual noise, and initMouseEvent has an excessively long signature. Action granularity: Each declaration occupies its own line, making individual members easy to identify. Reading flow: Consistent declarations support scanning, but missing blank lines between member groups, unconventional modifier ordering, and tightly formatted empty constructors reduce readability.
Run 2
Code Structure: A straightforward class declaration separates fields, methods, and constructors, although the static prototype field interrupts this grouping. Nesting: Flat, with no nested control flow. Clarity of intent: The class name, inheritance, and conventional event-property names make its purpose clear; native declarations and empty constructors suggest an API binding, but this is not documented. Code length: Concise overall, though fully qualified java.lang types add visual noise and initMouseEvent has an excessively long signature. Action granularity: Each field, method, and constructor occupies its own line, making declarations easy to scan. Reading flow: Generally predictable, but minimal spacing, limited semantic grouping of related properties, and the unwrapped parameter list reduce readability.
Run 3
Code Structure: A straightforward class declaration separates fields, methods, and constructors, though spacing and semantic field grouping would improve organization. Nesting: Essentially flat, with no nested control flow. Clarity of intent: The class name, inheritance, and familiar mouse-event properties clearly identify its purpose; native methods and empty constructors lack explanatory context. Code length: Concise overall, but initMouseEvent has an excessively long signature that would benefit from wrapping. Action granularity: Each field, method, and constructor occupies its own line, making individual declarations easy to scan. Reading flow: Generally natural from properties to methods to constructors, but the prototype field interrupts that progression, and fully qualified types add visual noise.