저는 이런 상황에서 1번, 타입이 명시적이지 않아서 코드를 읽기 힘들다는 말이 선뜻 이해가 되지 않았습니다.
코드가 읽기 힘든 건 변수명이 모호할 때가 주 이유고 (여러가지가 있겠지만… ^^;)
지금 읽고 잇는 코드의 정확한 타입이 무엇인지 몰라 힘든 경우는 잘 없을 것이라고 생각했었습니다.
또한, 타입이 알고 싶을 때 변수명에 마우스를 올려두면 친철하게 정확한 타입을 알 수도 있습니다.
2번의 경우에는 댓글에도 말씀이 나온 Effective C#에서도 주의가 필요한 경우라고 했던거로 기억납니다.
그래서 저는 위에 말씀드린대로 기본타입은 타입을 명확히 선언하고 그 외는 var로 선언한다는 나름의 결론을 내려서 실천 중입니다. ㅋㅋ
new 키워드 뿐만 아니라 함수 호출 표현식에서도 함수 이름과 인자를 감싸는 괄호 사이에 공백 문자를 하나 두는 코딩 스타일(예: Foo (bar))이 있는데, 대체로 Mono나 Mono + Gtk#을 써서 만든 리눅스용 GUI 앱들의 코드가 그렇습니다.
Mono 쪽 사람들 중에 GNOME 프로젝트와 관계된 사람이 많고(Mono 창업자인 미겔 데 이카사가 GNOME 창업자이기도 하고 Xamarin 창업자이기도 하고 그렇습니다), GNOME 커뮤니티에서 Mono 와 C#으로 리눅스용 GUI 앱을 많이들 만들었기 때문에 GNOME C 코딩 스타일을 많이 따른 듯 합니다.
아, 그런데 궁극적으로 함수 이름과 여는 괄호 사이에 공백을 넣는 관행 자체는 아마도 GNU 코딩 표준이 GNOME C 코딩 스타일에도 영향을 준 것 같습니다.
메모장으로 코딩하는 일은 없겠지만, 현실적으로는 GitHub 등에서 코드 리뷰를 할 때는 IDE처럼 타입 정보를 띄워주는 툴팁이 제공이 안 되는 문제가 있어서, 저희 팀에서는 타입이 명확하게 드러나는 케이스(예: var foo = new Foo())가 아니면 var을 쓰지 않는 쪽으로 코딩 스타일을 맞추고 있습니다. (그 외에도 가끔 Vim으로 간단한 코드 수정을 하기도 하고요.)
요즘에는 코드 리뷰도 IDE 안에서 할 수 있게 진화하고 있어서 이 문제는 점점 완화될 것으로 보이지만, 개인적으로 간단한 코드 리뷰는 모바일에서도 할 때가 많아서 당분간은 이 스타일을 좀더 고수하고자 합니다.
var를 많이 사용하는 입장에서 var가 개발자가 예상하지 않는 타입으로 추론될 수 있다는 것을
이해한순간이 제겐 더 강한 임팩트가 있었나봅니다… ㅋㅋㅋ
다른건 잘 생각이 안나네요 ㅋㅋㅋㅋㅋ
오늘 퇴근하면 오랜만에 Effective C#에서 그 챕터를 다시 읽어봐야겠네요! ㅎㅎ
개발자가 예측하지 못하는 타입으로 추론하는 경우는 저는 우선 경험을 못했고,
var 써놓고 alt + enter로 자동완성 사용하시면 만사해결…? 입니다. (안정적인 타입 + 명시적인 타입 + 가독성은 취향)
전 자동완성 강추…!
전 이펙티브 C#은 안봤는데 var로 인해 성능이 문제가 될 수 있다고 하는 이유 중 예시를 하나 들은 것은 있는데,
IQueryable 타입으로 리턴하는 메서드에 대해 개발자가 명시적으로 IEnumerable 타입으로 받았을 경우 문제가 있다는 점인데요.
이 경우에도 var로 받아서 자동완성해주면 IQueryable로 잘 바꿔줍니다. ← 이것은 경험담
@suwoo 님, @Vincent 님이 말씀해주신 것처럼 LINQ 결과가 복잡한 케이스에서 IEnumerable로 리턴되든 IQueryable로 리턴되든 var로 퉁(?)칠수 있어서 편하게 사용하고 있는데요. (자동완성까지는 생각을 못해 봤네요~)
@hongminhee 님의 말씀처럼 리뷰어를 배려하거나 코드 가독성을 유지하는 차원에서 명시적으로 타입을 선언하는 것도 필요할 것 같다는 생각이 듭니다.
var v = new C() 방식이 C v = new() 방식보다 먼저 나온 것으로 기억하는데, 그래서 좀더 친숙한 것 같기도 하고요.
개인적으로는 데이터 처리를 할때 결과가 아닌 중간 과정의 타입으로 익명 타입을 쓰곤 하는데, var로 선언하면 IDE의 인텔리센스 도움을 받아가면서 불필요한 타입을 정의하지 않아도 되는 장점이 있는 것 같아요.
저는 개인적으로 깃헙 같은 데에서 코드 리뷰를 할 때,
타입이 안 보여서 답답했던 적은 딱히 없었던 거 같숨다.
어차피 디버깅 하면서 BP 찍어 볼 거 아닌데 소스코드 보는 타이밍에 타입에 대한 정보가 그렇게까지 중요한가 싶어요.
(극단적으로 말하자면, 타입 이름은 메서드 시그니처와 반환 타입 정도에 표시 되는거면 충분… 나머지는 딱히 필요 없…;;; )
오히려 타입 정보 보다는 변수 이름과 메서드 이름, 그리고 그것이 어떻게 구성되어 흘러가는 가를 한 눈에 알아볼 수 있게 정리하는 것이 훨씬 더 중요하다고 생각하는 편입니닷.
다시 한 번 곰곰히 생각해봐도,
변수로 선언되는 타입 이름이 안 보여서 답답했던 적은 없는 거 같은데…
(시그니처나 반환 타입을 맞추는 것을 제외하고, 변수 선언이나 할당에서 타입 이름이 안 보여서 답답한 적은 없는 거 같숨다.)
오히려 타입 정보 보다는 변수 이름과 메서드 이름, 그리고 그것이 어떻게 구성되어 흘러가는 가를 한 눈에 알아볼 수 있게 정리하는 것이 훨씬 더 중요하다고 생각하는 편입니닷.
이것도 하고 타입명시도 해주는 것이지요.
제가 명시적인 것을 좋아하는 성격이라 그런 걸 수도 있습니다.
제가 싫어하는 구문이
var result = objectMethod.GetXXX();
와 같이 어떤 메서드에 대해서 리턴형이 제대로 보이지 않을 경우입니다.
물론 지금 논점인 var c = new asdf(); 와 asdf c = new(); 와는 논점이 빗나가지만, 저는 이런 경우때문에 var를 그냥 쓰지말자고 스스로 컨벤션을 정하는 편입니다.
저는 var때문에 타입이 안보이면 좀 답답하고 막 다른 사람 소스 허락맡고 var를 자동완성으로 타입을 명시시키는 방식으로 수정한 적도 있습니다.
저는 단순히 쓰기 편해서 var v = new C(); 를 선호했습니다. 그러다 GitHub로 협업을하니 알게된 의견 입니다. C v = new();로 쓰자, “GitHub로 리뷰 할 때 var을 쓰면 IDE도움을 받을 수 없어 정확히 어떤 타입인지 알기 힘들다” 등등…이 였습니다. 즉 가능한 var을 자제하고 명시적으로 표현하자 입니다.
var isString? = IDontKnow; var what? = YouShouldFigureout
