새로운 프레임워크에 적응할 때 가장 먼저 해야하는 것

• 각 언어 혹은 프레임워크마다 공식적인 명명규칙이 있다.
• 경험상으로 프로젝트마다 혹은 프로젝트 팀장의 스타일에 따라가는 경우가 많긴 했지만, 그래도 큰 틀은 각 언어 혹은 프레임워크에서 배포하는 명명규칙을 지키는 경우가 많았다.
• 언리얼 C++을 본격적으로 하기 전에 언리얼에서 배포하는 코딩 표준 문서를 봤다.

명명규칙

[AssetTypePrefix][AssetName][Descriptor]_[OptionalVariantLetterOrNumber]

AssetTypePrefix 는 에셋 타입을 식별해 줍니다. 자세한 내용은 아래 표를 참고하세요.

AssetName 은 에셋의 이름입니다.

Descriptor 는 에셋에 추가 컨텍스트를 제공하여 사용법을 파악하도록 돕습니다. 예를 들어 텍스처가 노멀 맵인지 오파시티 맵인지 설명합니다.

OptionalVariantLetterOrNumber 는 에셋의 여러 버전 또는 변형을 구분하기 위해 선택적으로 사용됩니다.

먼저 에셋 이름 명명법인데, 실제로 아트 직군과 협업하면서 가장 빈번하게 부딪히는 것 중 하나인데, 이런 기준점이 있다면 서로 부딪힐 일 없이 평화로울 것 같다.

명명 규칙을 사용할 때, 모든 코드 및 코멘트는 미국 영어의 철자법 및 문법을 사용해야 합니다.

각 단어의 첫 번째 글자(타입 이름 또는 변수 이름)는 대문자여야 합니다. 
일반적으로 단어 사이에는 언더스코어를 사용하지 않습니다. 
예를 들어, Health 및 UPrimitiveComponent 는 올바르지만, 
lastMouseCoordinates 또는 delta_coordinates 는 올바르지 않습니다.
이는 다른 오브젝트 지향 프로그래밍 언어에 익숙한 사용자를 위한 PascalCase 포맷입니다.

결국 파스칼 케이스를 주로 사용한다는 이야기인데, 생각보다 파스칼, 카멜, 스네이크 표기법을 혼용해서 쓰는 사람이 있다. 나보다 아래면 괜찮은데 윗사람이라면 골치가 많이 아파진다.

템플릿 클래스에는 접두사 T를 포함합니다.

	class TAttribute
class TAttribute
UObject에서 상속하는 클래스에는 접두사 U를 포함합니다.
	class UActorComponent
class UActorComponent
AActor에서 상속하는 클래스에는 접두사 A를 포함합니다.
	class AActor
class AActor
SWidget에서 상속하는 클래스에는 접두사 S를 포함합니다.
	class SCompoundWidget
class SCompoundWidget
추상적 인터페이스인 클래스에는 접두사 I를 포함합니다.
	class IAnalyticsProvider
class IAnalyticsProvider
에픽의 콘셉트가 유사한 클래스 타입에는 접두사 C를 포함합니다.
	template <typename Concept, typename... Ts>
template <typename Concept, typename... Ts>
열거형에는 접두사 E를 포함합니다.
	enum class EColorBits
	{
	   ECB_Red,
	   ECB_Green,
	   ECB_Blue
	};
enum class EColorBits
	{
	   ECB_Red,
	   ECB_Green,
	   ECB_Blue
	};
부울 변수에는 접두사 b를 포함합니다.
	bPendingDestruction
 
	bHasFadedIn.
bPendingDestruction

	bHasFadedIn.
그 외 대부분의 클래스는 접두사 F를 포함합니다. 그러나 일부 서브시스템은 다른 글자를 사용하기도 합니다.

무엇을 상속 받냐, 혹은 자료형에 따라서 접두사를 붙이는데, 꽤 괜찮은 스타일이라고 생각한다.

	   // true일 경우 무슨 의미일까요?
   bool CheckTea(FTea Tea);
    
   // 이름을 통해 true일 경우 차가 신선하다는 것을 명확히 알 수 있습니다.
   bool IsTeaFresh(FTea Tea);
 
   float TeaWeight;
   int32 TeaCount;
   bool bDoesTeaStink;
   FName TeaName;
   FString TeaFriendlyName;
   UClass* TeaClass;
   USoundCue* TeaSound;
   UTexture* TeaTexture;

가장 적응 안될 것 같은 부분인데, 변수가 파스칼 케이스라는 것.

과거에는 다음과 같은 이유로 UE에서 C 및 C++ 표준 라이브러리를 직접 사용하는 것을 지양했습니다.

느린 구현을 자체 라이브러리로 대체하여 메모리 할당에 대한 제어력 강화

널리 이용 가능해지기 전에 다음과 같은 새 함수 기능 추가:

바람직하지만 비표준인 동작 변경 수행

코드베이스 전체에서 문법 일관성 유지

UE 언어와 호환되지 않는 컨스트럭트 방지

이 부분도 굉장히 중요한 부분이라고 생각하는게, 엔진을 다룰 땐 엔진에서 제공하는 걸 사용하는게 협업 측면에서부터 가장 좋다고 생각한다. 유니티 같은 경우 몇년 전만해도 유니티 C#에서 지원하지 않는 C#기능이 많았다. 그래서 개고생한 적도 몇번있다.

• 사실 뭔가 새로 시작하기 전에 이렇게 공식문서부터 보고하는 경우 보다는, 하면서 중간 중간 찾아보면서 하는 경우가 더 많긴하지만, 명명규칙 같은 경우에는 초기에 습관이 안되면 나중에 고치기도 힘들어서 미리미리 보는 편이다.