본문 바로가기
Game Programming

Unity 세팅 및 Visual Studio 세팅

이민웅 2017. 2. 3. 16:09
728x90
반응형

C#Formatting-Exported-2016-07-13 (1).vssettings


Visual Studio C# Setting & Plugins


Indent 와 같은 editor 기본 설정

 

Plugins

1. Visual Studio auto format document on Save

Visual Studio 에서 위 플러그인을 설치 하면, 저장 할 때 자동으로 indent와 포맷을 수정 후 저장해 줍니다.

2. FuzzyOpenFile

ALT+o를 누르면 빠르게 파일을 찾아서 열 수 있습니다.

3. CodeMaid

C#, C++, F#, VB, PHP, PowerShell, R, JSON, XAML, XML, ASP, HTML, CSS, LESS, SCSS, JavaScript 등의 언어를 깔끔하게 정리해 줍니다.

4. Indent Guides

코드의 indent 라인을 표시해 줍니다.

5. Go To Definition

Ctrl + click하면 관련 source로 이동합니다.

6. Developer Assistant for Visual Studio

Stackoverflow 같은데서 code 찾아줍니다.

 

Unity3D C# coding style guide

1. 공백

  • Indent는 스페이스 쓰지 않고 탭을 사용합니다.
  • Indent의 간격은 자신이 사용하는 IDE에 설정합니다.
  • 클래스, 함수, 분기문, 반복문 사이에는 줄바꿈을 합니다.
  • 분기문과 반복문의 가로 앞뒤에는 탭을 쓰지 않고 스페이스를 씁니다.
    • 스페이스 형식은 자율입니다.

 

if ( a = 0 )
{
    a = 100;
}
  • 쉼표는 문자열 뒷쪽에 붙여 줍니다.(2.1 enum 참고)

 

2. 이름 짓기

이름 짓기시에는 기본적으로 카멜표기법을 사용합니다. 의미가 없는 짧은 이름 또는 약어로 이름을 짓지 않습니다.

// 나쁜 예
void q()
{
}
 
// 좋은예
void RunQuery()
{
}

2.1. const, enum

  • 고정 형식의 전역 변수는 대문자와 언더바로 표기 합니다.
  • Enum type의 정의는 "E_"로 시작합니다.
 
const string GOOGLE_URL = "google.com";
enum E_DAYS
{
    SAT = 1,
    SUN,
    MON,
    TUE,
    WED,
    THU,
    FRI,
    XXX_XXX
};

2.2. namespace, class

  • 카멜표기법을 사용합니다.
  • 첫문자를 대문자로 시작합니다.

2.3. function

  • 카멜표기법을 사용합니다.
  • 첫문자는 대문자로 시작합니다.
    • Unity3D에서 기본적으로 제공되는 함수는 대문자로 시작합니다. 이 코드와 구분을 위해서 첫 문자를 소문자로 사용 됩니다.
  • private 함수일 경우에는 언더바(_)로 시작 합니다.
 
class MyClass()
{
    public MyClass()
    {
    }
 
    public void RunStart()
    {
    }
}

2.4. variable

  • 카멜표기법을 사용합니다.
  • 첫문자는 소문자로 시작합니다.
  • 일반적인 변수의 형식과 클래스는 프리픽스를 붙이지 않습니다.
  • UI 컴포넌트 기반의 변수에는 프리픽스를 붙입니다.
  • public을 제외한 멤버는 m_를 붙입니다.
 
int iCount; // X
int count;  // O
public GameObject panelMovie;   // O
public GameObject buttonSkip;   // O 
protected XXX m_jaewonBabo; // O
private YYY m_MinBabo;      // X
private ZZZ mJungHwanBabo;  // X
  
public int a {get; set;}    // O (property는 변수로 봅니다, override 쓰지말자)

2.5. array 형

  • array의 변수는 복수형을 사용합니다.
    • 변수의 명만 봐도 바로 배열형임을 알 수있게 됩니다.
    • 배열 변수명의 예 1. dog (X), dogs (O) 2. list (O) : 원래 복수형
  • ex
    • private Dictionary<> m_dogDic
    • private List<> m_dogList
    • private Array m_dogArray;
    • private xxx[] m_dogs; 영어 사전 검색 권장

2.6. Guide

(출처: http://devmag.org.za/2012/07/12/50-tips-for-working-with-unity-best-practices/)

Naming General Principles
  1. Call a thing what it is. A bird should be called Bird.
  2. Choose names that can be pronounced and remembered. If you make a Mayan game, do not name your levelQuetzalcoatisReturn.
  3. Be consistent. When you choose a name, stick to it.
  4. Use Pascal case, like this: ComplicatedVerySpecificObject. Do not use spaces, underscores, or hyphens, with one exception (see Naming Different Aspects of the Same Thing).
  5. Do not use version numbers, or words to indicate their progress (WIP, final).
  6. Do not use abbreviations: DVamp@W should be DarkVampire@Walk.
  7. Use the terminology in the design document: if the document calls the die animation Die, then use DarkVampire@Die, notDarkVampire@Death.
  8. Keep the most specific descriptor on the left: DarkVampire, not VampireDark; PauseButton, not ButtonPaused. It is, for instance, easier to find the pause button in the inspector if not all buttons start with the word Button. [Many people prefer it the other way around, because that makes grouping more obvious visually. Names are not for grouping though, folders are. Names are to distinguish objects of the same type so that they can be located reliably and fast.]
  9. Some names form a sequence. Use numbers in these names, for example, PathNode0, PathNode1. Always start with 0, not 1.
  10. Do not use numbers for things that don’t form a sequence. For example, Bird0, Bird1, Bird2 should be Flamingo, Eagle,Swallow.
  11. Prefix temporary objects with a double underscore __Player_Backup.
Naming Different Aspects of the Same Thing

Use underscores between the core name, and the thing that describes the “aspect”. For instance:

  • GUI buttons states EnterButton_Active, EnterButton_Inactive
  • Textures DarkVampire_Diffuse, DarkVampire_Normalmap
  • Skybox JungleSky_Top, JungleSky_North
  • LOD Groups DarkVampire_LOD0, DarkVampire_LOD1

Do not use this convention just to distinguish between different types of items, for instance Rock_Small, Rock_Large should be SmallRock, LargeRock

3. indention

  • namespace, class, function과 같이 집합으로 이루워지는 단위는 BSD 스타일을 사용합니다.
  • 프로그램의 묶음 단위를 편하게 인식 할 수 있도록 합니다.
  • 각 단위 앞뒤로는 한줄을 띄어 주도록 합니다.
 
namespace StyleGuide
{
    public class MyClass
    {
        int name = 'guider';
 
        public MyClass()
        {
        }
 
        public int MultiplyAddOne ( int num )
        {
            return num * num;
        }
 
        private int Sum ( int num)
        {
            return num + num;
        }
    }
}
if (...)
{
}
else
{
}
 
while (1)
{
}
 
switch ( language )
{
    case "korean":
        //...
        break;
    case "korean":
        //...
        break;
    default:
        break;
}

 

4. 주석

4.1. 기본 규칙

  • 클래스는 무조건 주석을 달아 줍니다.
  • 함수는 되도록이면 주석을 달아 줍니다. 강제 하진 않습니다.
  • 주석은 IDE 툴에서 지원하는 양식을 선호 합니다.
    • 클래스, 함수 등 앞에서 슬래쉬(/)를 3번 치면 양식이 출력 됩니다. (VS2015, monodevelop 모두 같음.)
 
/// <summary>
/// 스타일 가이드
/// by author, YYYYMMDD
/// </summary>
namespace StyleGuide
{
    /// <summary>
    /// 내 클래스
    /// by author, YYYYMMDD
    /// </summary>
    public class MyClass
    {
    }
}

4.2. Fixme Comment

소스코드에 요구 사항에 따른 주석을 달아 줍니다. fixme comment는 해당 함수, 또는 변수 상단에 달아 줍니다.

  1. TODO : 좀 더 최적화시키고 리팩토링 시킬 수 있는 만한 구석이 있을 때.
  2. FIXME : 문제가 있는것이 확실하지만, 그걸 당장 수정할 필요는 없을 때.
  3. XXX : 해당 부분에 대해서는 더 생각해볼 필요성이 있을때. 또는 해당 부분에 질문이 생길 때.
  4. NOTE : 해당 부분의 이해가 필요 하거나, 메모를 남기고 싶을 때.
 
// TODO : 음성인식 로직을 개선 사항이 보임.
// FIXME : 랜덤으로 오류가 발생 함.
// XXX : 구현중 정확한 동작 확인 필요
// NOTE : 특별 변수와 연동이 되어 있습니다.

 

5. Unity3D class get instance

Unity3D에서 Class 참조 시 property를 참조 하게 한다.

 

6. Bracing

(출처: http://wiki.unity3d.com/index.php/Csharp_Coding_Guidelines)

Open braces should always be at the beginning of the line after the statement that begins the block. Contents of the brace should be indented by 1 tab or 4 spaces. For example:

if (someExpression)
{
   DoSomething();
}
else
{
   DoSomethingElse();
}

 

“case” statements should be indented from the switch statement like this:

switch (someExpression)
{
   case 0:
      DoSomething();
      break;
  
   case 1:
      DoSomethingElse();
      break;
  
   case 2:
      {
         int n = 1;
         DoAnotherThing(n);
      }
      break;
} 
 

Braces should never be considered optional. Even for single statement blocks, you should always use braces. This increases code readability and maintainability.

for (int i=0; i<100; i++) 
{
    DoSomething(i);
}

6.1 Single line statements

Single line statements can have braces that begin and end on the same line.

public class Foo
{
   private int m_bar;
  
   public int bar
   {
      get { return m_bar; }
      set { m_bar = value; }
   }
  
   public int foo { get; private set; }
} 
It is suggested that all control structures (if, while, for, etc.) use braces, but it is not required.


728x90
반응형
저작자표시

'Game Programming' Related Articles

티스토리툴바