ArkTS programming specification(1)

Coding Guidelines for ArkTS

Target and Applicability

This document, aligned with industry standards and practices and tailored to the features of ArkTS, offers coding guidelines to enhance code standardization, security, and performance. It is designed for developers engaged in system or application development using ArkTS.

Rule Sources

ArkTS builds on the basic syntax of TypeScript and introduces enhanced static checking and analysis. Some rules in this guide are adapted from the "OpenHarmony Application TS&JS Programming Guide", with additions specific to ArkTS to boost code readability and performance.

Chapter Overview

• Code Style: Covers naming and formatting.
• Programming Practices: Includes declarations, initializations, data types, operations, expressions, and exceptions. The rules are refined based on the "OpenHarmony Application TS&JS Programming Guide", with irrelevant parts removed and new rules added for ArkTS.

Terms and Definitions

Term	Abbreviation	Explanation
ArkTS	None	ArkTS programming language
TypeScript	TS	TypeScript programming language
JavaScript	JS	JavaScript programming language
ESObject	None	Marks the type of JS/TS objects in cross-language calls in ArkTS

General Principles

Rules are categorized into two levels: Requirements and Recommendations.

• Requirements: Rules that should generally be followed. All content in this document currently falls under the requirements for ArkTS.
• Recommendations: Best practices that can be adopted based on specific circumstances.

Naming Conventions

General Naming Principles

• Clarity: Names should clearly convey their purpose. Avoid single letters or non-standard abbreviations.
• English Usage: Use correct English words and grammar. Avoid Chinese pinyin.
• Distinctiveness: Names should be distinctive to prevent misunderstandings.

Class, Enum, and Namespace Naming

• Style: Use UpperCamelCase.
• Description: Class names should be nouns or noun phrases, such as Person, Student, Worker. Verbs and vague terms like Data, Info should be avoided.

Positive Example:

// Class Name
class User {
  username: string;

  constructor(username: string) {
    this.username = username;
  }

  sayHi() {
    console.log('hi' + this.username);
  }
}

// Enum Name
enum UserType {
  TEACHER = 0,
  STUDENT = 1
}

// Namespace Name
namespace Base64Utils {
  function encrypt() {
    // todo encrypt
  }

  function decrypt() {
    // todo decrypt
  }
}

Variable, Method, and Parameter Naming

• Style: Use lowerCamelCase.
• Description: Function names are typically verbs or verb phrases. Variable names should be nouns or noun phrases.

Positive Example:

let msg = 'Hello world';

function sendMsg(msg: string) {
  // todo send message
}

let userName = 'Zhangsan';

function findUser(userName: string) {
  // todo find user by user name
}

Constant and Enum Value Naming

• Style: Use all uppercase letters with underscores between words.
• Description: Constant names should be composed of all uppercase words separated by underscores to fully express their meaning.

Positive Example:

const MAX_USER_SIZE = 10000;

enum UserType {
  TEACHER = 0,
  STUDENT = 1
}

Boolean Variable Naming

• Prefix Usage: It is recommended to use prefixes that convey meaning, such as is, has, can, should, for Boolean local variables and methods. However, the use of logical negation operators can lead to double negatives, such as !isNotError, which can be confusing. Therefore, the definition of Boolean variables with negative meanings should be avoided.

Negative Example:

let isNoError = true;
let isNotFound = false;

function empty() {}
function next() {}

Positive Example:

let isError = false;
let isFound = true;

function isEmpty() {}
function hasNext() {}