C #에서 사용하지 않는 using 지시문을 제거하는 이유는 무엇입니까?

개발자 Usings가 Visual Studio 2008에서 " 사용하지 않는 항목 제거 "기능을 사용하는 이유 (소스 코드 정리를 제외하고)가 있는지 궁금합니다 .

그들을 꺼내고 싶은 몇 가지 이유가 있습니다.

• 무의미합니다. 그들은 가치를 추가하지 않습니다.
• 혼란 스럽습니다. 해당 네임 스페이스에서 무엇을 사용하고 있습니까?
• 그렇지 않으면 using시간이 지남에 따라 코드가 변경됨에 따라 점차적으로 무의미한 진술이 축적 됩니다.
• 정적 분석이 더 느립니다.
• 코드 컴파일이 느립니다.

다른 한편으로, 그것들을 남겨 둘 이유는 많지 않습니다. 나는 당신이 그들을 삭제해야하는 노력을 절약했다고 ​​생각합니다. 그러나 당신이 그렇게 게으르다면 더 큰 문제가 있습니다!

나는 그 반대라고 말하고 싶습니다. 불필요하고 불필요한 using 문을 제거하는 것은 매우 도움이됩니다.

3, 6, 9 개월 내에 코드로 돌아 가야하거나 다른 사람이 코드를 인계 받아 유지해야한다고 상상해보십시오.

정말로 필요하지 않은 using 문에 대한 방대한 양의 세탁 목록이 있다면 코드를 보는 것이 매우 혼란 스러울 수 있습니다. 그 네임 스페이스에서 아무것도 사용되지 않는다면 왜 거기에서 사용하고 있습니까 ??

전문적인 환경에서 장기적인 유지 관리 측면에서 코드를 가능한 한 깨끗하게 유지하는 것이 좋습니다. 여기에는 불필요한 내용을 버리는 것도 포함됩니다. 덜 혼란 스러울수록 혼란이 적어 유지 보수 가능성이 높아집니다.

마크

이것은 응답하는 사람들에 의해 상당히 경솔한 방식으로 취급되고있는 매우 합리적인 질문 인 것 같습니다.

소스 코드에 대한 모든 변경은 정당화되어야한다고 말하고 싶습니다. 이러한 변경에는 숨겨진 비용이있을 수 있으며 질문을 제기 한 사람은이를 알고 싶어했습니다. 그들은 한 사람이 움직이는 것처럼 "게으른"이라고 부르지 않았습니다.

방금 Resharper를 사용하기 시작했으며 내가 담당하는 프로젝트에 대한 경고와 스타일 힌트를주기 시작했습니다. 그중에는 중복 using 지시문을 제거하고 중복 한정자, 대문자 사용 등을 제거하는 것입니다. 내 직감은 코드를 정리하고 모든 힌트를 해결하는 것이지만, 비즈니스 책임자는 부당한 변경에 대해 경고합니다.

우리는 자동화 된 빌드 프로세스를 사용하므로 SVN 리포지토리를 변경하면 프로젝트 / 버그 / 이슈에 연결할 수없는 변경 사항이 생성되고 이전 버전에 기능적 변경 사항이없는 자동화 된 빌드 및 릴리스가 트리거됩니다.

중복 한정자의 제거를 살펴보면 도메인 및 데이터 계층 클래스가 한정자에 의해서만 구분되므로 개발자에게 혼란을 줄 수 있습니다.

애칭 (예 : ABCD-> Abcd)의 적절한 대소 문자 사용을 살펴보면 Resharper가 해당 참조 클래스 이름을 사용하는 Xml 파일을 리팩터링하지 않는다는 점을 고려해야합니다.

따라서 이러한 힌트를 따르는 것은 보이는 것처럼 간단하지 않으며 존경심을 가지고 대해야합니다.

이미 주어진 이유 외에도 불필요한 이름 충돌을 방지합니다. 다음 파일을 고려하십시오.

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

네임 스페이스 System.IO 및 System.Windows.Shapes에는 각각 Path라는 클래스가 포함되어 있으므로이 코드는 컴파일되지 않습니다. 전체 클래스 경로를 사용하여 수정할 수 있습니다.

        private static string temporaryPath = System.IO.Path.GetTempFileName();

또는 단순히 줄을 제거 할 수 있습니다 using System.Windows.Shapes;.

Intellisense 팝업의 옵션이 적습니다 (특히 네임 스페이스에 확장 메서드가 많이 포함 된 경우).

이론적으로 Intellisense도 더 빨라야합니다.

그들을 제거하십시오. 보고 궁금해 할 코드가 적 으면 시간과 혼란이 절약됩니다. 더 많은 사람들이 모든 것을 단순하고 깔끔하고 깔끔하게 유지하기를 바랍니다. 방에 더러운 셔츠와 바지가있는 것과 같습니다. 추악하고 왜 거기에 있는지 궁금해해야합니다.

또한 사용하지 않는 사용을 제거한 후 프로젝트에서 일부 dll / 프로젝트 참조를 제거 할 수 있다고 가정하면 잘못된 순환 종속성을 방지하는 데 도움이됩니다.

코드가 더 빨리 컴파일됩니다.

최근에 사용하지 않는 수입품을 삭제하는 것이 매우 유용하고 중요한 또 다른 이유를 얻었습니다.

하나가 다른 하나를 참조하는 두 개의 어셈블리가 있다고 가정합니다 (지금은 첫 번째 어셈블리를 A 하고 참조 B)를. 이제 A에 B에 의존하는 코드가 있으면 모든 것이 정상입니다. 그러나 개발 프로세스의 어느 단계에서 실제로 해당 코드가 더 이상 필요하지 않다는 것을 알게되었지만 using 문은 그대로 둡니다. 이제뿐만 아니라는 의미가 using-directive뿐만 아니라, 어셈블리 참조 에 B임의의 장소에서 사용하지 않는하지만 사용되지 않는 지시어에 있습니다. 이것은 먼저 컴파일에 필요한 시간을 늘립니다 A.B 또한로드 할 수 있습니다.

따라서 이것은 더 깔끔하고 읽기 쉬운 코드에 대한 문제 일뿐만 아니라 참조 된 어셈블리가 모두 존재 하지 않는 프로덕션 코드에서 어셈블리 참조를 유지하는 문제이기도 합니다 .

마지막으로 예제에서 B와 A를 함께 배송해야했지만 B는 A의 어느 곳에서도 사용되지 않고-섹션에서 사용되었습니다 using. 이 다량으로 영향을 미칠 것이다 런타임 의 - 성능A 어셈블리를 로드 .

적어도 이론적으로는 C # .cs 파일 (또는 단일 프로그램 소스 코드 파일)이 제공된 경우 코드를보고 필요한 모든 것을 시뮬레이션하는 환경을 만들 수 있어야합니다. 일부 컴파일 / 파싱 기술을 사용하면 자동으로 수행하는 도구를 만들 수도 있습니다. 이 작업을 최소한 염두에두고 수행하면 코드 파일이 말하는 모든 내용을 이해할 수 있습니다.

이제 1000이 포함 된 .cs 파일을받은 경우 using 실제로 10 개만 지시문이 . 외부 세계를 참조하는 코드에 새로 도입 된 기호를 볼 때마다 1000 줄을 거쳐야합니다. 이것은 분명히 위의 절차를 느리게합니다. 따라서 10 개로 줄일 수 있다면 도움이 될 것입니다!

제 생각에는 C # using지시문은 매우 약합니다. 일반성을 잃지 않고는 단일 제네릭 기호를 지정할 수없고 using별칭 지시문을 사용하여 확장 메서드를 사용할 수 없기 때문 입니다. Java, Python 및 Haskell과 같은 다른 언어에서는 그렇지 않습니다. 이러한 언어에서는 외부 세계에서 원하는 것을 (거의) 정확하게 지정할 수 있습니다. 그러나 이벤트는 using가능할 때마다 별칭 을 사용하는 것이 좋습니다 .