# 소스 코드 관리

# 분기 모델

PX4 프로젝트는 3가지 Git 분기 모델을 사용합니다.

We try to retain a linear history through rebases (opens new window) and avoid the Github flow (opens new window). 그러나, 전세계의 역동적인 개발팀과 수시로 병합 작업을 진행합니다.

To contribute new functionality, sign up for Github (opens new window), then fork (opens new window) the repository, create a new branch (opens new window), add your changes as commits, and finally send a pull request. 변경사항은 지속적 통합 (opens new window) 테스트를 통과한 다음에 병합됩니다.

코드 기여는 BSD 3절 라이선스 (opens new window)를 준수하여여 하며, 코드에는 사용에 제약 사항을 부과하지 않아야 합니다.

# Code Style

PX4 uses the Google C++ style guide (opens new window), with the following (minimal) modifications:

Note

Not all PX4 source code matches the style guide, but any new code that you write should do so — in both new and existing files. If you update an existing file you are not required to make the whole file comply with the style guide, just the code you've modified.

# Tabs

  • Tabs are used for indentation (equivalent to 8 spaces).
  • Spaces are used for alignment.

# Line Length

  • Maximum line length is 120 characters.

# File Extensions

  • Source files use extension *.cpp instead of *.cc.

# Function and Method Names

  • lowerCamelCase() is used for functions and methods to visually distinguish them from ClassConstructors() and ClassNames.

# Private Class Member Variable Names

  • _underscore_prefixed_snake_case is used for private class member variable names, as oppose to underscore_postfixed_.

# Class Privacy Keywords

  • zero spaces before public:, private:, or protected: keywords.

# Example Code Snippet

class MyClass {
public:

        /**
         * @brief Description of what this function does.
         *
         * @param[in] input_param Clear description of the input [units]
         * @return Whatever we are returning [units]
         */
        float doSomething(const float input_param) const {
                const float in_scope_variable = input_param + kConstantFloat;
                return in_scope_variable * _private_member_variable;
        }

        void setPrivateMember(const float private_member_variable) { _private_member_variable = private_member_variable; }

        /**
         * @return Whatever we are "getting" [units]
         */
        float getPrivateMember() const { return _private_member_variable; }

private:

        // Clear description of the constant if not completely obvious from the name [units]
        static constexpr float kConstantFloat = ...;

        // Clear description of the variable if not completely obvious from the name [units]
        float _private_member_variable{...};
};

# 소스 내 문서 작업

PX4 개발자는 소스 내에서 적절한 문서를 작성하는 것이 좋습니다.

Note

Source-code documentation standards are not enforced, and the code is currently inconsistently documented. 이보다 더 나아지길 바랍니다!

현재 두 가지 소스 기반 문서 유형이 있습니다.

  • PRINT_MODULE_* 메소드는 두 모듈 런타임과 모듈 & 이 가이드의 명령 참조 사용 지침에 모두 사용됩니다.

  • We encourage other in-source documentation where it adds value/is not redundant.

    TIP

    Developers should name C++ entities (classes, functions, variables etc.) such that their purpose can be inferred - reducing the need for explicit documentation.

:::

  • Do not add documentation that can trivially be inferred from C++ entity names.
  • ALWAYS specify units of variables, constants, and input/return parameters where they are defined.
  • 일반적으로 특이 사항이나 오류 처리에 대한 정보를 추가할 수 있습니다.
  • 필요시에는 Doxgyen (opens new window) 태그를 사용합니다. @class, @file, @param, @return, @brief, @var, @see, @note. 좋은 예는 src/modules/events/send_event.h (opens new window)입니다.

Please avoid "magic numbers", for example, where does this number in the conditional come from? What about the multiplier on yaw stick input?

if (fabsf(yaw_stick_normalized_input) < 0.1f) {
        yaw_rate_setpoint = 0.0f;
}
else {
        yaw_rate_setpoint = 0.52f * yaw_stick_normalized_input;
}

Instead, define the numbers as named constants with appropriate context in the header:

// Deadzone threshold for normalized yaw stick input
static constexpr float kYawStickDeadzone = 0.1f;

// [rad/s] Deadzone threshold for normalized yaw stick input
static constexpr float kMaxYawRate = math::radians(30.0f);

and update the source implementation.

if (fabsf(yaw_stick_normalized_input) < kYawStickDeadzone) {
        yaw_rate_setpoint = 0.0f;
}
else {
        yaw_rate_setpoint = kMaxYawRate * yaw_stick_normalized_input;
}

# 커밋과 커밋 메시지

Use descriptive, multi-paragraph commit messages for all non-trivial changes. 쉽게 이해할 수 있는 한 줄 요약과 자세한 세부정보도 기록하십시오.

컴포넌트: 변경 사항을 한 문장으로 설명하십시오. Fixes #1234

요약 시작 부분에 소프트웨어 구성 요소를 추가합니다.
모듈 이름이나 설명으로 줄을 지정합니다.
(예: "mc_att_ctrl" 또는 "멀티콥터 자세 콘트롤러").

발행번호를 <Fixes #1234>으로 붙이면, Github 커밋이 완료시 자동으로 문제를 종료합니다.
마스터 브랜치에 병합됩니다.

메시지 본문에는 여러 단락이 포함될 수 있습니다.
변경한 사항을 자세히 기술하십시오. 이 수정 사항 또는 이 커밋의 테스트 결과와 관련된 문제 및 비행 로그를 연결합니다.

변경 사항과 변경한 이유를 설명하고 코드 변경을 다른 말로 표현하지 마십시오(좋음: "GPS 수신 품질이 낮은 차량에 대한 추가 안전 점검 추가".
불량: "gps_reception_check() 함수 추가").

보고자: 이름 <email@px4.io>

****git commit -s**를 사용하여 모든 커밋을 승인합니다. ** 이렇게 하면 signed-off-by:가 추가됩니다. 마지막 줄에 이름과 이메일을 입력합니다.

This commit guide is based on best practices for the Linux Kernel and other projects maintained (opens new window) by Linus Torvalds.

# Pull Requests

Github Pull Requests (PRs) (opens new window) are the primary mechanism used to submit new functionality and bug fixes to PX4.

They include the new set of commits in your branch (relative the main branch), and a description of the changes.

The description should include:

  • An overview of what the changes deliver; enough to understand the broad purpose of the code
  • Links to related issues or supporting information.
  • Information about what testing of the PR functionality has been done, with links to flight logs.
  • Where possible, the results from general Test Flights both before and after the change.