더 넓은 질문 :
그러한 표준이 부과되는 것을 들어 본 적이 있습니까? 그렇다면 그 이유는 무엇입니까?
예, 들었습니다. 정규화 된 객체 이름을 사용하면 이름 충돌이 방지됩니다. 드물기는하지만, 일어날 때 예외적으로 가시적 일 수 있습니다.
예 :
해당 유형의 시나리오는 예를 통해 더 잘 설명 될 수 있습니다.
Lists<T>두 개의 별도 프로젝트에 속하는 두 가지가 있다고 가정 해 봅시다 .
System.Collections.Generic.List<T>
MyCorp.CustomCollections.Optimized.List<T>
정규화 된 개체 이름을 사용할 때 어떤 개체 List<T>가 사용되고 있는지 분명 합니다. 그 선명도는 명백하게 자세한 정보를 요구합니다.
그리고 당신은 "잠깐만! 아무도 그런 목록을 사용하지 않을 것입니다!" 유지 보수 시나리오를 지적 할 곳입니다.
Foo회사에서 승인하고 최적화 한 회사를 사용하는 회 사용 모듈 을 작성했습니다 List<T>.
using MyCorp.CustomCollections.Optimized;
public class Foo {
List<object> myList = ...;
}
나중에 새 개발자가 수행 한 작업을 확장하기로 결정합니다. 회사의 표준을 알지 못하고 using블록 을 업데이트합니다 .
using MyCorp.CustomCollections.Optimized;
using System.Collections.Generic;
그리고 서둘러 상황이 어떻게 나빠지는지 알 수 있습니다.
이름이 같지만 동일한 프로젝트 내에서 서로 다른 네임 스페이스에 두 개의 독점 클래스가있을 수 있다는 점은 간단합니다. 따라서 .NET 프레임 워크 제공 클래스와의 충돌에 대한 우려가 아닙니다.
MyCorp.WeightsAndLengths.Measurement();
MyCorp.TimeAndSpace.Measurement();
현실 :
자, 이것이 대부분의 프로젝트에서 일어날 가능성 이 있습니까? 아니 정말. 그러나 입력이 많은 대규모 프로젝트를 수행 할 때는 폭발 할 가능성을 최소화하기 위해 최선을 다합니다.
여러 기고 팀이있는 대규모 프로젝트는 응용 프로그램 세계에서 특별한 종류의 짐승입니다. 다른 프로젝트에 불합리하게 보이는 규칙은 프로젝트에 대한 입력 스트림과 기여하는 규칙이 프로젝트의 지침을 읽지 않았을 가능성으로 인해 더 적절 해집니다.
두 개의 큰 프로젝트가 병합 될 때도 발생할 수 있습니다. 두 프로젝트에 모두 비슷한 이름의 클래스가있는 경우 한 프로젝트에서 다른 프로젝트로 참조를 시작할 때 충돌이 발생합니다. 또한 프로젝트가 너무 커서 리팩토링하지 않거나 경영진이 리팩토링에 소요되는 시간을 지원하기위한 비용을 승인하지 않습니다.
대안 :
당신이 묻지 않았지만 이것이 문제에 대한 훌륭한 해결책 이 아니라는 것을 지적 할 가치가 있습니다. 네임 스페이스 선언없이 충돌하는 클래스를 만드는 것은 좋지 않습니다.
List<T>특히 예약어로 취급해야하며 수업 이름으로 사용해서는 안됩니다.
마찬가지로, 프로젝트 내의 개별 네임 스페이스는 고유 한 클래스 이름을 갖도록 노력해야합니다. Foo()작업중 인 네임 스페이스를 다시 호출해야하는 것은 피해야 할 정신적 오버 헤드입니다. 갖는 또 다른 방법은 말했다 MyCorp.Bar.Foo()및 MyCorp.Baz.Foo()개발자 위로 피해야을 여행하는 것입니다.
다른 것이 없으면 모호성을 해결하기 위해 부분 네임 스페이스를 사용할 수 있습니다. 예를 들어 Foo()클래스 이름을 완전히 바꿀 수 없으면 부분 네임 스페이스를 사용할 수 있습니다.
Bar.Foo()
Baz.Foo()
현재 프로젝트의 구체적인 이유 :
해당 표준에 따라 현재 프로젝트에 주어진 특정 이유로 질문을 업데이트했습니다. 그것들을보고 토끼의 흔적을 따라 내려가 보자.
정규화 된 유형을 얻으려면 이름 위로 마우스를 가져가는 것이 번거 롭습니다. 항상 정규화 된 유형을 항상 표시하는 것이 좋습니다.
"수줍어?" 음 .. 아니야. 아마도 성가시다. 화면 포인터를 이동시키기 위해 몇 온스의 플라스틱을 움직이는 것은 번거롭지 않습니다 . 그러나 나는 산만하다.
이 추론은 다른 무엇보다 은폐처럼 보입니다. 필자는 응용 프로그램 내 클래스의 이름이 약하고 클래스 이름을 둘러싼 적절한 양의 의미 정보를 수집하기 위해 네임 스페이스에 의존해야한다고 생각합니다.
이것은 정규화 된 클래스 이름에 대한 정당화가 아니며, 부분적으로 정규화 된 클래스 이름을 사용하는 것에 대한 정당화 일 수 있습니다.
이메일로 전송 된 코드 스 니펫에는 완전한 이름이 없으므로 이해하기 어려울 수 있습니다.
이 (계속?) 추론은 클래스의 이름이 잘못되었다는 의심을 강화시킵니다. 다시 말해, 클래스 이름이 잘못되었다고해서 모든 것이 정규화 된 클래스 이름을 사용해야한다고 정당화되는 것은 아닙니다 . 클래스 이름을 이해하기 어려운 경우 정규화 된 클래스 이름으로 수정할 수있는 것보다 훨씬 잘못된 것이 있습니다.
Visual Studio 외부에서 코드를 보거나 편집 할 때 (예 : 메모장 ++) 정규화 된 유형 이름을 얻는 것은 불가능합니다.
모든 이유에서, 이것은 거의 내 음료를 뱉어 버렸습니다. 그러나 다시, 나는 떠난다.
팀이 왜 Visual Studio 외부에서 코드를 자주 편집하거나 보는지 궁금합니다 . 그리고 지금 우리는 네임 스페이스가 무엇을 제공 할 것인지에 대해 직교하는 정당화를보고 있습니다. 이것은 툴링 된 논증이지만, 네임 스페이스는 코드에 조직 구조를 제공하기 위해 존재합니다.
툴링이 제공 할 수있는 기능을 활용하지 않는 개발자와 함께 명명 규칙이 열악한 프로젝트처럼 들립니다. 그리고 이러한 실제 문제를 해결하기보다는 증상 중 하나에 대해 반창고를 치기 위해 정규 클래스 이름이 필요합니다. 나는 이것을 오도 된 접근법으로 분류하는 것이 안전하다고 생각합니다.
이름이 잘못 지정된 클래스가 있고 리팩토링 할 수 없다고 가정하면 정답은 Visual Studio IDE를 최대한 활용하는 것입니다. VS PowerTools 패키지와 같은 플러그인을 추가하는 것이 좋습니다. 그런 다음 AtrociouslyNamedClass()클래스 이름을 클릭하고 F12 키를 누르고 클래스 정의로 직접 이동하여 수행하려는 작업을 더 잘 이해할 수 있습니다. 마찬가지로 Shift-F12를 클릭하여 현재 사용해야하는 코드의 모든 지점을 찾을 수 있습니다 AtrociouslyNamedClass().
외부 툴링 문제와 관련하여 가장 좋은 방법은 중지하는 것입니다. 스 니펫이 참조하는 내용을 즉시 명확하게 알 수없는 경우 스 니펫을 이메일로주고받지 마십시오. Visual Studio 외부의 다른 도구는 팀이 필요로하는 코드와 관련된 인텔리전스가 없으므로 다른 도구를 사용하지 마십시오. 메모장 ++는 훌륭한 도구이지만이 작업에는 적합하지 않습니다.
따라서 귀하가 제시 한 세 가지 정당성에 대한 귀하의 평가에 동의합니다. "내가 생각할 수없는이 프로젝트에 대한 근본적인 문제가 있는데 이것이 바로 우리가 그 문제를 '고정한 방법'입니다." 그리고 그것은 분명히 당신을 위해 붉은 깃발 역할을 할 수있는 팀 내에서 더 깊은 문제를 말합니다.