How to Write High‑Quality Front‑End Code: Best Practices and Standards

1. Introduction

1.1 Why Write High‑Quality Code

In business development, projects often start fast but slow down as new features are added, bugs become harder to fix, and the codebase feels like a patchwork that requires tedious archaeology to understand.

High‑quality code is easier to read and modify, reducing maintenance effort. It is more reusable and extensible, leading to faster feature development. For front‑end code, high quality means fewer errors, faster load times, and better responsiveness, directly improving user experience.

Good articles have three standards: ideas, logic, and rhetoric. Writing code is similar—first ensure functional correctness, then pursue elegant form through coding standards, so that regardless of how many people work on it, the code feels like a single author wrote it.

1.2 What Is High‑Quality Code

Readability: clear naming, short functions, comments for complex sections, consistent style.

Maintainability: follow design patterns, avoid heavy dependencies, modular structure, intuitive for future changes.

Robustness: handle edge cases, fail gracefully, follow security best practices.

Efficiency: minimal resources, CDN proximity, lazy loading, optimal data structures and algorithms.

1.3 How to Write High‑Quality Code

Programming is not just about making code run; it is about writing elegant, efficient, maintainable code. It requires good thinking, problem‑solving strategies, and attention to detail.

Front‑end development involves many technologies and tools. Insufficient understanding or skill can hinder writing high‑quality code, especially under tight milestones and resources.

2. Engineer Coding Literacy

2.1 Meaningful Naming

Good names convey information and act as implicit documentation. Bad names cause misunderstand‑ings and increase maintenance cost.

Guidelines:

Choose professional words (e.g., use dispatch instead of send).

Avoid vague names like temp, arr, obj.

Prefer concrete over abstract (e.g., orderState instead of thisState).

Use prefixes/suffixes to add context (e.g., setPageSize).

Adjust name length to scope; longer names for broader scope.

Use casing conventions (camelCase, PascalCase, UPPER_SNAKE_CASE) to express meaning.

Follow team or industry patterns (e.g., boolean names start with is, has, can).

Avoid:

Spelling mistakes (e.g., submitFrom instead of submitForm).

Mixed Chinese/English (e.g., chanpinList).

Unclear abbreviations (e.g., fwsc).

Numeric or single‑letter names ( btn1, btnA).

Inconsistent naming styles ( comments, comment-list, commentList).

Incorrect singular/plural ( downloadOrderData vs downloadOrder).

Wrong antonyms ( showEditDialog vs closeEditDialog).

Names that may be filtered by ad blockers (e.g., ad, banner).

2.1.3 Team Naming Conventions

Variable names should use lowerCamelCase; prefixes indicate type (e.g., length, count for numbers, name, title for strings).

// Good variable naming
var maxCount = 10;
var tableTitle = 'LoginTable';

// Bad variable naming
var setCount = 10;
var getTitle = 'LoginTable';

2.2 Proper Comments

Prefer meaningful names over comments; avoid commenting bad names.

Explain intent, not obvious details.

Avoid translating code literally.

Provide summary comments for complex sections.

// Bad
// delete order data by id
delete(id);

// Good
deleteOrderItemById(id);

Use single‑line // comments with a preceding blank line and a space after the slashes. Use JSDoc style /** ... */ for multi‑line comments, including @param, @return, etc.

// Bad
var active = true; // is current tab

// Good
// is current tab
var active = true;

2.3 Reasonable Code Organization

Make control flow readable (stable values on the right, variable on the left).

Handle true conditions first, then simple cases, then edge cases.

Use early returns to reduce nesting.

Split long expressions, avoid deep ternary operators.

Introduce temporary variables or helper functions for clarity.

Limit variable scope and avoid unnecessary variables.

Extract common logic into reusable functions.

// Bad ternary
mode === 'multi' ? hasSelectedAll ? 'All selected' : 'None selected' : mode === 'single' ? 'Single select' : null;

// Good
if (mode === 'multi') {
  // ...
} else if (mode === 'single') {
  // ...
}

function errorHandler(error) {
  alert('Server busy, please try later');
  log('axios response err', error);
}

async function getUser() {
  try {
    const response = await axios.get('/user?ID=12345');
    console.log(response);
  } catch (error) {
    errorHandler(error);
  }
}

2.4 Front‑End Skills

Read entire API of frameworks, understand their principles, and know their limits.

Leverage existing libraries (e.g., decimal.js, day.js) and team‑provided component libraries.

2.5 Front‑End Security and User Experience

Validate and sanitize user input to prevent SQL injection and XSS.

Prevent XSS by not rendering untrusted HTML.

Mitigate CSRF with anti‑forgery tokens.

Enforce HTTPS and HSTS.

Use Content Security Policy (CSP) to restrict resource origins.

Consider performance, layout, interaction, error handling, and responsiveness across devices.

3. E‑Commerce Front‑End Development Standards

3.1 Language, Framework, and Component Libraries

Team consensus: use React for web development. PC back‑office projects default to MUI . Mobile pages prefer one‑code‑multiple‑targets solutions such as RTX documents with component libraries KproM and Kid‑ui‑plus .

3.2 Engineering Coding Standards

Consistent code style is enforced by lint tools and type checkers.

ESLint for JavaScript syntax.

StyleLint for CSS syntax and formatting.

Prettier for overall file formatting.

Team uses the jia command (built on code‑spec‑unid) to run checks and auto‑fixes, combining ESLint, StyleLint, and Prettier.

jia check

3.3 Commit Conventions

Husky with lint‑staged and CommitLint enforces commit messages in the format <type>: <subject>. Types include upd, feat, fix, docs, style, refactor, chore, revert.

3.4 Compatibility Handling

Browserslist for browser compatibility configuration.

Babel to transpile modern JavaScript.

PostCSS with Autoprefixer for CSS compatibility.

3.5 Static Code Checks

kdev scans source code for sensitive words, licensing, and external domains. It also checks build artifacts for size, source maps, and other safety aspects. The Tianqiong platform provides dynamic checks for page performance metrics such as LCP and FMP.