develop, algorithm, study: 5월 2016

http://www.dofactory.com/reference/csharp-coding-standards

위의 링크에서 설명하는

C# 표준 코딩 과 올바른 네이밍 기법에 대한 정리를 번역하여 정리함

권장! 메서드 네이밍은 파스칼케싱(PascalCasing)으로 사용

public class ClientActivity
{
public void ClearStatistics()
{
//...
}
public void CalculateStatistics()
{
//...
}
}

이유 : 마이크로소프트의 .NET 프레임워크 형식과 일치하고 읽기도 쉬움

//파스칼케싱이란 대문자로 시작하며 복합어일 경우 단어가 시작될 때 마다 대문자로 시작.

권장! 매개변수나 로컬변수의 네이밍은 카멜케싱(camelCasing)으로 사용

public class UserLog
{
public void Add(LogEvent logEvent)
{
int itemCount = logEvent.Items.Count;
// ...
}
}

이유 : 마이크로소프트의 .NET 프레임워크 형식과 일치하고 읽기도 쉬움

//카멜케싱이란 소문자로 시작하며 복합어일 경우 단어가 시작될 때 마다 대문자로 시작.

금지! 헝가리안 표기법의 사용 과 변수에 타입식별자 정보를 포함

// Correct
int counter;
string name;
// Avoid
int iCounter;
string strName;

이유 : 마이크로소프트의 .NET 프레임워크와 VS IDE 는 (툴팁을 통해) 타입을 매우 간단하게 알 수 있다.
일반적으로 다른 식별자를 통한 유형 지표를 피하고자 함.

금지! 상수 또는 읽기 전용 변수에 Screaming Caps(대문자열거) 사용

// Correct
public static const string ShippingType = "DropShip";
// Avoid
public static const string SHIPPINGTYPE = "DropShip";

이유 : 마이크로 소프트의 .NET 프레임워크 형식과 일치하고 있다. 너무 많은 관심을 끈다.

권장하지 않음! 약어를 사용. 예외 : Id, Xml, Ftp, Uri 같은 일반 명칭으로 사용되는 약어

// Correct
UserGroup userGroup;
Assignment employeeAssignment;
// Avoid
UserGroup usrGrp;
Assignment empAssignment;
// Exceptions
CustomerId customerId;
XmlDocument xmlDocument;
FtpHelper ftpHelper;
UriPart uriPart;

이유 : 마이크로 소프트 .NET 프레임워크의 일관성과 일치하지 않는 약어를 방지할 수 있다.

권장! 3자 이상의 약어는 파스칼케싱을 사용(2자의 경우 모두 대문자)

HtmlHelper htmlHelper;
FtpTransfer ftpTransfer;
UIControl uiControl;

이유 : 마이크로 소프트의 .NET 프레임워크 형식과 일치하고 있다. 너무 많은 관심을 끈다.

금지! 식별자에 밑줄을 사용, 예외 : private 정적 변수에는 넣을 수 있음.

// Correct
public DateTime clientAppointment;
public TimeSpan timeLeft;
// Avoid
public DateTime client_Appointment;
public TimeSpan time_Left;
// Exception
private DateTime _registrationDate;

이유 : 마이크로소프트 .NET 프레임워크에서 일관성이 있고(밑줄 없이) 더 자연스럽게 코드를 읽을 수 있음.

또한 언더라인 스트레스(언더라인을 볼 수 없음)를 방지할 수 있음.

권장! 시스템 타입의 이름(Int16, Single, UInt64, 등) 대신 미리 정의된 타입을 사용

// Correct
string firstName;
int lastIndex;
bool isSaved;
// Avoid
String firstName;
Int32 lastIndex;
Boolean isSaved;

이유 : 마이크로소프트 .NET 프레임워크에서 일관성있고 코드를 더 자연스럽게 읽을 수 있습니다.

권장! 지역변수의 경우 VAR(암시적 형) 형을 사용. 예외 : 기본유형(int, string, double, 등)은 미리 정의된 이름을 사용.

var stream = File.Create(path);
var customers = new Dictionary();
// Exceptions
int index = 100;
string timeSheet;
bool isCompleted;

이유 : 비교적 복잡한 유형에 대한 혼란을 제거합니다. Viual Studio에서 도구 칩을 통해 쉽게 검출됩니다.

권장! 클래스 이름을 명사 또는 명사구를 사용

public class Employee
{
}
public class BusinessLocation
{
}
public class DocumentCollection
{
}

이유 : 마이크로소프트 .NET 프레임워크에서 일관성 있고 기억하기 쉽다.

권장! 인터페이스에는 접두사 I를 붙임. 인터페이스 이름은 명사(구) 또는 형용사 사용.

public interface IShape
{
}
public interface IShapeCollection
{
}
public interface IGroupable
{
}

이유 : 마이크로소프트 .NET 프레임워크 정책과 일치

권장! 소스파일의 이름은 메인클래스의 이름으로 함. 예외 : 부분 클래스의 파일이름(예를 들어 코드의 목적을 반영, 디자이너, 생성, 등)


// Located in Task.cs
public partial class Task
{
    //...
}


// Located in Task.generated.cs
public partial class Task
{
    //...
}

이유 : 마이크로소프트 관행과 일치. 파일은 알파벳 순으로 정렬하고, 부분 클래스 인접은 남아있다.

권장! 명확하게 정의된 구조를 가지는 네임스페이스를 구성

// Examples
namespace Company.Product.Module.SubModule
namespace Product.Module.Component
namespace Product.Layer.Module.Group

이유 : 마이크로소프트 .NET 프레임워크 정책과 일치. 당신의 코드베이스에서 좋은 구성을 유지함.

권장! 수직 중괄호를 맞춤.

// Correct
class Program
{
static void Main(string[] args)
{
}
}

이유 : 마이크로소프트는 다른 기준을 가지고 있지만, 개발자가 압도적으로 수직 중괄호를 선호.

권장! 클래스 상단에 모든 멤버변수를 선언, 스테틱 변수는 최상단에 선언

// Correct
public class Account
{
public static string BankName;
public static decimal Reserves;
public string Number {get; set;}
public DateTime DateOpened {get; set;}
public DateTime DateClosed {get; set;}
public decimal Balance {get; set;}
// Constructor
public Account()
{
// ...
}
}

이유 : 일반적으로 변수 선언을 찾아 다닐 필요가 없게됨.

권장! 열거형은 단수 이름을 사용. 예외 : 비트 필드 열거

// Correct
public enum Color
{
Red,
Green,
Blue,
Yellow,
Magenta,
Cyan
}
// Exception
[Flags]
public enum Dockings
{
None = 0,
Top = 1,
Right = 2,
Bottom = 4,
Left = 8
}

이유: 마이크로소프트 .NET 프레임워크에서 일관적이고 자연스럽게 코드를 읽을 수 있음.

복수 플래그 열거가(비트 or을 사용하여) 여러 값을 저장할 수 있기 때문.

금지! 명시적으로(비트 필드 제외) 열거형의 유형이나 값을 지정

// Don't
public enum Direction : long
{
North = 1,
East = 2,
South = 3,
West = 4
}
// Correct
public enum Direction
{
North,
East,
South,
West
}

이유 : 실제 유형이 아닌 값에 의존할때 혼란스러울 수 있음.

금지! 열거형 이름에 Enum을 포함

// Don't
public enum CoinEnum
{
Penny,
Nickel,
Dime,
Quarter,
Dollar
}
// Correct
public enum Coin
{
Penny,
Nickel,
Dime,
Quarter,
Dollar
}

이유 : 마이크로소프트의 .NET 프레임 워크와 일치하고 식별자에 어떤 유형 지표의 사전 규칙과 일치

develop, algorithm, study

2016년 5월 16일 월요일

C# 네이밍 정책에 대한 정리

2016년 5월 6일 금요일

Attempting to call method 'System.Reflection.MonoProperty::GetterAdapterFrame' for which no ahead of time (AOT) code was generated.

ios could not find developer disk image