Skip to content

Latest commit

 

History

History
106 lines (74 loc) · 2.82 KB

CONTRIBUTING.md

File metadata and controls

106 lines (74 loc) · 2.82 KB
Raw

C/C++ Project Style Guide

Table of Contents

  1. Introduction
  2. Formatting and Code Style
  3. Documentation
  4. Git and GitHub Guidelines

1. Introduction

Welcome to the C/C++ Project Style Guide. This guide outlines the coding standards and best practices to be followed by contributors to maintain consistency and high-quality code across the project.

2. Formatting and Code Style

Indentation

Use 4 spaces for indentation; do not use tabs.

Line Length

Limit each line of code to a maximum of 80 characters for improved readability.

Naming Conventions

  • Identifiers (functions, variables): Use camelCase.
  • Classes/Structs: Begin with a capital letter and use PascalCase.
  • Functions and variables: Begin with lowercase letters and use camelCase.

Braces

Use the K&R style for braces:

if (condition) {
    // code
} 
else {
    // code
}

Main Code in Header Files

Avoid writing program code in header files. Place only declarations and small inline functions in headers. Main code should be in the corresponding source files (.c or .cpp) to ensure modularity and prevent potential issues.

Add headers to CMakeLists.txt when required

Header Guards

All header files must include header guards to prevent multiple inclusions. Use the following format:

#ifndef HEADER_NAME_H
#define HEADER_NAME_H

// Content of the header

#endif // HEADER_NAME_H

3. Documentation

README

Maintain an up-to-date and informative README.md at the root of the repository. Include details such as:

  • Project overview
  • Installation instructions
  • Usage examples
  • Plans
  • Configuration details
  • Contribution guidelines
  • License information

4. Git and GitHub Guidelines

Branching Strategy

  • Never directly commit to the main branch.
  • Create a branch for each feature/bugfix using descriptive names.
  • Push branches to the remote repository and open pull requests.
  • Use the following branches:
    • main: Stable production-ready code.
    • develop: Integration branch for upcoming releases.
    • Feature branches: Created off develop and merged back after development.

Commit Messages

  • Write clear and descriptive commit messages.
  • For minor patches, a concise message is acceptable.
  • Use the rebase strategy to keep commit history clean before merging.

Pull Requests

  • Create pull requests from feature/bugfix branches to develop.
  • Provide detailed descriptions of changes.
  • Require code reviews before merging.