지시문을 사용하여 불필요한 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 문은 사용하는 유형을 한정하지 않습니다. 나는 개인적으로 그들을 청소하고 싶습니다. 위치 측정법이 어떻게 사용되는지에 따라 달라집니다

실제로 사용하는 네임 스페이스 만 있으면 코드를 문서화 할 수 있습니다.

검색 도구를 사용하여 코드의 어떤 부분이 서로를 호출하는지 쉽게 찾을 수 있습니다.

사용하지 않는 네임 스페이스가있는 경우 검색을 실행할 때 아무 의미가 없습니다.

응용 프로그램의 어떤 부분이 동일한 데이터에 어떤 방식으로 액세스하고 있는지 지속적으로 묻기 때문에 네임 스페이스 정리 작업을하고 있습니다.

데이터 액세스가 네임 스페이스 (예 : 데이터베이스를 통해 직접 또는 웹 서비스를 통해 직접)로 구분되어 어느 부분에서 데이터에 액세스하고 있는지 알고 있습니다.

한 번 에이 작업을 수행하는 간단한 방법을 생각할 수 없습니다.

코드가 개발자에게 블랙 박스가되기를 원한다면 중요하지 않습니다. 그러나 시간이 지남에 따라 유지 관리 해야하는 경우 다른 모든 코드와 마찬가지로 유용한 문서입니다.

'using'문은 식별자 이름을 규정하는 데 도움을주기 때문에 성능에 영향을 미치지 않습니다. 따라서 System.IO.Path.Combine (...) 을 입력하는 대신 Path.Combine (...)을 입력하면 됩니다. 당신이 경우 System.IO를 사용하여 .

컴파일러는 프로젝트를 빌드 할 때 모든 것을 최적화하기 위해 많은 작업을 수행한다는 것을 잊지 마십시오. 그것을 사용하는 것은 많은 장소에서 사용되거나 1은 한 번 컴파일 된 다른 것을해서는 안됩니다.