Visual Studio의 기본 네임 명명 규칙과 싸움을 중지해야합니까?

Visual Studio의 기본 네임 명명 규칙과 싸움을 중지해야합니까?

---

MVVM 프로젝트에서 작업 중 Models, ViewModels, Windows 제안 같은 프로젝트에 폴더가 있습니다. 새 클래스를 만들 때마다 Visual Studio는 프로젝트를 유지하는 대신 네임 스페이스 지정에 폴더 이름을 자동으로 추가합니다. 레벨 네임 스페이스. 따라서 스페이스 초래 폴더 ViewModels에 새 클래스를 추가하는 MyProject.ViewModels대신의 MyProject.

처음 만났을 때 짜증이났다. 내 클래스 이름은 매우 명확하며, 폴더 이름이 포함되어 있습니다. (예 :) ContactViewModel. 나는 네임 스페이스에서 폴더 이름을 수동으로 제거하는 것을 빨리 발견했습니다. 한 지점에서 사용자 지정 클래스 템플릿을 만들려고 시도했지만 ( 이 질문 참조 ) 작동하지 않아 수동으로 계속했습니다.

그래도이 내가 볼 수없는 좋은 이유 때문에 존재하는지 궁금해지기 시작했습니다. 어떤 것이 든 폴더로 구성된 클래스 이름 세트가 많은 경우 유용하다는 것을 알 수 있습니다.

질문 :

• 네임 스페이스 이름이 폴더 구조를 반영하는 것이 일반적인 규칙 인 이유는 무엇입니까?
• 이 대회를 지키세요? 왜?

---

너와 똑같아-나는 가장 오랫동안 싸웠다. 그런 다음 폴더를 만든 이유를 고려하기 시작했습니다. 임의의 버킷 대신 네임 스페이스와 패키지를 대규모 폴더를 만들기 시작했습니다.

예를 들어 MVVM 프로젝트에서 뷰와 뷰 모델을 별도의 네임 스페이스에 두는 것이 유용 할 수 있습니다. MVC에는 모델, 별도의 네임 스페이스가 있습니다. 기능별로 클래스를 그룹화하는 것도 유용합니다.

갑자기 프로젝트가 더 조직적으로는 한 번에 죽습니다. 다른 개발자가 기능이 구현 된 위치를 더 찾을 수 있습니다.

네임 스페이스 관행을 표준화하면 모든 프로젝트가 동일한 예측 가능한 구조를 사용되어 유지 관리에 큰 도움이됩니다.

---

확실한 조언이 필요하다면 프레임 워크 디자인 기능 : 가능한 .NET 라이브러리에 대한 규칙, 관용구 및 패턴을 구입하는 것이 좋습니다 .이 가이드 는 실제 프레임 워크 디자인 팀에서 필요한 모든 것을 제공합니다.

... 네임 스페이스 이름을 만들 때의 목표는 프레임 워크를 사용하는 프로그래머가 네임 스페이스의 내용이 무엇인지 즉시 알 수 있습니다.

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

그리고 중요하게

스페이스와 해당 네임 스페이스의 유형에 동일한 이름을 사용 하지 않습니다.

모든 1/2 유형을 네임 스페이스로 조각화하는 것은 Visual Studio 방식을 따랐을 경우 정규화하거나 사용하는 네임 스페이스가 많기 때문에 첫 번째 요구 사항을 말할 것도 없습니다. 예를 들면

핵심-도메인-사용자-권한-계정

당신은 만들 겠겠습니까?

• MyCompany.Core.Domain.Users
• MyCompany.Core.Domain.Permissions
• MyCompany.Core.Domain.Accounts

아니면 그냥

• MyCompany.Core.Domain

Visual Studio의 경우 전자가 될 것입니다. 또한 소문자 파일 / 폴더 이름 지정을 사용하는 경우 매번 클래스 이름을 변경하고 하나의 큰 네임 스페이스 엉킴을 만드는 방법을 살펴 봅니다.

그것의 대부분은 당신이 조직 네임 스페이스 보여야하는데 진짜로 상식이고 당신은 자신의 API 또는 프레임 워크의 소비자가 있습니다.

---

나는 이것에 짜증이 났지만 민족 코드베이스로 프로젝트를 작업하고 리팩토링하면 다른 방법으로 빠르게 배웠습니다. 이 개념을 수용 한 나는 "물리적으로"코드를 구조화하는 아주 좋은 방법이라고 생각합니다. 큰 프로젝트가 있고 네임 스페이스가 폴더와 일치하지 파일을 빨리 찾기가 어려워집니다. 또한 사물이 어디에 있는지 기억하기 훨씬 더 어렵습니다.

또한 ReSharper가 권장한다면 아마도 좋은 생각 일 것입니다. 예를 들어 R #은 클래스의 네임 스페이스가 폴더 이름과 일치하지 이름합니다.

---

파일 시스템 폴더와 네임 스페이스는 모두 계층을 나타냅니다. 나는 두 사람을 맞추는 것이 완벽하게 자연스러워 시청합니다. 한 단계 더 나아가 파일과 클래스 1 : 1 관계를 사용합니다. C ++와 같은 다른 언어로 프로그래밍 할 때도 그렇게합니다.

이제는 두 계층 사이의 관계에 대해 질문 했어 파일 시스템 계층으로 무엇을 표현하고 싶은지 진지하게 궁금합니다.

---

규칙을 따르지 않는 한 가지 방법은 프로젝트 루트 폴더에 파일을 만든 다음 하위 하위 폴더로 이동하는 것입니다.

어쨌든 실제로 좋아하는입니다. 유형을 폴더로 분할하는 경우 해당 유형에는 폴더와 관련된 개념적 그룹이 있습니다. 따라서 어느 정도 의미가 고유 네임 스페이스도 준비합니다. Java는 접근 방식을 취하고 패키지 시스템에 적용됩니다. 가장 큰 차이점은 VS는 언어 나 CLR이 적용되지 않기 때문에 사용자에게 "제안"할 뿐이라는 것입니다.

---

음성 구조와 일치하는 물리적 구조가 도움이되는 모든 사람들의 의견에 동의하지만 Visual Studio의 자동 이름 지정과 싸우고 있습니다. 클래스 이름을 변경해야하는 이유는 6 가지입니다.

• 루트 "src"폴더를 사용하여 포함 된 리소스에서 코드를 분리합니다.
• 다른 대문자를 원합니다
• 네임 스페이스 내에서 구성 할 수 추가 코드를 하위 폴더로 구성하겠습니다.
• 구현 및 기본 클래스에서 인터페이스를 분리하는 것을 좋아합니다.
• 기분이 좋아

나는 제가 제가 만드는 모든 수업에 대해 조정해야하는 일을 그만 두었습니다. 이 문제를 방지하기위한 전략은 원하는 네임 스페이스 선언이있는 파일을 복사 한 다음 즉시 내용을 삭제하는 것입니다.

---

C ++에서 네임 스페이스가 도입되기 전에는 모든 C 유형이 전역 네임 스페이스에있었습니다. 이름 공간은 유형을 논리적 컨테이너로 분리하기 위해 만들어 졌으므로 어떤 유형이 참조되고 있는지 명확하게 알 수 있습니다. 이것은 C #에도 적용됩니다.

어셈블리는 배포 결정입니다. .Net 프레임 워크를 보면 주어진 어셈블리에 여러 개의 서로 다른 네임 스페이스가 포함됩니다.

폴더는 디스크에 파일을 정리하는 것입니다.

이 세 가지는 서로 관련이 없지만 어셈블리 이름, 네임 스페이스 및 폴더 이름이 동일한 것이 편리합니다. Java는 폴더와 네임 스페이스를 동일한 것으로 축소합니다 (개발자의 파일 및 네임 스페이스 구성 자유를 제한 함).

종종 우리는 프로젝트의 파일을 여러 폴더로 구성하기로 선택합니다. 저나 제 팀이 파일을 더 쉽게 탐색 할 수 있기 때문입니다. 일반적으로이 파일 구성은 우리가 사용하는 네임 스페이스 디자인과 관련이 없습니다. VS 팀이 네임 스페이스를 폴더 이름과 동일하게 기본 설정하지 않거나 적어도 이것이 기본값이되지 않도록 옵션을 다시 제공하지 않기를 바랍니다.

새 클래스의 템플릿을 변경하거나 새 파일이 생성 된 후에 네임 스페이스를 수정하십시오.

---

또한 Visual Studio에서이 '기본'동작으로 고통을 느낍니다.

Visual Studio는 LinqToSql .dbml파일을 자체 디렉터리에 넣을 때 네임 스페이스 / 디렉터리 일치를 설정하려고합니다 . 를 편집 할 때마다 다음 사항 .dbml을 기억해야합니다.

• .dbml.designer.cs파일 열기
• namespace선언 에서 디렉토리 / 폴더 이름을 제거하십시오.

하지만 이 동작 을 중지 하는 방법 이 있습니다 . 여기에는 사용자 정의 클래스 템플릿 생성이 포함됩니다.

---

네임 스페이스와 프로젝트 폴더에 대해 서로 다른 구조를 갖는 데는 실제로 타당한 이유가 있다고 생각합니다. 라이브러리를 개발하는 경우 네임 스페이스 구조는 무엇보다 먼저 API 사용자에게 서비스를 제공 해야합니다. 논리적이고 이해하기 쉬워야합니다. 반면에 폴더 구조는 주로 API 설계자 인 여러분의 편의 를 위해 존재해야합니다.. 일부 목표는 구조도 논리적이어야한다는 점에서 매우 유사합니다. 그러나 툴링을 위해 관련 파일을 빠르게 선택할 수 있거나 탐색하기 쉬운 것과 같은 다른 파일이있을 수도 있습니다. 예를 들어 저는 특정 파일 임계 값에 도달하면 새 폴더를 만드는 경향이 있습니다. 그렇지 않으면 찾고있는 파일을 찾는 데 너무 오래 걸립니다. 그러나 디자이너의 선호도를 존중한다는 것은 네임 스페이스를 엄격하게 따르는 것을 의미 할 수도 있습니다.

그래서 전반적으로, 많은 경우에 둘 다 일치하는 것이 타당하지만, 이탈 할 유효한 경우가 있다고 생각합니다.

과거에 저에게 도움이 된 것은 한곳에 파일 (예 : WPF UserControl)을 만들어 네임 스페이스를 올바르게 만든 다음 "오른쪽"폴더로 이동하는 것이 었습니다.

---

네임 스페이스 계층 구조를 폴더 계층 구조와 일치시키는 것이 편리하고 좋은 생각이라는 데 동의하지만 Visual Studio가이 기능을 해제하는 것을 지원하지 않는 것 같다는 사실은 역겨운 일이라고 생각합니다. Visual Studio에는 많은 응용 프로그램이 있으며 완벽한 코딩 스타일과 소스 파일 폴더를 구성하는 방법이 많이 있습니다.

네임 스페이스에 속하는 수천 개의 파일이 있지만 프로그래머가 계층 구조를 더 쉽게 탐색 할 수 있도록 폴더로 그룹화하려고한다고 가정 해 보겠습니다. 이게 정말 나쁜 생각인가요? 이로 인해 유지 관리가 너무 어려워서 IDE에서 금지해야할까요 ???

Visual Studio를 사용하여 Unity와 함께 작업한다고 가정 해 보겠습니다. 이제 모든 스크립트는 "Assets.Scripts"네임 스페이스에 있습니다. 현재 스크립트가없는 쓸모없는 에셋 네임 스페이스가있을뿐만 아니라 "Assets.Scripts"는 의미가 없습니다. 소스 파일이 속한 프로젝트 또는 프로젝트의 일부를 설명하지 않습니다. 쓸모없는.

참고 URL : https://stackoverflow.com/questions/1289425/should-i-stop-fighting-visual-studios-default-namespace-naming-convention