Source code
package def.dom;
@jsweet.lang.Extends({SVGStylable.class,SVGTests.class,SVGLangSpace.class,SVGExternalResourcesRequired.class,SVGUnitTypes.class})
public class SVGMaskElement extends SVGElement {
public SVGAnimatedLength height;
public SVGAnimatedEnumeration maskContentUnits;
public SVGAnimatedEnumeration maskUnits;
public SVGAnimatedLength width;
public SVGAnimatedLength x;
public SVGAnimatedLength y;
native public void addEventListener(String type, EventListener listener, Boolean useCapture);
public static SVGMaskElement prototype;
public SVGMaskElement(){}
public Object className;
public CSSStyleDeclaration style;
public SVGStringList requiredExtensions;
public SVGStringList requiredFeatures;
public SVGStringList systemLanguage;
native public Boolean hasExtension(String extension);
public String xmllang;
public String xmlspace;
public SVGAnimatedBoolean externalResourcesRequired;
public static double SVG_UNIT_TYPE_OBJECTBOUNDINGBOX;
public static double SVG_UNIT_TYPE_UNKNOWN;
public static double SVG_UNIT_TYPE_USERSPACEONUSE;
native public void addEventListener(String type, EventListener listener);
native public void addEventListener(String type, EventListenerObject listener, Boolean useCapture);
native public void addEventListener(String type, EventListenerObject listener);
}
Run 1
This is an API declaration class with poor readability. While it uses package/import structure properly, the file mixes many concerns (SVG mask properties, event handling, SVG test interfaces) without logical grouping. All fields and methods are declared at the same level with no sections or comments explaining why certain members are inherited or required. The order of members appears arbitrary - native methods and fields are interleaved confusingly. Multiple overloaded addEventListener methods add noise without explanation. Static prototype and constants lack context. The line 'public SVGMaskElement(){}' has an empty body, which is ambiguous. While each line represents one action and there is no deep nesting, the overall organization makes the class harder to scan than necessary. Naming follows Java conventions, which helps, but no grouping by type (constants, fields, methods) or purpose (SVG masks vs events) diminishes clarity.
Run 2
The code represents a straightforward DOM interface declaration, which limits structural complexity, but its readability is hindered by a lack of organization and clarity. The class fields are grouped by coincidental inheritance rather than logical categories, making the purpose of the class harder to discern. The multiple overloaded 'addEventListener' methods are scattered rather than grouped together, disrupting reading flow. Action granularity is mostly one declaration per line, which is good, but the overall code appears as a monolithic list of fields without comments or visual separation. The annotation '@jsweet.lang.Extends' is highly specific and assumes domain knowledge, potentially obscuring intent for readers unfamiliar with the jsweet framework. While the code is relatively concise due to the concise nature of interface declarations, the absence of any organizational structure or explanatory comments keeps the score low.
Run 3
This code represents a Java class declaration for a DOM interface, likely auto-generated. The structure is entirely linear with no methods beyond declarations, resulting in very low complexity but also poor logical organization—fields and methods are intermixed without grouping. There is no nesting, which is a positive, but clarity of intent is low because there is no documentation or comments explaining the purpose of the class, fields, or methods. Code length is moderate but verbose due to repetitive declarations. Action granularity is one field or method per line, but the reading flow is unnatural—fields like 'height' and 'width' appear early, then unrelated methods, then more fields, then static constants. This disjointed layout hampers comprehension. While technically flat and straightforward, the lack of structure and semantic grouping makes it difficult to read as meaningful code.
Run 1
Code Structure: The class is straightforward, but fields, constants, constructor, and methods are interspersed rather than grouped consistently. Nesting: Essentially flat, with no nested control flow. Clarity of intent: Descriptive SVG-related names and explicit types make the API understandable, though the annotation and native declarations require familiarity with JSweet. Code length: Concise for a binding class, with little unnecessary content. Action granularity: Each declaration occupies its own line, making individual members easy to scan. Reading flow: Generally readable, but separated addEventListener overloads, missing blank lines between logical groups, and the crowded annotation interrupt the flow.
Run 2
Code Structure: The class is straightforward, but fields, constants, the constructor, and methods are interleaved rather than grouped consistently. Nesting: Almost entirely flat, making it easy to scan. Clarity of intent: Descriptive SVG types and member names clearly identify a DOM binding, although the annotation and native declarations assume familiarity with JSweet. Code length: Concise for a declarative binding, with little unnecessary content. Action granularity: Each member occupies its own line; the empty constructor is appropriately compact. Reading flow: Mostly natural, but scattered addEventListener overloads, no blank-line grouping, and a long annotation reduce readability.
Run 3
Code Structure: A straightforward class declaration, but fields, constants, constructor, and methods are interspersed rather than consistently grouped. Nesting: Essentially flat, making it easy to scan. Clarity of intent: Descriptive SVG-related names and explicit types communicate the binding's purpose, although the annotation and inherited interface members require domain knowledge. Code length: Concise, with little unnecessary code; overloads are reasonable for an API binding. Action granularity: Each declaration occupies its own line, except the compact empty constructor, which remains understandable. Reading flow: Generally natural, but scattered addEventListener overloads, missing blank-line grouping, and the dense annotation interrupt readability.