playbooks

home / skills / openharmonyinsight / openharmony-skills / openharmony-cpp

openharmony-cpp skill

/skills/openharmony-cpp

This skill enforces OpenHarmony C++ conventions, reviewing and refactoring code to ensure naming, formatting, header usage, and secure memory practices.

npx playbooks add skill openharmonyinsight/openharmony-skills --skill openharmony-cpp

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
2.2 KB
---
name: openharmony-cpp
description: Expert coding guide for OpenHarmony C++ development. Use this skill when writing, refactoring, or reviewing C++ code for OpenHarmony projects. It enforces strict project-specific conventions (naming, formatting, headers) and critical security requirements (input validation, memory safety).
---

# OpenHarmony C++ Coding Skills

## Core Mandates (Common Pitfalls)

These rules are strictly enforced in OpenHarmony and often differ from general C++ projects.

### 1. Strict Naming & Formatting
- **Extensions:** Always use `.cpp` and `.h`.
- **Files:** Filenames **must** match class names (Unix-like, e.g., `my_class.cpp`).
- **Variables:** Global vars must start with `g_` (e.g., `g_config`). Class members must end with `_` (e.g., `value_`).
- **Braces:** **K&R Style** is mandatory (opening brace on the same line).
- **Details:** See [naming_formatting.md](references/naming_formatting.md).

### 2. Header Management
- **Guards:** Use `#ifndef` guards. **#pragma once is FORBIDDEN.**
- **Includes:** Prefer `#include` over forward declarations to prevent hidden dependencies.
- **Details:** See [headers_scopes.md](references/headers_scopes.md).

### 3. Critical Security Requirements
- **Input Validation:** All external data must be validated before use (indices, sizes, loops).
- **Memory Safety:** Pointers must be set to `nullptr` **immediately** after deletion.
- **Bitwise:** Only on **unsigned** types.
- **Details:** See [secure_coding.md](references/secure_coding.md).

## Usage Guide

### When to use
- **New Code:** Generating new classes or modules.
- **Refactoring:** Cleaning up legacy code.
- **Review:** Checking code against OpenHarmony standards.

### Reference Map
- **[naming_formatting.md](references/naming_formatting.md)**: Naming conventions (g_, _), braces (K&R), line length.
- **[secure_coding.md](references/secure_coding.md)**: Input validation, integer safety, memory management, prohibited functions.
- **[class_function_design.md](references/class_function_design.md)**: Constructors, inheritance, modern C++ (nullptr, const), function size.
- **[headers_scopes.md](references/headers_scopes.md)**: Header guards, namespaces, include rules.

Overview

This skill is an expert coding guide for OpenHarmony C++ development. It enforces strict project conventions for naming, formatting, and header management and highlights critical security requirements such as input validation and memory safety. Use it to produce, refactor, or review C++ code that must comply with OpenHarmony standards.

How this skill works

The skill inspects C++ source and header files for adherence to OpenHarmony rules: file extensions, filename-to-class mapping, variable and member naming, and K&R brace style. It verifies header guards (no #pragma once), prefers explicit includes over forward declarations, and checks for proper input validation, pointer nullification after delete, and safe bitwise usage on unsigned types. It flags deviations and offers concrete corrective recommendations.

When to use it

  • Creating new classes or modules for OpenHarmony projects.
  • Refactoring legacy C++ code to conform to OpenHarmony conventions.
  • Performing code reviews to enforce naming, formatting, and security rules.
  • Auditing headers and include scopes to eliminate hidden dependencies.
  • Verifying memory management and input validation before release.

Best practices

  • Use .cpp and .h file extensions and match filenames to class names using Unix-like lowercase and underscores.
  • Prefix global variables with g_ and suffix class members with _. Keep member visibility clear and prefer small, focused functions.
  • Apply K&R brace style (opening brace on the same line) and respect configured line length and indentation rules.
  • Always use #ifndef header guards; do not use #pragma once. Prefer explicit #include over forward declarations to avoid hidden dependencies.
  • Validate all external input (sizes, indices, loop bounds) before use. Nullify pointers immediately after delete and avoid unsafe casts.
  • Perform bitwise operations only on unsigned integer types. Follow secure_coding rules for prohibited functions and integer safety.

Example use cases

  • Generate a new OpenHarmony-compliant class with correct file naming, header guard, and member naming.
  • Refactor a legacy module: convert global and member names, apply K&R braces, and replace pragma once with header guards.
  • Review a pull request to detect missing input validation or pointer nullification after deletion.
  • Audit header includes to replace forward declarations with explicit includes where required.
  • Fix bitwise operations that use signed types and validate loop bounds to prevent out-of-bounds access.

FAQ

Are #pragma once and include guards both allowed?

No. Use #ifndef header guards; #pragma once is forbidden in OpenHarmony code.

How should I handle pointer deletion?

After deleting a pointer, set it to nullptr immediately to avoid dangling pointers and make ownership explicit.