AI Skill Report Card

Enforcing Alibaba JS Style

A-84·Sep 20, 2026·Source: Extension-page
14 / 15

Apply these non-negotiable defaults to any JS code before further review:

JavaScript
// 2-space indent, semicolons, single quotes, trailing commas, const-first const heroes = [ 'Batman', 'Superman', ]; function createHero(firstName, lastName) { return { firstName, lastName }; } if (isJedi) { fight(); } else { flee(); }

Checklist to run over any file:

  • 2-space indentation, no tabs
  • Semicolons at end of every statement
  • Trailing commas in multiline arrays/objects/params, no leading commas
  • Egyptian-bracket style ({ same line, } else { same line)
  • const by default, let only if reassigned, never var
  • One variable per declaration statement
  • No unused vars, no use-before-define, no shadowing, no redeclaration
  • Single quotes for strings; template literals for concatenation
  • Array/object literals instead of new Array()/new Object()
  • Object shorthand for properties/methods
  • Dot notation for property access unless dynamic/special-char key
  • Max line length ~100 chars (except strings/regex)
Recommendation
Add a third example covering ES6+ features or naming conventions specifically, since the description promises those but examples focus mostly on var/const and objects/arrays
14 / 15
  1. Scan structure — indentation, braces, blank lines, file-ending newline.
  2. Check punctuation — semicolons, comma style (trailing, not leading).
  3. Check spacing — around keywords, parens, brackets, braces, operators, object keys.
  4. Check variable declarationsconst/let usage, one-per-statement, no var, no shadow/redeclare/use-before-define, declare close to usage.
  5. Check primitives — no wrapper objects (new Number/String/Boolean), proper coercion (Number(), String(), !!), parseInt with radix, no double-boolean-cast.
  6. Check strings — single quotes, template literals over + concatenation, no unnecessary escapes.
  7. Check arrays — literal creation, return inside callback methods (map/filter/reduce/etc.), spread operator over concat/apply, destructuring for extraction.
  8. Check objects — literal creation, shorthand syntax, unquoted keys (unless special chars), dot notation for access.
  9. Report violations grouped by rule, each with a "bad → good" code diff and the matching ESLint rule name (e.g. eslint: indent, no-var, prefer-const).
  10. Fix or annotate the code per Alibaba style, preserving logic.
Recommendation
Include a bad/good example for comment style, since it's mentioned in the description but never demonstrated
15 / 20

Example 1: Input:

JavaScript
var foo = 1, bar = 2 if(foo){ console.log(foo) }

Output:

JavaScript
const foo = 1; const bar = 2; if (foo) { console.log(foo); }

Violations: no-var, one-var, indent (4→2 spaces), keyword-spacing (missing space after if), semi (missing semicolons), space-before-blocks.

Example 2: Input:

JavaScript
const arr = new Array(1,2,3); const obj = new Object(); obj['name'] = 'tod'; function getData() { return [left, right, top, bottom] }

Output:

JavaScript
const arr = [1, 2, 3]; const obj = {}; obj.name = 'tod'; function getData() { return { left, right, top, bottom }; }

Violations: no-array-constructor, no-new-object, dot-notation, prefer object destructuring for multi-return, missing trailing ;.

Recommendation
Consider adding a brief note on how to integrate with eslint-config-ali/alloy tooling directly (e.g., config snippet) since the description explicitly calls out ESLint config setup as a use case
  • Default to const; escalate to let only when reassignment is real. Never var.
  • Declare variables as close as possible to first use, not all at the top (ES6 block scope allows this).
  • Prefer expressive coercions: Number(x), String(x), !!x — never new Number/String/Boolean.
  • Prefer spread (...) over concat/apply/manual loops for array copy, merge, and argument spreading; use Array.from when converting iterables to avoid intermediate arrays.
  • Use object destructuring for functions with multiple logical return values instead of array destructuring.
  • Group shorthand object properties together for readability.
  • Keep functions ≤ 80 lines and files ≤ 1000 lines as a soft guideline; split when exceeded.
  • Keep lines ≤ 100 chars except for strings/templates and regex literals.
  • Don't use leading commas in multiline structures — always trailing, on every last item too.
  • Don't leave empty blocks without a comment explaining why.
  • Don't rely on ASI (automatic semicolon insertion) — always terminate statements explicitly.
  • Don't use parseInt without a radix argument.
  • Don't shadow or redeclare variables, even across nested scopes.
  • Don't chain assignments (a = b = c = 1) — assign separately.
  • Don't forget return inside map/reduce/filter/sort/find/some/every callbacks — use forEach if no return value is needed.
  • Don't quote object keys unless they contain special characters or are reserved-looking dynamic strings.
  • Don't double-cast booleans (!!!!foo or if (!!foo)), the condition context already coerces.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
14/15
Examples
15/20
Completeness
17/20
Format
14/15
Conciseness
14/15