1. 코딩 규칙

 

음... 현재 사용하고 있는 유니티에서 회사 및 개인 개발에 사용하고 있는 방법은 Camel 방식이다. 전역변수는 앞애 _(언더바)를 붙여 사용하고 있다. 하지만 언리얼은 조금 다르다.

 

일단 구글 C++ 코딩 스타일 가이드를 한번 보자

이 문서가 있는 이유는 무엇입니까?

이 가이드가 제공해야 하는 몇 가지 핵심 목표가 있습니다.
이것이 모든 개별 규칙의 근간이 되는 근본적인 이유입니다. 
이러한 아이디어를 전면에 내세움으로써 우리는 토론의 토대를 마련하고 
왜 규칙이 있고 특정 결정이 내려진 이유를 더 넓은 커뮤니티에 더 명확하게 전달하기를 희망합니다. 
각 규칙이 제공하는 목표를 이해하면 규칙이 언제 포기될 수 있는지(일부는 포기될 수 있음) 
가이드의 규칙을 변경하는 데 어떤 종류의 인수 
또는 대안이 필요한지 모든 사람에게 더 명확해야 합니다.

정리 해보면, 프로젝트 에서 작성된 코드는 한사람이 만든것 처럼 작성해야 코드를 분석하는데 시간을 줄일수 있다. 라고 한다.

 

이제 언리얼에서 공식적으로 사용하고 있는 코딩 표준을 알아보자

https://docs.unrealengine.com/5.1/ko/epic-cplusplus-coding-standard-for-unreal-engine/

코딩 표준

 

클래스 체계

클래스는 작성자보다는 읽는 사람을 염두에 두고 조직되어야 합니다. 읽는 사람은 대부분 클래스의 퍼블릭 인터페이스를 사용할 것이므로, 퍼블릭 인터페이스에서 먼저 선언한 후 클래스의 프라이빗 구현이 뒤따라야 합니다.

 

라고 돼있다. 이게 무슨 말이냐면

UCLASS()
class HELLOUNREAL_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()
public:

private:

};

이런식으로 public 선언 후에 private 선언을 하는것을 말한다.

 

명명 규칙

기본적으로 코딩을 할때 사용하는 명명 규칙은 크게 세개로 나눠진다.
- 파스칼 케이싱(Pascal Casing) : 합성어의 첫 글자를 대문자를 사용해 명명 -> UnrealEngine

- 카멜 케이싱(Camel Casing) : 첫 합성어는 소문자로 나머지는 대문자를 사용해 명명 -> unrealEngine

- 스네이크 케이싱(Snake Casing) : 합성어 사이에 언더바(_)를 사용해 명명 -> unreal_engine

 

각 단어의 첫 번째 글자(타입 이름 또는 변수 이름)는 대문자여야 하며, 
일반적으로 단어 사이에는 언더스코어를 사용하지 않습니다. 
예를 들어, Health 및 UPrimitiveComponent 는 올바르지만, 
lastMouseCoordinates 또는 delta_coordinates 는 올바르지 않습니다.

위에는 언리얼 엔진의 명명 규칙이다. 파스칼 케이싱을 사용하고 있다. 따라서 언리얼 엔진을 사용할때는 파스칼 케이싱을 따르도록 한다.

 

UObject 에서 상속받는 클래스에는 접두사 U를 포함합니다.

이전에 만든 클래스를 한번 확인해보자

UCLASS()
class HELLOUNREAL_API UMyGameInstance : public UGameInstance
{
	GENERATED_BODY()
public:
	virtual void Init() override;

private:

};

MyGameInstance 를 확인해보면 앞에 U가 있는것을 볼수 있다.

AActor 에서 상속받는 클래스에는 접두사 A를 포함합니다.
SWidget 에서 상속받는 클래스에는 접두사 S를 포함합니다.

 

위의 설명대로 만들면 된다.

부울 변수는 접두사 b를 포함합니다(예: bPendingDestruction 또는 bHasFadedIn ).

부울값은 b를 꼭 붙여주자 사용해보면 편하다.

 

필수 사항은 아니지만, 
함수 파라미터가 참조로 전달된 후 함수가 그 값에 쓸 것으로 예상되는 경우 
이름 앞에 접두사 'Out'을 추가할 것을 권장합니다. 
이렇게 하면 이 아규먼트에 전달되는 값이 함수로 대체된다는 것을 확실히 알 수 있습니다.

이건 C#에서 기능이 있다.

 

포터블 C++ 코드

언리얼에서는  워낙 메모리가 중요하기 때문에 int 선언이 아니라 int32 이런식으로 변수를 선언 해야 된다.

 

Const 정확

중요하다. 혼자 개발하는게 아니기 때문에 다른 사람이 변수를 수정하는것을 막아준다. 그리고 과거의 내가 잘 써놓으면 현재 코딩하는 나도 헷갈리지 않게 사용할수 있다.

    void SomeMutatingOperation(FThing& OutResult, const TArray<Int32>& InArray)
    {
        // InArray는 여기서 수정되지 않지만, OutResult는 수정될 수도 있습니다.
    }

    void FThing::SomeNonMutatingOperation() const
    {
        // 이 코드는 자신을 호출한 FThing을 수정하지 않습니다.
    }

    TArray<FString> StringArray;
    for (const FString& : StringArray)
    {
        // 이 루프의 바디는 StringArray를 수정하지 않습니다.
    }

이렇게 주석을 달아놓는것도 좋다.

    // const 포인터에서 const 이외 오브젝트 - 포인터로의 재할당은 불가하나, T는 여전히 수정 가능합니다.
    T* const Ptr = ...;

    // 틀림
    T& const Ref = ...;

밑의 Reference 타입은 어차피 수정할수 없는 타입이기 때문에 const를 붙여봤자 의미 없다.

    // 나쁜 예 - const 배열 반환
    const TArray<FString> GetSomeArray();

    // 좋은 예 - const 배열로의 레퍼런스 반환
    const TArray<FString>& GetSomeArray();

    // 좋은 예- const 배열로의 포인터 반환
    const TArray<FString>* GetSomeArray();

    // 나쁜 예 - const 배열로의 const 포인터 반환
    const TArray<FString>* const GetSomeArray();

첫번째는 복사과정이 추가되기 때문에 문제가 있고,

두번째는 자주사용 되고, 세번째는 잘 사용이 안된다.
네번째는 굳이??

 

최신 C++ 언어 문법

override, final은 사용해야만 한다.

nullptr은 NULL로 대체 해야 된다.

 

개인적으로 거의 사용하지 않고 있다. 인텔리 센스가 발전돼서 좋다. 라는 사람이 많지만, 그래도 자료형을 확인하기 위해 마우스 한번 가져다 대야 확인할수 있어 가독성이 조금 떨어진다.

 

밑의 방법이 이터레이터로 돌아가기때문에 약간 더 빠르다.

 

강 - 타입 Enum

    UENUM()
    enum class EThing : uint8
    {
        Thing1,
        Thing2
    }

이 방식으로 열거형을 만들어야 한다.

이동 시맨틱

디폴트 멤버 이니셜라이저

언리얼에서는 변수 값을 초기화 할때 생성자에서 초기화 해주는것이 좋다.

 

나머지는 문서 들어가서 확인해보는것이 좋다.