C#에서 var 키워드 사용

Question

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 item in someList) { // ...보다 낫지 않습니다.} 동등합니다.

여기에는 유형 안전성에 대한 실질적인 우려가 있습니다. 예를 들어 해당 쿼리의 결과를 IEnumerable<int> 및 IEnumerable<double>을 허용하는 오버로드된 메서드에 배치하는 경우 호출자가 실수로 잘못된 유형을 전달할 수 있습니다.

var 하다 강력한 타이핑을 유지해야 하지만 문제는 실제로 유형이 정의에서 즉시 명백하지 않은 것이 위험한지 여부입니다. 이는 오버로드로 인해 실수로 잘못된 유형을 메서드에 전달할 때 컴파일러 오류가 발생하지 않을 수 있음을 의미할 때 확대됩니다.

Answer 1

나는 아직도 생각한다 var 어떤 경우에는 코드를 더 읽기 쉽게 만들 수 있습니다.Orders 속성이 있는 Customer 클래스가 있고 이를 변수에 할당하려는 경우 다음과 같이 하면 됩니다.

var orders = cust.Orders;

Customer.Orders가 다음과 같은지 여부는 상관하지 않습니다. IEnumerable<Order>, ObservableCollection<Order> 또는 BindingList<Order> - 내가 원하는 것은 해당 목록을 메모리에 유지하여 나중에 반복하거나 개수 등을 얻는 것입니다.

위 선언을 다음과 대조해 보세요.

ObservableCollection<Order> orders = cust.Orders;

나에게 유형 이름은 단지 소음일 뿐이다.그리고 돌아가서 고객 유형을 변경하기로 결정하면 다음 단계로 주문합니다(예: ObservableCollection<Order> 에게 IList<Order>) 그런 다음 해당 선언도 변경해야 합니다. 처음에 var를 사용했다면 수행할 필요가 없는 작업입니다.

Answer 2

나는 사용한다 var 널리.이로 인해 코드의 가독성이 떨어진다는 비판이 있었지만 그러한 주장을 뒷받침하는 주장은 없습니다.

물론 이는 우리가 어떤 유형을 다루고 있는지 명확하지 않다는 의미일 수 있습니다.그래서 뭐?이것이 실제로 분리된 디자인의 핵심입니다.인터페이스를 다룰 때는 다음과 같이 강조합니다. ~ 아니다 변수의 유형에 관심이 있습니다. var 이것은 훨씬 더 나아가 사실이지만 가독성 측면에서 주장은 동일하게 유지된다고 생각합니다.프로그래머는 실제로 변수의 유형이 아니라 변수가 무엇인지에 관심을 가져야 합니다. 하다.이것이 바로 Microsoft가 유형 추론을 "오리 타이핑"이라고 부르는 이유입니다.

그렇다면 변수를 사용하여 선언하면 변수는 무엇을 합니까? var?쉽습니다. IntelliSense가 지시하는 대로 수행됩니다.IDE를 무시하는 C#에 대한 추론은 현실에 미치지 못합니다.실제로 모든 C# 코드는 IntelliSense를 지원하는 IDE에서 프로그래밍됩니다.

내가 사용하는 경우 var 변수를 선언했는데 그 변수가 무엇을 위한 것인지 혼란스러워집니다. 내 코드에 근본적으로 문제가 있는 것입니다. var 원인은 아니고 증상만 눈에 띄게 됩니다.메신저를 비난하지 마십시오.

이제 C# 팀은 다음과 같은 코딩 지침을 발표했습니다. var ~해야 한다 오직 익명 형식을 생성하는 LINQ 문의 결과를 캡처하는 데 사용됩니다(여기서는 이에 대한 실제 대안이 없기 때문입니다). var).글쎄요, 그걸로 됐어요.C# 팀이 이 지침에 대해 타당한 주장을 하지 않는 한 저는 이를 무시하겠습니다. 왜냐하면 제 직업적, 개인적 견해로는 이 지침이 정말 헛소리이기 때문입니다.(죄송합니다;문제의 가이드라인에 대한 링크가 없습니다.)

실제로는 (표면적으로) 몇 가지가 있습니다. 좋은 설명 왜 사용하면 안 되는지에 대해 var 그러나 나는 아직도 그들이 대체로 틀렸다고 믿습니다."검색 가능성"의 예를 들어보겠습니다.저자는 다음과 같이 주장한다. var 장소를 검색하기 어렵게 만듭니다. MyType 사용.오른쪽.인터페이스도 마찬가지입니다.실제로 클래스가 어디에 사용되는지 알고 싶은 이유는 무엇입니까?인스턴스화되는 위치에 더 관심이 있을 수 있으며 생성자가 어딘가에서 호출되어야 하기 때문에 여전히 검색 가능합니다(간접적으로 수행되더라도 유형 이름은 어딘가에서 언급되어야 합니다).

Answer 3

내 생각에 Var는 C#에서 좋은 것^TM.이렇게 유형이 지정된 모든 변수는 여전히 강력한 유형이지만 해당 유형은 정의된 할당의 오른쪽에서 가져옵니다.유형 정보는 오른쪽에서 확인할 수 있으므로 대부분의 경우 왼쪽에도 입력해야 하는 것은 불필요하고 지나치게 장황합니다.나는 이것이 유형 안전성을 저하시키지 않으면서 가독성을 크게 향상시킨다고 생각합니다.

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

Answer 4

둘 중 어느 것도 절대적으로 사실이 아닙니다. var 가독성에 긍정적인 영향과 부정적인 영향을 모두 미칠 수 있습니다.내 생각에는, var 다음 중 하나가 참일 때 사용해야 합니다.

1. 유형은 익명입니다(음, 여기서는 선택의 여지가 없습니다. ~ 해야 하다 이 경우에는 var가 됩니다)
2. 유형은 할당된 표현식(예: var foo = new TypeWithAReallyLongNameTheresNoSenseRepeating())

var 구문 설탕이므로 성능에 영향을 미치지 않습니다.컴파일러는 유형을 추론하고 IL로 컴파일되면 유형을 정의합니다.아무것도 없어 실제로 그것에 대해 역동적입니다.

Answer 5

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에서 특정 다른 기능이 작동하도록 하기 위해.

Answer 6

나는 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 프로그램이 필요합니다.내 이름은 Matt이고 var를 (남용) 사용합니다.

Answer 7

우리는 새로운 개발보다 유지 관리 모드에 몇 배 더 많은 시간을 소비한다는 가정을 바탕으로 "기계가 아닌 사람을 위한 코드"라는 정신을 채택했습니다.

나에게 있어서 그것은 컴파일러가 변수의 유형을 "알고" 있다는 주장을 배제합니다. 물론 컴파일러가 코드 컴파일을 중지하기 때문에 처음에는 잘못된 코드를 작성할 수 없지만 다음 개발자가 코드를 읽을 때 6개월 안에 변수가 올바르게 작동하는지 또는 잘못 작동하는지 추론하고 문제의 원인을 신속하게 식별할 수 있어야 합니다.

따라서,

var something = SomeMethod();

우리 코딩 표준에 의해 불법이지만 가독성을 높이기 위해 우리 팀에서는 다음을 권장합니다.

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

Answer 8

나쁘지 않은데, 스타일에 더 가깝고 주관적인 경향이 있습니다.var를 사용할 때와 사용하지 않을 때 불일치가 추가될 수 있습니다.

또 다른 우려 사항은 다음 호출에서 반환된 유형의 코드를 보는 것만으로는 알 수 없다는 것입니다. CallMe:

var variable = CallMe();

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

메서드에서 익명 대리자를 선언할 때 var를 사용하는데, 어떻게든 var를 사용하는 것보다 더 깔끔해 보입니다. Func.다음 코드를 고려해보세요:

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

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

Answer 9

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

Intellisense를 사용하는 것이 게으른가요?전체 이름보다 타이핑 횟수가 적습니다.아니면 일이 적지만 비판받을 가치가 없는 것들이 있습니까?내 생각엔 그런 게 있다고 생각하는데, var도 그 중 하나입니다.

Answer 10

이것이 필요할 가능성이 가장 높은 때는 익명 유형(100% 필수)입니다.그러나 이는 또한 사소한 경우에 대한 반복을 방지하고 IMO는 경계를 더 명확하게 만듭니다.간단한 초기화를 위해 유형을 두 번 볼 필요가 없습니다.

예를 들어:

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

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

대:

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);

Answer 11

var가 어려운 구체적인 경우는 다음과 같습니다.오프라인 코드 검토, 특히 종이로 수행된 코드 검토.

마우스 오버에만 의존할 수는 없습니다.

Answer 12

큰일이 뭔지 모르겠네요..

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>();

그런데 그러면 그렇지요 우우 입니다.

Answer 13

누군가가 사용하고 있다면 var 키워드는 "유형 파악"을 원하지 않기 때문에 확실히 잘못된 이유입니다.그만큼 var 키워드는 동적 유형의 변수를 생성하지 않지만 컴파일러는 여전히 유형을 알아야 합니다.변수에는 항상 특정 유형이 있으므로 가능하면 해당 유형이 코드에서도 분명하게 나타나야 합니다.

사용하는 좋은 이유 var 키워드는 예를 들면 다음과 같습니다:

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

데이터 유형을 작성하면 코드를 더 쉽게 따라갈 수 있는 경우가 많습니다.사용 중인 데이터 유형이 무엇인지 표시하므로 먼저 코드의 기능을 파악하여 데이터 유형을 파악할 필요가 없습니다.

Answer 14

현재 Intellisense가 얼마나 강력한지를 고려하면 var가 클래스의 멤버 변수나 보이는 화면 영역 외부에 정의된 메서드의 로컬 변수를 갖는 것보다 읽기 어려운지 잘 모르겠습니다.

다음과 같은 코드 줄이 있는 경우

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

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

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

Answer 15

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

만약 당신이 갖다 그런 다음 무언가에 대한 유형을 사용해야 합니다. 그렇게 하지 않는 것은 단순한 게으름입니다(일반적으로 권장되는 창의적인 게으름과 반대). 좋은 프로그래머는 종종 게으르기 위해 열심히 일하며 게으름의 근원으로 간주될 수 있습니다. 우선).

전면적인 금지는 애초에 구조를 남용하는 것만큼 나쁘지만 합리적인 코딩 표준이 필요합니다.

기억해야 할 또 다른 점은 유형을 변경할 수 없다는 점에서 VB 유형 var가 아니라는 것입니다. ~이다 강력한 유형의 변수는 단지 유형이 유추된다는 것입니다(이것이 foreach에서 사용하는 것이 비합리적이지 않다고 주장하는 사람들이 있지만 가독성과 유지 관리성이라는 이유로 동의하지 않는 이유입니다).

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

머프

Answer 16

확신하는, int 쉽지만 변수 유형이 IEnumerable<MyStupidLongNamedGenericClass<int, string>>, var를 사용하면 작업이 훨씬 쉬워집니다.

Answer 17

에서 훔친 CodingHorror에 이 문제에 대한 게시물을 게시하세요.:

---

불행하게도 당신과 다른 모든 사람들은 거의 틀렸습니다.중복성이 좋지 않다는 점에는 동의하지만 이 문제를 해결하는 더 좋은 방법은 다음과 같은 작업을 수행하는 것이었습니다.

MyObject m = new();

또는 매개변수를 전달하는 경우:

개인 p = new("FirstName", "LastName);

새 객체를 생성할 때 컴파일러는 오른쪽이 아닌 왼쪽에서 유형을 추론합니다.이는 필드 선언에도 사용할 수 있다는 점에서 "var"에 비해 다른 장점이 있습니다(유용할 수 있는 다른 영역도 있지만 여기서는 다루지 않겠습니다).

결국 중복성을 줄이려는 의도는 아니었습니다.오해하지 마십시오. "var"는 C#에서 익명 유형/프로젝션에 매우 중요합니다. 그러나 여기서는 유형을 난독화하므로 여기서는 완전히 사용되지 않습니다(그리고 저는 오랫동안 이것을 말해왔습니다). 사용되고 있습니다.두 번 입력하는 것은 너무 자주 발생하지만 0번 선언하는 것은 너무 적습니다.

Nicholas Paldino .NET/C# MVP 2008년 6월 20일 오전 8시

---

당신의 주요 관심사가 타이핑을 적게 하는 것이라면, 그것을 사용하는 데 방해가 될 어떤 논쟁도 없을 것입니다.

너만 갈 예정이라면 항상 당신의 코드를 보는 사람이 되세요. 그러면 누가 신경쓰나요?그렇지 않은 경우에는 다음과 같습니다.

var people = Managers.People

괜찮습니다만, 다음과 같은 경우에는:

var fc = Factory.Run();

그것은 내 두뇌가 코드의 '영어'로부터 형성되기 시작할 수 있는 즉각적인 유형 추론을 단락시킵니다.

그렇지 않은 경우에는 프로젝트에 참여해야 할 다른 사람에 대해 최선의 판단과 프로그래밍 '예의'를 사용하십시오.

Answer 18

사용 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());
...

대신 변경할 필요가 없습니다.

Answer 19

@aku:한 가지 예는 코드 검토입니다.또 다른 예는 리팩토링 시나리오입니다.

기본적으로 나는 마우스로 활자 사냥하러 가고 싶지 않습니다.사용하지 못할 수도 있습니다.

Answer 20

그것은 맛의 문제입니다.이 모든 것에 대한 소란은 유형 동적 유형 언어에 익숙해지면 변수가 사라집니다.그건, 만약에 당신은 그들을 좋아하기 시작할 것입니다. (모두가 그럴 수 있을지는 모르겠지만 저는 그렇습니다).

C# var 그 점에서는 꽤 멋지다 외모 동적 타이핑과 비슷하지만 실제로는 공전 타이핑 - 컴파일러가 올바른 사용법을 적용합니다.

변수의 유형은 실제로 그렇게 중요하지 않습니다(이는 이전에 언급되었습니다).컨텍스트(다른 변수 및 메서드와의 상호 작용)와 이름에서 상대적으로 명확해야 합니다. 기대하지 마세요. 고객 목록 함유하다 int...

나는 여전히 내 상사가 이 문제에 대해 어떻게 생각하는지 기다리고 있습니다. 3.5의 새로운 구성을 사용할 수 있는 담요가 있지만 유지 관리에 대해서는 어떻게 해야 합니까?

Answer 21

귀하의 비교에서 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
    };

이제 보세요 anon열거 intellisense에서는 다음과 같이 나타납니다. 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 유형은 해당 속성이 일치하는 경우 동일한 생성 유형을 갖습니다.

그 외에는 Intellisense가 있는 한 사용하는 것이 좋습니다. 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;

Answer 22

나는 그것이 당신의 관점에 달려 있다고 생각합니다.저는 개인적으로 코드 조각을 이해하는 데 어려움을 겪은 적이 없습니다. 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

처리하기가 정말 불가능했기 때문에 누구도 동적 유형 언어를 사용하지 않을 것입니다.

Answer 23

나는 어떤 유형이 사용되는지 확실히 알 수 있을 때만 var를 사용합니다.

예를 들어, 이 경우에는 x가 "MyClass" 유형이라는 것을 즉시 확인할 수 있으므로 var를 사용합니다.

var x = new MyClass();

이와 같은 경우에는 var를 사용하지 않을 것입니다. 왜냐하면 코드 위로 마우스를 드래그하고 툴팁을 통해 MyFunction이 반환하는 유형을 확인해야 하기 때문입니다.

var x = MyClass.MyFunction();

특히, 나는 절대 오른쪽이 메서드도 아니고 값만인 경우에는 var를 사용하세요.

var x = 5;

(컴파일러는 내가 바이트, short, int 등을 원하는지 알 수 없기 때문입니다)

Answer 24

나에게는 그에 대한 반감이 var .NET의 이중 언어 사용이 중요한 이유를 보여줍니다.VB .NET도 사용해본 C# 프로그래머에게 VB .NET의 장점은 다음과 같습니다. 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>, 아니 List<string>?VB .NET에서는 다음을 수행해야 함을 의미합니다.

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

C#에서 해야 하는 것처럼 분명히 사용할 수 없었습니다. var 을 위한:

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

만약 너라면 필요 유형이 다를 수도 있습니다.그러나 좋은 프로그래밍의 기본 원칙 중 하나는 중복성을 줄이는 것입니다. 이것이 바로 var가 하는 일입니다.

Answer 25

익명 유형에 사용하세요. 그게 바로 그 목적입니다.다른 것은 너무 많이 사용됩니다.C에서 자란 많은 사람들처럼 나 역시 유형 선언의 왼쪽을 보는 데 익숙합니다.나는 꼭 필요한 경우가 아니면 오른쪽을 보지 않습니다.사용 var 오래된 선언이 있으면 항상 그렇게 하게 되기 때문에 개인적으로 불편하다고 생각합니다.

'상관없어, 마음에 드는 걸 쓰세요'라고 말하는 사람들은 전체 그림을 보지 못하는 것입니다.모든 사람은 어느 시점에서든 다른 사람의 코드를 집어들게 되며, 코드를 작성할 당시 내린 결정을 처리해야 합니다.완전히 다른 명명 규칙이나 - 고전적인 불만 - 전체 '를 추가하지 않고 버팀대 스타일을 처리해야 하는 것만으로도 충분하지 않습니다.var 아니면'이 혼합되어 있습니다.최악의 경우는 한 프로그래머가 사용하지 않은 경우입니다. var 그리고 그것을 좋아하고 그것을 사용하여 코드를 확장하는 관리자가 등장합니다.이제 당신은 불경한 혼란에 빠졌습니다.

표준은 좋은 것입니다. 왜냐하면 임의의 코드를 선택하고 신속하게 파악할 수 있는 가능성이 훨씬 더 높다는 것을 의미하기 때문입니다.다른 점이 많을수록 더 어려워집니다.그리고 'var Everywhere' 스타일로 전환하면 큰 차이점.

나는 동적 타이핑이나 암시적 타이핑(그들을 위해 설계된 언어)에 신경 쓰지 않습니다.저는 파이썬을 꽤 좋아합니다.그러나 C#은 정적으로 명시적으로 형식화된 언어로 설계되었으므로 그대로 유지되어야 합니다.익명 유형에 대한 규칙을 어기는 것만으로도 충분히 나빴습니다.사람들이 그것을 더 멀리 받아들이고 언어의 관용어를 더욱 깨뜨릴 수 있게 하는 것은 내가 만족하지 못하는 일입니다.이제 지니는 병 밖으로 나왔으니 다시는 들어갈 수 없습니다.C#은 진영으로 분열될 것입니다.안좋다.

Answer 26

테스트하는 동안 여러 번 다음과 같은 코드를 발견했습니다.

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가 없으면 왼쪽에서 선언된 유형도 계속 변경해야 합니다.사소하다는 것은 알지만 매우 편리합니다.

Answer 27

라고 생각하는 매니아들을 위해 var 시간이 절약되고, 입력하는 데 필요한 키 입력이 줄어듭니다.

StringBuilder sb = new StringBuilder();

~보다

var sb = new StringBuilder();

믿을 수 없다면 세어보세요...

19 대 21

필요하면 설명하겠지만 한번 시도해 보세요...(현재 인텔리센스 상태에 따라 각각에 대해 몇 가지를 더 입력해야 할 수도 있습니다)

그리고 그것은 당신이 생각할 수 있는 모든 유형에 해당됩니다!!

내 개인적인 느낌은 코드에서 인식 가독성을 떨어뜨리기 때문에 유형을 알 수 없는 경우를 제외하고는 var를 절대 사용해서는 안 된다는 것입니다.뇌는 한 줄 전체를 인식하는 것보다 유형을 인식하는 데 더 오랜 시간이 걸립니다.기계어와 비트를 이해하는 노련한 사람들은 내가 말하는 내용을 정확히 알고 있습니다.뇌는 병렬로 처리하며 var를 사용하면 입력을 직렬화하게 됩니다.왜 뇌가 더 열심히 작동하게 만들고 싶어할까요?그것이 바로 컴퓨터의 존재 이유입니다.

Answer 28

나는 var를 여기저기로 나누었습니다. 나에게 유일하게 의심스러운 부분은 내부 짧은 유형입니다.나는 선호한다 int i = 3; ~ 위에 var i = 3;

Answer 29

어제 작성한 코드를 사용하면 확실히 작업이 더 간단해질 수 있습니다.

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

그렇지 않았다면 이것은 매우 장황했을 것입니다. var.

부록:언어와 함께 약간의 시간을 보냈습니다. 진짜 유형 추론(예:F#)은 컴파일러가 표현식 유형을 올바르게 가져오는 데 얼마나 좋은지 보여줍니다.그것은 확실히 내가 사용하는 경향이 있다는 것을 의미했습니다. var 가능한 한 많이 사용하고 이제 명시적 유형을 사용하면 변수가 초기화 표현식 유형이 아니라는 것을 나타냅니다.

Answer 30

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