[Unity] C# Programming Nameing

녹차·2024년 4월 23일
Unity

Unity

목록 보기
2/8
post-thumbnail

Introduction

C# Programming Nameing 정의

C# Programming Nameing은 정의는 설명하지 않더라도 누구나 알 것입니다. 말 그대로 "이름을 어떻게 정하냐"입니다.

C# Programming Nameing 필요한 이유

여러 명에서 한 프로젝트를 진행하게 될 경우 개개인마다 조금씩 프로그래밍 스타일이 다를 것입니다.

이를 방지하기 위해 저는 프로그래밍을 시작하기 전 변수, 함수 등등 표기법를 정의하여 프로그래밍을 진행합니다.

Unity 엔진은 C++로 만들어졌지만, 프로그래밍은 C#으로 하기에 C#의 관례를 전제로 하였습니다.

https://learn.microsoft.com/ko-kr/dotnet/csharp/fundamentals/coding-style/identifier-names

Body

주석 스타일

코드에 주석을 다는 방식은 팀마다 다릅니다. 어떤 팀은 코드 문서화에 공통 표준에 반드시 특정한 스타일을 따르도록 명시하기도 하고, 다른 조직은 주석의 스타일이나 양을 프로그래머가 알아서 정하도록 내버려두기도 합니다.

문장 단위 주석

문서화을 소흘하지 않는 한 가지 방법은 모든 문장에 주석을 작성하는 것입니다. 문장마다 주석을 작성하면 자연스레 꼭 필요한 코드만 작성하게 됩니다. 하지만 전체를 주석으로 도배하는 것은 역설적으로 지저분해 보이기에 권장하지 않습니다.

머리말 주석

어떤 팀은 소스 파일의 첫머리에 명시할 내용을 표준 주석으로 정해두기도 합니다. 프로그램이나 파일 관련 주요사항을 여기에 남기면 좋습니다.

[EX]

  • 최초 수정 일자
  • 최초 작성자
  • 변경내역
  • 파일에서 구현한 기능의 ID
  • 저작권 정보
  • 파일/클래스에 대한 간략한 설명
  • 미완성 기능
  • 발견된 버그

고정 양식 주석

최근에는 주석을 외부 문서화 도구로 처리할 수 있도록 표준 양식에 따라 작성하는 사례가 늘고 있습니다. 자바 프로그래머는 프로젝트에 대한 문서를 하이퍼링크 기반으로 자동으로 생성해 주는 javaDOC이란 도구에서 표준 양식에 따라 주석을 작성합니다. 유니티 내에서는 DocFX, Doxygen 등등 있습니다.

https://assetstore.unity.com/packages/tools/utilities/doxygen-tool-13962?locale=ko-KR&srsltid=AfmBOopJWozMB7BPMxJXIr5ACDkxNknrOAZSlwbqfeGe6ONvhyKI8y5j

임의 주석

말 그대로 정해진 형식과 관계없이 필요할 때마다 주석을 달 때가 있습니다. 이런 주식을 작성할 때는 아래와 같이 가이드라인이 있으면 좋습니다.

[EX]

  • 공격적이거나 무시하는 표현은 자제합니다. 여러분이 작성한 코드를 언제든지 다른 사람이 볼 수 있습니다.
  • 팀원끼리만 이해하는 농담을 적어도 문제되진 않지만, 관리자의 검토를 받는 것이 좋습니다.
  • 주석을 작성하기 전에 굳이 주석을 달 필요가 없도록 코드를 수정할 수 없는지 검토합니다.
  • 코드에 자기 이름을 남기지 않습니다. 이러한 정보는 소스 코드 관리 시스템에서 자동으로 관리해줍니다.
  • API을 사용하는 과정이 명확하지 않다면 사용한 API에 대한 참고 문헌을 남깁니다.
  • 한 함수를 여러 부분으로 나누기 위해 주석을 작성할 때 그 함수를 더 작은 단위의 함수로 나눌 수 없는지 검토합니다.

Formatting

중괄호 정렬에 관련된 논쟁

가장 흔하게 볼 수 있는 논쟁거리 중 하나로 코드 블록을 표시하는 중괄호를 적는 위치에 대한 것입니다.

Way1

void someFunction()
{
	if(condition()) {
    	Debug.Log("condition was ture");
    else {
    	Debug.Log("condition was ture");
    }
}

Way2 * 저는 아래와 같이 사용합니다.

Number1
void someFunction()
{
	if(condition()) 
    {
    	Debug.Log("condition was ture");
    }
    else 
    {
    	Debug.Log("condition was ture");
    }
}

Way3

Number1
void someFunction()
{
	if(condition()) 
    	{
    		Debug.Log("condition was ture");
        }
    else 
    	{
    		Debug.Log("condition was ture");
    	}
}

Way4

Number1
void someFunction()
{
	if(condition()) 
    	Debug.Log("condition was ture");
    else 
    	Debug.Log("condition was ture");
}

스페이스와 소활호에 대한 논쟁

문장단위로 적용되는 포매팅 논쟁거리입니다.

way1 * 저는 아래와 같이 사용합니다.

if(i == 2) {
	j = i + (k / m);
}

way2

if( i == 2) {
	j = i + (k / m);
}

스페이스와 탭

space와 tab에 대한 서식은 단순히 스타일에 대한 취향으로 보기 힘듭니다. 팀 내에서 따로 정하지 않으면 협업에 문제가 발생합니다. 가장 대표적인 예로 프로그래머A는 코드를 들여 쓸 때 4칸을 사용했고, 프로그래머B는 5칸을 사용했습니다. 두 코드를 한 파일로 합쳐보면 매우 지저분해 보이기 때문입니다.

대부분 IDE는 Space와 Tab을 설정하는 기능을 제공합니다. 어떤 IDE는 소스 파일을 불러 올 때 코드에 적용된 스타일을 따르기도 하고, 코드를 지정할 때 tab 키를 들여 쓴 부분을 모두 space로 변환하기도 합니다. 서식을 유연하게 처리하는 환경을 사용하면 다른 사람이 쓴 작성한 코드를 다루기 편합니다.

Unity UGUI

[UI 관련 약자 모음]

  • Button -> Btn
  • Image -> Img
  • TextMeshProUGUI -> Txt
  • CanvasGroup -> CG
  • inputField -> IF
[SerializeField] Button _maxPointBtn;
[SerializeField] TextMeshProUGUI _maxPointTxt;
[SerializeField] CanvasGroup CG;

혹은 btn, txt을 뒤로 빼서 빠르게 찾을 수 있도록 써도 문제없습니다.

[SerializeField] Button _btnMaxpoint;
[SerializeField] TextMeshProUGUI _txtMaxpoint;
[SerializeField] CanvasGroup CG;

Variable

C, C++은 Prviate 접근자 앞에(생략 가능) _ 을 안붙이는 것이 관례이지만, C#에서는 멤버변수 앞에 붙이는 것이 관례입니다. 또한 멤버 변수는 카멜 표기법이 사용됩니다. 

[변수]
[SerializeField] int _pointNum;
[SerializeField] float _speedValue;

Get&Set

  • 외부에서 클래스 변수에 값을 할당 할 때, 변수의 값이 변경되었을 때를 감지하여, 다른 함수나 동작을 실행하길 원한다.

  • 해당 변수를 여러 곳에서 가져가서 조건을 사용하는 것을 편하게 하기 위해서 사용한다.

[ShowInInspector] public int MisstakeNumber { get; set; }
[ShowInInspector] public string Answer { get; set; }
[ShowInInspector] public bool IsStageClear { get; set; }

Class & Function

C#에서는 Class, Function 파스칼 표기법을사용한다. 

[함수]
public void Begin(UIInGameView owner)
{
    Debug.Log("StageRuntimeState Begin");
}

public void End(UIInGameView owner)
{
    Debug.Log("StageRuntimeState End");
}

public void Runtime(UIInGameView owner)
{
    Debug.Log("StageRuntimeState Runtime");
    owner.GameTime();
}

Static

C, C++은 static(정적)의 경우 앞에 sint32, staticInt가 관례이지만 C#에서는 멤버변수 앞에 ‘s’을 붙이는 것이 관례입니다. 

C++
static int msint16 = 0; //#선언 및 초기화
static int ms_int32 = 0; //#선언 및 초기화
static int sint64 = 0; //#선언
unity
static int s_int32 = 0; //#선언 및 초기화
static int s_int64 = 0; //#선언

Abstract

public abstract void ShowPanel();
public abstract void HidePanel();

Interface

Interface 사용할 경우 앞에 ‘I’을 사용해줍니다, 또한 복수형보다는 단수형을 사용하고 이후 파스칼표기법 사용해줍니다. 

public interface UIObject
{
    public void Enter();

    public void Exit();
}

Code Comment

.CS마다 summary를 만들어 다른 사람이 어떤 코드인지 빠르게 알 수 있도록 만들어주었습니다.

/// <summary>
/// 모든 UI는 UIOjbect 상속받아 담당합니다.
/// </summary>

Namespace & Enum

프로젝트의 커스텀 Enum 데이터 타입들을 모아놓을 클래스 파일을 만들어
유니티 개발 과정에서 다양한 열거형 타입들을 사용하게 될 것이다.

이 데이터 타입들 중에서 특정 클래스에 귀속되어야 하는 타입도 존재하겠지만 글로벌하게 사용되어야 한느 공통 데이터 타입들도 존재한다. 빠르게 개발을 진행할 때를 위해 마음놓고 정의할 공간이 필요하다.

타입들을 네임스페이스 묶어두면 클래스 타입과 네이밍이 겹칠 일이 없으며, 자동완성의 이점을 누릴 수 있다.

namespace EnumTypes
{
    public enum ViewType
    {
        LogoView = 0,
        FixUIView,
        InfinteView,
        StorySelectView,
        StoryView
    }

    public enum Language
    {
        Kr = 0,
        En,
        Jp,
        Zh
    }
}

ETC 약어

[PRS 관련]

  • Transform -> tr
  • position - pos
  • rotation -> rot
  • direction -> dir

[그 외]

  • Gameobject -> obj
  • Vector2/3 -> vec2/3
  • animator -> anim

Conclusion

한번 개인/팀 프로젝트에 직접 적용해보시고, 프로그래머가 3명 이상일 경우 프로그래머끼리 이름 규칙을 만드는 것은 게임 개발을 원활하게 진행할 수 있습니다.

profile
녹차
CK23 Game programmer
이전 포스트

[Unity] In-Game Flow FSM(feat. State Pattern)

다음 포스트

[Unity] Hierarchy & Aseets & ETC Management

0개의 댓글