ArkTS programming specification(1)

#harmonyosnext

Targets and Applicability

This guide, referencing industry standards and practices as well as the characteristics of the ArkTS language, aims to enhance code standardization, safety, and performance.

It applies to developers engaged in system or application development using ArkTS for coding.

Rule Sources

ArkTS retains the essential syntax style of TypeScript while enhancing static checking and analysis. Some rules are drawn from the "OpenHarmony Application TS&JS Programming Guide". Additional rules specific to ArkTS syntax are included to boost code readability and execution performance.

Chapter Overview

Code Style: Covering naming and formatting.
Programming Practices: Addressing declarations, initializations, data types, operations, expressions, exceptions, etc.
Rules Reference: Based on the "OpenHarmony Application TS&JS Programming Guide", with modifications to accommodate ArkTS specifics.

Terms and Definitions

Term	Abbreviation	Chinese Explanation
ArkTS	None	ArkTS programming language
TypeScript	TS	TypeScript programming language
JavaScript	JS	JavaScript programming language
ESObject	None	In cross - language invocation scenarios of ArkTS, used to mark the type of JS/TS objects

General Principles

Rules are categorized into two levels: Requirements and Recommendations.

Requirements: Rules that should be followed in principle. Currently, all rules in this guide are requirements for ArkTS coding.
Recommendations: Best practices that can be adopted based on actual circumstances.

Naming Conventions

Objective: Select descriptive names for identifiers to enhance code readability.
Description: Good identifier names should adhere to the following principles:
- Clearly convey intent. Avoid single letters or non - standard abbreviations.
- Use proper English words and grammar. Avoid Chinese pinyin.
- Be unambiguous to prevent misunderstandings.
- Class names, enum names, and namespace names should use UpperCamelCase.
Level: Recommendation
Description: Class names should start with a capital letter and follow the camel case convention.
- Class names are typically 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
namespace Base64Utils {
  function encrypt() {
    // todo encrypt
  }

  function decrypt() {
    // todo decrypt
  }
};

Variable Names, Method Names, and Parameter Names: Use lowerCamelCase.
Level: Recommendation
Description: Function names are typically verbs or verb phrases, using lower camel case. Examples include:
- load + PropertyName()
- put + PropertyName()
- is + BooleanPropertyName()
- has + Noun/Adjective()
- Verb()
- Verb + Object()

Variable names should be nouns or noun phrases, using lower camel case for easy comprehension.

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 Names and Enum Value Names: Use all - uppercase letters with underscores between words.
Level: Recommendation
Description: Constant names should consist of all - uppercase words separated by underscores. They should fully convey their meaning.
Positive Example:

const MAX_USER_SIZE = 10000;

enum UserType {
  TEACHER = 0,
  STUDENT = 1
};

Boolean Variable Names: Avoid using negative names for Boolean variables. Prefix Boolean local variables or methods with terms that express affirmative meanings.
Level: Recommendation
Description: Boolean local variables should be prefixed with terms like is, has, can, should. Double negatives arising from logical NOT operators can cause comprehension issues. For example, !isNotError is unclear. Thus, defining Boolean variables with negative names 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() {}

DEV Community