C #에서 var 키워드 사용

C # 3에서 'var'키워드 사용에 대해 동료들과 토론 한 후 var를 통한 유형 유추의 적절한 사용에 대한 사람들의 의견이 궁금했습니다.

예를 들어, 나는 의심스러운 상황에서 var를 게으르게 사용했습니다.

foreach(var item in someList) { // ... } // Type of 'item' not clear.
var something = someObject.SomeProperty; // Type of 'something' not clear.
var something = someMethod(); // Type of 'something' not clear.

var의 합법적 사용은 다음과 같습니다.

var l = new List<string>(); // Obvious what l will be.
var s = new SomeClass(); // Obvious what s will be.

흥미롭게도 LINQ는 약간 회색 영역으로 보입니다.

var results = from r in dataContext.SomeTable
              select r; // Not *entirely clear* what results will be here.

IEnumerable을 구현하는 유형이 될 것이라는 결과는 분명하지만 새로운 객체를 선언하는 var와 같은 방식으로 완전히 명확하지는 않습니다.

LINQ가 객체와 관련하여 더 나쁩니다.

var results = from item in someList
              where item != 3
              select item;

이것은 동등한 foreach (var list in someList) {// ...} 동등성보다 낫습니다.

예를 들어 IEnumerable <int> 및 IEnumerable <double>을 허용하는 오버로드 된 메서드에 해당 쿼리 결과를 배치하려는 경우 호출자가 실수로 잘못된 형식으로 전달할 수 있습니다.

var 않는 당신이 의도하지 않게하는 방법에 잘못된 유형을 통과 할 때, 과부하 평균 컴파일러 오류가 발행되지 않을 때 확대되는 것을 강력한 입력을 유지하지만, 질문 유형이 정의에 즉시 나타나지 않을 것이 위험하다 정말 여부입니다.

여전히 var어떤 경우에는 코드를 더 읽기 쉽게 만들 수 있다고 생각 합니다. Orders 속성이있는 Customer 클래스가 있고이를 변수에 할당하려면 다음과 같이하십시오.

var orders = cust.Orders;

Customer.Orders가인지 상관하지 않습니다 IEnumerable<Order>. ObservableCollection<Order>또는 BindingList<Order>원하는 것은 목록을 메모리에 유지하여 목록을 반복하거나 나중에 계산하는 것입니다.

위의 선언을 다음과 대조하십시오.

ObservableCollection<Order> orders = cust.Orders;

나에게 유형 이름은 소음입니다. 그리고 돌아가서 Customer의 유형을 변경하기로 결정하면 (예 : ObservableCollection<Order>에서 IList<Order>) 추적 을 선언해야합니다. 첫 번째에서 var를 사용하면 수행 할 필요가없는 선언도 변경해야합니다. 장소.

var폭넓게 사용 하고 있습니다. 이것이 코드의 가독성을 떨어 뜨린다는 비판이 있지만, 그 주장을 뒷받침하는 주장은 없습니다.

물론, 우리가 다루는 유형이 명확하지 않다는 것을 의미 할 수 있습니다. 그래서 무엇? 이것은 실제로 분리 된 디자인의 요점입니다. 인터페이스를 다룰 때 변수의 유형에 크게 관심이 없습니다 . var나는 이것을 훨씬 더 진실로 받아들이지 만, 인수는 가독성 관점에서 동일하게 유지된다고 생각한다. 프로그래머는 실제로 변수의 유형에 관심을 두지 말고 변수 가 하는 것에 관심을 가져야한다 . 이것이 바로 Microsoft가 유형 추론을 "덕 타이핑"이라고 부르는 이유입니다.

그래서 변수를 사용하여 선언 할 때 변수는 무엇을 var합니까? IntelliSense가 알려주는 모든 작업을 쉽게 수행 할 수 있습니다. IDE를 무시하는 C #에 대한 추론은 실제로 부족합니다. 실제로 모든 C # 코드는 IntelliSense를 지원하는 IDE에서 프로그래밍됩니다.

var선언 된 변수를 사용 하고 변수가 무엇인지 혼동하면 코드에 근본적으로 문제가 있습니다. var원인이 아니라 증상 만 보이게합니다. 메신저를 비난하지 마십시오.

이제 C # 팀은 익명 형식을 생성하는 LINQ 문의 결과를 캡처하는 데만var 사용해야 하는 코딩 지침을 발표했습니다 (여기서는 실제 대안이 없습니다 ). 음, 나사로 조이십시오. C # 팀이이 가이드 라인에 대해 건전한 주장을하지 않는 한, 전문적이고 개인적인 견해로는 순수한 외롭기 때문에 무시할 것입니다. (죄송합니다. 해당 가이드 라인에 대한 링크가 없습니다.)var

실제로, 왜 당신이 사용하지 말아야하는지에 대한 (표면적으로) 좋은 설명이var 있지만 여전히 그것들이 크게 잘못되었다고 생각합니다. “searchabililty”의 예를 보자. 저자 는 사용 된 var장소를 찾기가 어렵다고 주장한다 MyType. 권리. 인터페이스도 마찬가지입니다. 실제로 왜 수업이 사용되는지 알고 싶습니까? 인스턴스화 된 위치에 더 관심이있을 수 있으며 생성자가 호출되어야하는 곳이기 때문에 여전히 검색 할 수 있습니다 (간접적으로 수행 된 경우에도 유형 이름을 어딘가에 언급해야 함).

내 의견으로는 C #에서 Var는 좋은 것입니다 ^tm . 이렇게 유형이 지정된 변수는 여전히 강력한 유형이지만 변수가 정의 된 할당의 오른쪽에서 유형을 가져옵니다. 유형 정보는 오른쪽에서 사용할 수 있기 때문에 대부분의 경우 왼쪽에서 입력해야하는 것은 불필요하고 너무 장황합니다. 나는 이것이 타입 안전성을 줄이지 않고 가독성을 크게 향상 시킨다고 생각합니다.

필자의 관점에서 변수와 메소드에 대한 좋은 명명 규칙을 사용하는 것이 명시 적 유형 정보보다 가독성 관점에서 더 중요합니다. 유형 정보가 필요한 경우 항상 변수 (VS) 위에 마우스를 가져 와서 얻을 수 있습니다. 그러나 일반적으로 독자에게 명시적인 유형 정보는 필요하지 않습니다. 개발자의 경우 VS에서는 변수 선언 방법에 관계없이 여전히 Intellisense를 얻습니다. 이 모든 것을 말했지만 유형을 명시 적으로 선언하는 것이 합리적 인 경우가 있습니다. 아마도를 반환하는 메소드가 List<T>있지만 유형을IEnumerable<T>당신의 방법으로. 인터페이스를 사용하고 있는지 확인하기 위해 인터페이스 유형의 변수를 선언하면이를 명시 적으로 만들 수 있습니다. 또는 초기 값없이 변수를 선언하려고합니다. 어떤 조건에 따라 즉시 값을 가져 오기 때문입니다. 이 경우 유형이 필요합니다. 유형 정보가 유용하거나 필요한 경우 계속 진행하십시오. 그러나 필자는 일반적으로 필요하지 않으며 대부분의 경우 코드가 없으면 코드를 쉽게 읽을 수 있다고 생각합니다.

그것들 중 어느 것도 절대 사실이 아닙니다. var가독성에 긍정적이고 부정적인 영향을 줄 수 있습니다. 제 생각 var에는 다음 중 하나에 해당하면 사용해야합니다.

1. 유형은 익명입니다 ( 이 경우 var 이어야 하므로 여기서 선택할 수 없습니다 )
2. 유형이 지정된 표현에 명백한 근거 (즉 var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var구문 설탕이므로 성능에 영향을 미치지 않습니다. 컴파일러는 형식을 유추하고 IL로 컴파일 된 후에 형식을 정의합니다. 실제로 역동적 인 것은 없습니다 .

C # 팀의 수석 소프트웨어 디자인 엔지니어 인 Eric Lippert

var키워드가 도입 된 이유는 무엇 입니까?

두 가지 이유가 있습니다. 하나는 오늘날 존재하며 다른 하나는 3.0에서 자랍니다.

첫 번째 이유는이 코드가 모든 중복성으로 인해 매우 추악하기 때문입니다.

Dictionary<string, List<int>> mylists = new Dictionary<string, List<int>>();

그리고 그것은 간단한 예입니다 – 나는 더 나빠졌습니다. 정확히 같은 것을 두 번 입력해야 할 때마다 그것은 우리가 제거 할 수있는 중복입니다. 쓰는 것이 훨씬 좋습니다

var mylists = new Dictionary<string,List<int>>();

그리고 컴파일러가 할당을 기반으로 유형이 무엇인지 알아 내도록하십시오.

둘째, C # 3.0은 익명 형식을 도입했습니다. 정의에 의해 익명의 종류에는 이름이 없기 때문에, 당신은 필요 의 유형은 익명 인 경우 초기화 표현에서 변수의 유형을 추론 할 수.

강조합니다. 전체 기사 C # 3.0은 여전히 ​​정적으로 유형이 정직합니다! 그리고 다음 시리즈 는 꽤 좋습니다.

이것은 무엇 var을위한 것입니다. 다른 용도로는 잘 작동하지 않을 수 있습니다. JScript, VBScript 또는 동적 타이핑과의 비교는 총 이층입니다. 참고 다시 var됩니다 필요한 .NET에서 기타 특정 기능이 작동을하기 위해.

var의 사용은 현명하게 선택된 변수 이름과 결합되어야한다고 생각합니다.

다음과 같은 경우 foreach 문에서 var를 사용하는 데 아무런 문제가 없습니다.

foreach (var c in list) { ... }

이 같은 경우 :

foreach (var customer in list) { ... }

... 코드를 읽는 사람은 "목록"이 무엇인지 이해할 가능성이 훨씬 높습니다. 리스트 변수 자체의 이름을 제어 할 수 있다면 더 좋습니다.

다른 상황에도 동일하게 적용될 수 있습니다. 이것은 쓸모가 없습니다.

var x = SaveFoo(foo);

... 그러나 이것은 의미가 있습니다.

var saveSucceeded = SaveFoo(foo);

각자 자신의 것으로 생각합니다. 나는 이것을하는 것을 발견했다.

var f = (float)3;

12 단계 var 프로그램이 필요합니다. 내 이름은 매트이고 나는 var를 사용합니다.

우리는 새로운 개발보다 유지 관리 모드에서 여러 번 더 오랜 시간을 소비한다는 가정을 바탕으로 "기계가 아닌 사람을위한 코드"라는 개념을 채택했습니다.

저에게는 컴파일러가 변수의 유형을 "알고있다"는 주장을 배제합니다. 컴파일러가 코드 컴파일을 중지하기 때문에 처음에는 잘못된 코드를 작성할 수 없지만 다음 개발자가 코드를 읽을 때 6 개월 만에 변수가 올바르게 또는 부정확하게 수행하는 작업을 추론하고 문제의 원인을 신속하게 파악할 수 있어야합니다.

그러므로,

var something = SomeMethod();

코딩 표준에 의해 금지되지만 가독성을 높이기 위해 팀에서 다음을 권장합니다.

var list = new List<KeyValuePair<string, double>>();
FillList( list );
foreach( var item in list ) {
   DoWork( item ); 
}

나쁘지 않고, 더 스타일리쉬 한 것으로 주관적인 경향이 있습니다. var를 사용하고 사용하지 않을 때 불일치를 추가 할 수 있습니다.

또 다른 우려 사항은 다음 호출에서 반환 된 유형을 코드로 확인하는 것만으로는 알 수 없습니다 CallMe.

var variable = CallMe();

그것은 var에 대한 나의 주요 불만입니다.

메서드에서 익명 대리자를 선언 할 때 var를 사용합니다. 어떻게하면 var를 사용하는 것보다 깨끗하게 보입니다 Func. 이 코드를 고려하십시오.

var callback = new Func<IntPtr, bool>(delegate(IntPtr hWnd) {
   ...
});

편집 : Julian의 입력을 기반으로 마지막 코드 샘플을 업데이트했습니다.

Var는 전혀 변형이 아닙니다. 변수는 여전히 강력하게 입력되었으므로 키를 누르지 않아도됩니다. Visual Studio에서 마우스를 가져 가면 유형을 볼 수 있습니다. 인쇄 된 코드를 읽는 경우 유형이 무엇인지 알아 내기 위해 약간의 생각이 필요할 수 있습니다. 그러나 그것을 선언하는 한 줄과 그것을 사용하는 많은 줄이 있으므로 적절한 이름을 지정하는 것이 여전히 코드를 더 쉽게 따르기위한 가장 좋은 방법입니다.

Intellisense 게으른 사용합니까? 이름보다 타이핑이 적습니다. 아니면 덜 일하지만 비판을받을 가치가없는 것들이 있습니까? 나는 있다고 생각하며 var는 그중 하나입니다.

가장 필요한 시간은 익명 유형 (100 % 필수) 인 경우입니다. 그러나 그것은 사소한 경우에도 반복을 피하고 IMO는 선을 더 명확하게 만듭니다. 간단한 초기화를 위해 유형을 두 번 볼 필요가 없습니다.

예를 들면 다음과 같습니다.

Dictionary<string, List<SomeComplexType<int>>> data = new Dictionary<string, List<SomeComplexType<int>>>();

(위의 hscroll을 편집하지 마십시오-요점을 증명합니다 !!!)

vs :

var data = new Dictionary<string, List<SomeComplexType<int>>>();

그러나 오해의 소지가있는 경우가 있으며 잠재적으로 버그가 발생할 수 있습니다. var원래 변수와 초기화 된 유형이 동일하지 않은 경우 사용에주의하십시오 . 예를 들면 다음과 같습니다.

static void DoSomething(IFoo foo) {Console.WriteLine("working happily") }
static void DoSomething(Foo foo) {Console.WriteLine("formatting hard disk...");}

// this working code...
IFoo oldCode = new Foo();
DoSomething(oldCode);
// ...is **very** different to this code
var newCode = new Foo();
DoSomething(newCode);

var가 어려운 특정 사례 : 오프라인 코드 검토, 특히 종이에서 수행 된 사례.

당신은 그것에 마우스 오버에 의존 할 수 없습니다.

큰 일이 무엇인지 모르겠습니다 ..

var something = someMethod(); // Type of 'something' not clear <-- not to the compiler!

당신은 여전히 ​​'무언가'에 대한 완전한 지식을 가지고 있으며 모호한 경우에 대해 단위 테스트를하고 있습니까? (그래요?)

varchar가 아니며 어둡지 않으며 동적이거나 약한 타이핑이 아닙니다. 다음과 같이 maddnes를 중지합니다.

List<somethinglongtypename> v = new List<somethinglongtypename>();

그리고 총 정신 마비를 줄이기 위해 :

var v = new List<somethinglongtypename>();

다음과 같이 좋지는 않습니다.

v = List<somethinglongtypename>();

그러나 그것은 Boo 를위한 것입니다.

var'유형 파악하기'를 원하지 않기 때문에 키워드를 사용하는 사람이라면 이는 잘못된 이유입니다. var동적 유형의 변수를 만들지 않습니다 키워드는, 컴파일러는 여전히 유형을 알고있다. 변수에는 항상 특정 유형이 있으므로 가능한 경우 코드에서 유형이 분명해야합니다.

var키워드 를 사용해야하는 좋은 이유 는 다음과 같습니다.

• 필요한 경우, 즉 익명 형식에 대한 참조를 선언합니다.
• 코드를 더 읽기 쉽게 만드는 곳, 즉 반복적 인 선언을 제거합니다.

데이터 유형을 작성하면 코드를 쉽게 따라갈 수 있습니다. 사용중인 데이터 유형을 보여 주므로 먼저 코드의 기능을 파악하여 데이터 유형을 파악할 필요가 없습니다.

Intellisense가 얼마나 강력한 지 감안할 때 var이 클래스에 멤버 변수를 가지고 있거나 보이는 화면 영역에서 정의 된 메소드에 로컬 변수를 갖는 것보다 읽기가 더 어렵다는 것을 확신하지 못합니다.

다음과 같은 코드가있는 경우

IDictionary<BigClassName, SomeOtherBigClassName> nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

다음보다 읽기가 훨씬 쉽거나 어렵습니다.

var nameDictionary = new Dictionary<BigClassName, SomeOtherBigClassName>();

VAR의 핵심은 적절한 곳에서만 사용하는 것입니다. 즉 Linq에서 작업을 수행 할 때 (그리고 아마도 다른 경우) 사용하는 것입니다.

당신이 무언가를위한 유형을 가지고 있다면 당신은 그것을 사용해야합니다-그렇게하지 않아야합니다 (일반적으로 권장되는 창조적 인 게으름과는 대조적으로)-좋은 프로그래머는 게으 르기 위해 열심히 일하지 않으며 고려 될 수 있습니다 처음에 물건의 출처).

블랭킷 금지는 처음부터 구조를 남용하는 것만 큼 좋지 않지만 합리적인 코딩 표준이 필요합니다.

기억해야 할 또 다른 점은 유형을 변경할 수 있다는 점에서 그 아닌 VB 형 VAR이 있다는 것입니다 - 그것은 이다 강력한 형식의 변수의 유형은 (추정되고 그냥있는 그것의 불합리하지 주장합니다 사람들이 왜 예를 들어 foreach에서 사용하지만 가독성과 유지 보수성의 이유로 동의하지 않습니다).

나는 이것이 실행될 것이라고 생각합니다 (-:

머프

물론, int쉽지만 변수의 유형이 IEnumerable<MyStupidLongNamedGenericClass<int, string>>이면 var가 훨씬 쉬워집니다.

CodingHorror 에서이 문제에 대한 게시물에서 도난 당했습니다 .

불행히도, 당신과 다른 사람들은 거의 잘못했습니다. 중복성이 좋지 않다는 점에 동의하지만이 문제를 해결하는 더 좋은 방법은 다음과 같은 작업을 수행하는 것입니다.

2008 년 6 월 20 일 Nicholas Paldino .NET / C # MVP 08:00 AM

당신의 주된 관심사가 덜 타이핑 해야하는 것 같아요-당신이 그것을 사용하지 못하게하는 논쟁은 없습니다.

당신은 단지하려는 경우 지금 다음, 코드에서 누가 염려를 보이는 사람이? 그렇지 않으면 다음과 같은 경우에 :

var people = Managers.People

괜찮지 만 다음과 같은 경우에는

var fc = Factory.Run();

그것은 뇌가 코드의 '영어'로부터 형성되기 시작할 수있는 모든 즉각적인 유형 공제를 단락시킵니다.

그렇지 않으면 프로젝트를 수행해야하는 다른 사람들을 위해 최선의 판단과 프로그래밍 '예의'를 사용하십시오.

사용 var하는 대신 명시 적 유형은 리팩토링 훨씬 쉽게 (그러므로 나는 그것이 차이를하지 않거나 순수하게 "문법 설탕"의미했다 이전 포스터를 부정한다)한다.

이 메소드가 호출되는 모든 파일을 변경하지 않고 메소드의 리턴 유형을 변경할 수 있습니다. 상상 해봐

...
List<MyClass> SomeMethod() { ... }
...

다음과 같이 사용됩니다

...
IList<MyClass> list = obj.SomeMethod();
foreach (MyClass c in list)
  System.Console.WriteLine(c.ToString());
...

SomeMethod()을 반환 하기 위해 리팩토링 하려는 경우 메소드를 사용한 모든 위치에서 IEnumerable<MySecondClass>변수 선언 ()을 변경해야합니다 foreach.

당신이 쓰는 경우

...
var list = obj.SomeMethod();
foreach (var element in list)
  System.Console.WriteLine(element.ToString());
...

대신 변경하지 않아도됩니다.

@ 아쿠 : 예제는 코드 리뷰입니다. 또 다른 예는 리팩토링 시나리오입니다.

기본적으로 마우스로 유형 사냥을하고 싶지 않습니다. 사용하지 못할 수 있습니다.

맛의 문제입니다. 변수 유형 에 대한이 모든 소란은 동적으로 유형이 지정된 언어에 익숙해지면 사라집니다. 즉, 경우 혹시 그들처럼에 시작 (모든 사람이 할 수 있는지 확실하지 않습니다,하지만 난 할).

C 번호의 var꽤는 점에서 냉각되어 보이는 실제로 동적 타이핑처럼,하지만은 정적 타이핑 - 컴파일러는 올바른 사용법을 적용합니다.

변수의 유형은 실제로 그렇게 중요하지 않습니다 (이전에 언급되었습니다). 문맥 (다른 변수 및 메소드와의 상호 작용)과 이름에서 상대적으로 분명해야합니다. customerList 에 int...

나는 여전히 사장님이이 문제에 대해 어떻게 생각하는지 기다리고 있습니다. 3.5에서 새로운 구조를 사용하기 위해 "앞으로 나아가는 담요"를 얻었지만 유지 관리에 대해 어떻게해야합니까?

사이 비교 IEnumerable<int>하고 IEnumerable<double>당신은 걱정할 필요가 없습니다 - 당신은 당신의 코드가 어쨌든 컴파일되지 않습니다 잘못된 유형을 통과합니다.

동적 var이 아니기 때문에 타입 안전에 대해 걱정할 필요 가 없습니다 . 그것은 단지 컴파일러의 마술 일 뿐이며 안전하지 않은 호출은 모두 잡히게됩니다.

Var Linq에 절대적으로 필요합니다.

var anonEnumeration =
    from post in AllPosts()
    where post.Date > oldDate
    let author = GetAuthor( post.AuthorId )
    select new { 
        PostName = post.Name, 
        post.Date, 
        AuthorName = author.Name
    };

이제 지능형 으로 anonEnumeration 을 보면 다음과 같이 나타납니다.IEnumerable<'a>

foreach( var item in anonEnumeration ) 
{
    //VS knows the type
    item.PostName; //you'll get intellisense here

    //you still have type safety
    item.ItemId;   //will throw a compiler exception
}

C # 컴파일러는 매우 영리합니다. 개별적으로 생성 된 anon 유형은 속성이 일치하는 경우 동일한 생성 유형을 갖습니다.

그 외에는, 지능이 var있는 한 문맥이 분명한 곳에서 사용하는 것이 좋습니다 .

//less typing, this is good
var myList = new List<UnreasonablyLongClassName>();

//also good - I can't be mistaken on type
var anotherList = GetAllOfSomeItem();

//but not here - probably best to leave single value types declared
var decimalNum = 123.456m;

나는 그것이 당신의 관점에 달려 있다고 생각합니다. 나는 개인적으로 var"오용"으로 인해 코드 조각을 이해하는 데 어려움을 겪지 않았으며 동료들과 나는 그것을 아주 많이 사용합니다. (나는 Intellisense가 이와 관련하여 큰 도움이된다는 것에 동의합니다.) 나는 반복적 인 균열을 제거하는 방법으로 그것을 환영합니다.

결국 if 문이

var index = 5; // this is supposed to be bad

var firstEligibleObject = FetchSomething(); // oh no what type is it
                                            // i am going to die if i don't know

실제로 처리하기가 불가능했기 때문에 아무도 동적으로 유형이 지정된 언어를 사용하지 않습니다.

사용되는 유형이 분명한 경우에만 var를 사용합니다.

예를 들어,이 경우 var를 사용합니다. x가 "MyClass"유형이라는 것을 즉시 알 수 있기 때문입니다.

var x = new MyClass();

마우스를 코드 위로 드래그하고 툴팁을보고 MyFunction이 리턴하는 유형을 확인해야하기 때문에 var를 사용하지 않을 것입니다.

var x = MyClass.MyFunction();

특히, 나는 결코 오른쪽도 방법,하지만 값이없는 곳의 경우 VAR를 사용하지 :

var x = 5;

(컴파일러가 바이트, 짧은, 정수 또는 기타를 원하는지 알 수 없기 때문에)

나에게있어서의 반감 var은 왜 .NET의 이중 언어가 중요한지를 보여줍니다. VB .NET을 수행 한 C # 프로그래머에게는 이점 var이 직관적으로 분명합니다. 다음의 표준 C # 선언 :

List<string> whatever = new List<string>();

VB .NET에서 다음을 입력하는 것과 같습니다.

Dim whatever As List(Of String) = New List(Of String)

그러나 VB .NET에서는 아무도 그렇게하지 않습니다. .NET의 첫 번째 버전 이후 로이 작업을 수행 할 수 있었기 때문에 어리석은 일입니다 ...

Dim whatever As New List(Of String)

... 변수를 만들고 합리적으로 콤팩트 한 줄로 모두 초기화합니다. 아,하지만 당신은 무엇을 원하는 경우 IList<string>A는하지 List<string>? VB .NET에서는 다음과 같이해야합니다.

Dim whatever As IList(Of String) = New List(Of String)

C #에서해야 할 것처럼 분명히 사용할 수는 없습니다 var.

IList<string> whatever = new List<string>();

이 경우 필요 뭔가 다른 일을 유형을, 그것은 할 수 있습니다. 그러나 좋은 프로그래밍의 기본 원칙 중 하나는 중복성을 줄이는 것입니다. 이것이 바로 var의 역할입니다.

익명 유형에 사용하십시오-그것이 거기에 있습니다. 다른 것은 너무 많이 사용됩니다. C에서 자란 많은 사람들처럼, 나는 유형에 대한 선언의 왼쪽을 보는 데 익숙합니다. 내가하지 않으면 오른쪽을 보지 않습니다. 사용 var오래된 선언 나를 그렇게 만드는 개인적으로 불편 찾을 모든 시간.

'중요하지 않습니다, 당신이 좋아하는 것을 사용하십시오'라고 말하는 사람들은 전체 그림을 보지 않습니다. 모든 사람은 다른 사람의 코드를 한 지점에서 다른 곳으로 가져 와서 작성 당시에 내린 결정을 처리해야합니다. var믹스에 전체 '아니오'를 추가하지 않고 근본적으로 다른 명명 규칙 또는 고전적인 그립 스타일을 다루는 것만으로는 충분 하지 않습니다. 최악의 경우는 한 프로그래머가 사용하지 않은 var다음 그것을 좋아하는 관리자가 와서 그것을 사용하여 코드를 확장하는 것입니다. 그래서 이제 당신은 거룩하지 않습니다.

표준은 정확히 좋은 것입니다. 왜냐하면 임의의 코드를 집어 들고 신속하게 처리 할 수있는 가능성이 훨씬 높기 때문입니다. 다른 것들이 많을수록 더 어려워집니다. 그리고 'var var'스타일로 옮기는 것이 큰 차이를 만듭니다 .

나는 동적 타이핑을 신경 쓰지 않으며, 그것들을 위해 설계된 언어로 타이핑을 함축하지는 않습니다. 나는 파이썬을 아주 좋아합니다. 그러나 C #은 정적으로 명시 적으로 형식화 된 언어로 설계되었으므로 그대로 유지됩니다. 익명 유형에 대한 규칙을 어기는 것은 충분히 나빴습니다. 사람들이 여전히 그것을 더 받아들이고 언어의 관용구를 더 많이 깨 뜨리게하는 것은 내가 좋아하지 않는 것입니다. 지니가 병에서 나왔으므로 다시는 들어 가지 않을 것입니다. C #은 캠프로 발칸 화됩니다. 안좋다.

테스트하는 동안 여러 시간 동안 나는 다음과 같은 코드를 가지고 있음을 알았습니다.

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();
Console.WriteLine(something);

때로는 SomeOtherThing 자체에 무엇이 포함되어 있는지 확인하고 싶을 때 SomeOtherThing은 CallMethod ()가 반환하는 것과 같은 유형이 아닙니다. var를 사용하고 있기 때문에 다음과 같이 변경합니다.

var something = myObject.SomeProperty.SomeOtherThing.CallMethod();

이에:

var something = myObject.SomeProperty.SomeOtherThing;

var가 없으면 왼쪽에서 선언 된 유형을 계속 변경해야합니다. 나는 그것이 사소한 것을 알고 있지만 매우 편리합니다.

var시간을 절약 한다고 생각하는 애호가들에게는 키 입력이 줄어 듭니다.

StringBuilder sb = new StringBuilder();

...보다

var sb = new StringBuilder();

당신이 나를 믿지 않으면 그들을 계수 ...

19 대 21

내가해야 할 경우 설명하지만 그냥 시도해보십시오 ... (지능의 현재 상태에 따라 각각에 대해 몇 가지를 더 입력해야 할 수도 있습니다)

그리고 당신이 생각할 수있는 모든 유형에 대해 사실입니다 !!

내 개인적인 느낌은 var가 코드에서 인식 가능성을 줄이기 때문에 유형을 알 수없는 경우를 제외하고는 var를 사용해서는 안된다는 것입니다. 전체 라인보다 유형을 인식하는 데 뇌가 더 오래 걸립니다. 기계 코드와 비트를 이해하는 오래된 타이머는 내가 말하는 것을 정확히 알고 있습니다. 뇌는 병렬로 처리되며 var를 사용할 때 입력을 직렬화하도록 강제합니다. 왜 누군가가 뇌를 더 열심히 일하고 싶습니까? 그것이 컴퓨터를위한 것입니다.

모든 장소에 걸쳐 I 분할 VAR, 나를 위해 유일한 의심 장소 내부 짧은 유형은, 예를 들어, 내가 선호 int i = 3;이상var i = 3;

어제 작성한 코드로 확실히 간단하게 만들 수 있습니다.

var content  = new Queue<Pair<Regex, Func<string, bool>>>();
...
foreach (var entry in content) { ... }

이 없이는 매우 장황하다 var.

부록 : 실제 형식 추론 이있는 언어 (예 : F #) 에서 약간의 시간을 보내면 컴파일러가 식 유형을 올바르게 얻는 방법을 알 수 있습니다. 그것은 var내가 가능한 한 많이 사용하는 경향이 있음을 의미 했으며, 명시 적 유형을 사용하면 변수가 초기화 식의 유형이 아님을 나타냅니다.

유형 이름을 두 번 쓸 필요가 없다는 점을 제외하고는 없습니다. http://msdn.microsoft.com/en-us/library/bb383973.aspx