Source code
package def.dom;
public class XPathEvaluator extends def.js.Object {
native public XPathExpression createExpression(String expression, XPathNSResolver resolver);
native public XPathNSResolver createNSResolver(Node nodeResolver);
native public XPathResult evaluate(String expression, Node contextNode, XPathNSResolver resolver, double type, XPathResult result);
public static XPathEvaluator prototype;
public XPathEvaluator(){}
native public XPathNSResolver createNSResolver();
}
Run 1
The code is a simple TypeScript declaration file for a DOM class, which is generally clear but has some readability issues. The structure is logical and flat, with no nesting, making it easy to follow. Intent is fairly clear for a declaration file, but overloads like `createNSResolver()` without arguments next to one with `Node` parameter may confuse readers without context. Code length is concise, appropriate for a wrapper. Each method is on one line, which is good for granularity, but method signatures are long, reducing scanning speed. The reading flow is natural for developers familiar with DOM APIs, but the mixed use of `native`, missing access modifiers, and implicit `public` reduces clarity. The empty constructor is redundant in TypeScript declarations. Overall, readable for experienced developers but lacks polish for broader audiences.
Run 2
The code is a simple, flat class definition with clear method signatures, making the intent easy to understand. Structure is logical, and nesting is minimal. However, readability is reduced by the presence of native methods, an empty constructor, a static prototype field, and overloaded methods without explanatory comments. The presence of both a static field named 'prototype' and a public constructor adds ambiguity. Action granularity is acceptable—each method is on a single line. Reading flow is natural due to the simple API surface. The score reflects the code being reasonably readable but lacking contextual clarity for a JavaScript-to-Java bridge scenario.
Run 3
The code is a short Java class with a clear purpose: defining an XPath evaluator interface. Structure is logical for a domain model, and intent is mostly clear from method names. However, readability suffers from several issues: use of 'native' methods without context, an overloaded createNSResolver with an empty implementation which is ambiguous, and the presence of a static 'prototype' field that seems out of place in idiomatic Java. The class is concise, but parameter names like 'type' are vague. There is minimal nesting, and each method is on one line, which keeps the file flat and action-per-line clean. Reading flow is interrupted by non-standard constructs ('native', 'prototype') that would confuse Java developers, suggesting this is transpiled or generated code rather than hand-written. Overall, it is readable in basic structure but lacks clarity in details and Java conventions.
Run 1
Code Structure: A compact class groups related XPath API declarations logically, though the prototype field and constructor interrupt the method grouping. Nesting: No nested logic, making the code easy to scan. Clarity of intent: Descriptive class, method, and parameter names clearly convey XPath functionality; the double type parameter and undocumented no-argument overload are less informative. Code length: Concise, with no redundant implementation. Action granularity: Each declaration occupies its own line, although the long evaluate signature would benefit from wrapping. Reading flow: Generally natural, but blank lines between methods, fields, and the constructor, conventional modifier ordering, and spacing in the empty constructor would improve readability.
Run 2
Code Structure: A simple, logically organized class containing related XPath operations, though grouping overloads together would improve organization. Nesting: No nested control flow, making the code easy to scan. Clarity of intent: Descriptive class, method, and parameter names communicate purpose; however, the numeric type parameter and prototype field are less self-explanatory. Code length: Concise, with no unnecessary implementation detail. Action granularity: Each declaration occupies its own line, although the empty constructor uses cramped formatting. Reading flow: Generally natural, but the long evaluate signature, lack of spacing between member groups, and separated createNSResolver overloads slightly reduce readability.
Run 3
Code Structure: A simple, logically organized class, though grouping the createNSResolver overloads would improve organization. Nesting: No nested control flow; only the class scope. Clarity of intent: XPath-related method and parameter names communicate purpose well, but the numeric type parameter and native binding conventions require external knowledge. Code length: Concise, with no unnecessary implementation detail. Action granularity: Each declaration occupies its own line, making members easy to distinguish. Reading flow: Mostly natural, but the long evaluate signature, lack of spacing between member groups, and placement of the no-argument overload after the constructor slightly reduce readability.