지시문을 사용하여 불필요한 C #을 제거해야하는 이유는 무엇입니까?

지시문을 사용하여 불필요한 C #을 제거해야하는 이유는 무엇입니까?

---

예를 들어 거의 필요하지 않습니다.

using System.Text;

항상 기본적으로 있습니다. 코드에 불필요한 using 지시문이 포함되어 있으면 응용 프로그램에서 더 많은 메모리를 사용한다고 가정합니다 . 그러나 내가 알아야 할 다른 것이 있습니까?

또한 동일한 using 지시문이 하나의 파일과 대부분 / 모든 파일에 사용되는 경우 어떤 차이가 있습니까?

---

편집 :이 질문은 객체가 범위를 벗어날 때 IDisposable.Dispose 메서드가 호출 되도록하여 리소스를 관리하는 데 도움이되도록 설계된 using 문 이라는 관련없는 개념에 관한 것이 아닙니다 . C #에서 "사용"사용을 참조하십시오 .

---

프로그램이 실행될 때 아무것도 변경되지 않습니다. 필요한 모든 것은 요청시로드됩니다. 따라서 해당 구문을 사용하더라도 실제로 해당 네임 스페이스 / 어셈블리에서 형식을 사용하지 않으면 구문을 사용하는 어셈블리가로드되지 않습니다.

주로 개인적인 취향을 위해 정리하는 것입니다.

---

코딩 기본 설정 외에 사용하지 않는 사용 / 네임 스페이스를 제거해야하는 몇 가지 이유 가 있습니다 .

• 프로젝트에서 사용하지 않는 using 절을 제거하면 컴파일러에서 확인할 유형의 네임 스페이스가 더 적기 때문에 컴파일 속도가 빨라질 수 있습니다. (확장자 메소드 때문에 C # 3.0의 경우 특히 그렇습니다. 컴파일러는 가능한 더 나은 일치, 제네릭 형식 유추 및 제네릭 형식과 관련된 람다 식에 대해 모든 네임 스페이스에서 확장 메서드를 검색해야합니다)
• 사용 된 네임 스페이스의 일부 유형과 이름이 같은 사용되지 않는 네임 스페이스에 새 유형이 추가 될 때 향후 빌드에서 이름 충돌을 방지하는 데 도움이 될 수 있습니다.
• 코딩 할 때 편집기 자동 완성 목록의 항목 수를 줄여서 입력 속도를 높일 수 있습니다 (C # 3.0에서는 표시된 확장 방법 목록을 줄일 수도 있음)

사용하지 않는 네임 스페이스 를 제거하면 다음과 같이되지 않습니다 .

• 어떤 식 으로든 컴파일러의 출력을 변경하십시오.
• 어떤 식 으로든 컴파일 된 프로그램의 실행을 변경하십시오 (더 빠른 로딩 또는 더 나은 성능).

결과 어셈블리는 사용하지 않은 사용을 제거하거나 제거하지 않고 동일합니다.

---

코드 청결 이 중요합니다.

불필요한 사용을 볼 때 코드가 유지되지 않고 브라우저 필드 경로에 있다는 느낌을 받기 시작합니다. 본질적으로, 사용되지 않는 일부 문장을 볼 때 뇌 뒤쪽에 "주의해서 진행하라"는 작은 노란색 깃발이 올라옵니다. 그리고 생산 코드를 읽는 것은 결코 그런 느낌을주지 않아야합니다.

사용을 정리하십시오. 조잡하지 마십시오. 자신감을 심어주십시오. 코드를 예쁘게 만드십시오. 따뜻한 느낌을주는 또 다른 개발자에게주세요.

---

에 해당하는 IL 구문이 없습니다 using. 따라서 using명령문은 생성 된 코드 나 데이터가 없으므로 애플리케이션 메모리를 늘리지 않습니다.

Using짧은 형식 이름을 정규화 된 형식 이름으로 확인하기 위해 컴파일 타임에만 사용됩니다. 따라서 불필요 using할 수 있는 유일한 부정적인 영향 은 컴파일 시간을 약간 느리게하고 컴파일하는 동안 조금 더 많은 메모리를 사용하는 것입니다. 나는 그것에 대해 걱정하지 않을 것입니다.

따라서 using입력하는 동안 완료 할 수있는 잠재적 인 일치 목록이 증가하므로 필요하지 않은 명령문을 갖는 유일한 실제 부정적인 영향은 인텔리전스에 있습니다.

---

네임 스페이스에서 (사용하지 않은) 클래스와 같은 클래스를 호출하면 이름이 충돌 할 수 있습니다. System.Text의 경우 "Encoder"라는 클래스를 정의하면 문제가 발생합니다.

어쨌든 이것은 일반적으로 사소한 문제이며 컴파일러에서 감지합니다.

---

응용 프로그램은 더 많은 메모리를 사용하지 않습니다. 컴파일러가 코드 파일에서 사용하는 클래스를 찾을 수 있습니다. 그것은 깨끗하지 않은 것 이상으로 아프지 않습니다.

---

주로 개인적인 취향입니다. 나는 그것들을 스스로 정리합니다 (Resharper는 불필요한 문장이있을 때 알려주는 좋은 일을합니다).

컴파일 시간을 단축시킬 수는 있지만 요즘 컴퓨터와 컴파일러 속도로 인해 눈에 띄는 영향을 미치지는 않습니다.

---

추가 using지시문을 남겨 두는 것이 좋습니다. 그것들을 제거하는 데 약간의 가치가 있지만 별로는 아닙니다. 예를 들어, IntelliSense 완성 목록이 더 짧아서 탐색하기가 더 쉽습니다.

컴파일 된 어셈블리는 외부 using지시문의 영향을받지 않습니다 .

때때로 나는 그것들을 안에 넣고 #region접힌 채로 둡니다. 파일을 좀 더 깔끔하게 볼 수 있습니다. IMO, 이것은 몇 가지 좋은 용도 중 하나입니다 #region.

---

코드를 깨끗하게 유지하려면 사용되지 않는 using명령문을 파일에서 제거해야합니다. 코드를 이해해야하는 공동 작업 팀에서 일할 때 모든 코드를 유지 관리해야한다고 생각하면 코드가 줄어든다 = 작업이 줄어든다는 이점은 장기적으로 이익이됩니다.

---

그들은 바로 가기로 사용됩니다. 예를 들어, 사용 시스템이없는 경우 System.Int32마다 다음과 같이 작성해야합니다. 위에.

사용하지 않는 것을 제거하면 코드가 더 깨끗해 보입니다.

---

using 문은 사용하는 유형을 한정하지 않습니다. 나는 개인적으로 그들을 청소하고 싶습니다. 위치 측정법이 어떻게 사용되는지에 따라 달라집니다

---

Having only the namespaces that you actually use allows you to keep your code documented.

You can easily find what parts of your code are calling one another by any search tool.

If you have unused namespaces this means nothing, when running a search.

I'm working on cleaning up namespaces now, because I'm constantly asked what parts of the application are accessing the same data one way or another.

I know which parts are accessing data each way due to the data access being separated by namespaces e.g. directly through a database and in-directly through a web service.

I can't think of a simpler way to do this all at once.

If you just want your code to be a black box (to the developers), then yes it doesn't matter. But if you need to maintain it over time it is valuable documentation like all other code.

---

The 'using' statement does not affect performance as it is merely a helper in qualifying the names of your identifiers. So instead of having to type, System.IO.Path.Combine(...), you can simply type, Path.Combine(...) if you have using System.IO.

---

Do not forget that the compiler do a lot of work to optimize everything when building your project. Using that is used in a lot of place or 1 shouldn't do a different once compiled.

참고URL : https://stackoverflow.com/questions/136278/why-should-you-remove-unnecessary-c-sharp-using-directives