Visual Basic 소개

Microsoft® Visual Basic® 프로그래밍 언어는 Microsoft .NET Framework의 고급 프로그래밍 언어입니다. 친근하고 배우기 쉬운 언어로 설계되었지만 숙련된 프로그래머의 요구를 충족할 수 있을 만큼 강력합니다. Visual Basic 프로그래밍 언어는 영어와 유사한 구문을 사용하여 Visual Basic 코드의 명확성과 가독성을 높입니다. 가능한 경우 약어, 약어 또는 특수 문자 대신 의미 있는 단어 또는 구가 사용됩니다. 불필요한 구문이나 불필요한 구문은 일반적으로 허용되지만 필수는 아닙니다.

Visual Basic 프로그래밍 언어는 강력한 형식의 언어이거나 느슨하게 입력된 언어일 수 있습니다. 느슨한 입력은 프로그램이 이미 실행될 때까지 형식 검사의 많은 부담을 지연합니다. 여기에는 변환의 형식 검사뿐만 아니라 메서드 호출도 포함됩니다. 즉, 메서드 호출의 바인딩은 런타임까지 지연될 수 있습니다. 이는 실행 속도보다 개발 속도가 더 중요한 프로토타입 또는 기타 프로그램을 빌드할 때 유용합니다. 또한 Visual Basic 프로그래밍 언어는 컴파일 타임에 모든 형식 검사를 수행하고 메서드 호출의 런타임 바인딩을 허용하지 않는 강력한 형식의 의미 체계를 제공합니다. 이렇게 하면 최대 성능이 보장되고 형식 변환이 올바른지 확인할 수 있습니다. 이는 실행 속도 및 실행 정확성이 중요한 프로덕션 애플리케이션을 빌드할 때 유용합니다.

이 문서에서는 Visual Basic 언어에 대해 설명합니다. 이는 언어 자습서나 사용자의 참조 설명서가 아닌 완전한 언어 설명입니다.

문법 표기법

이 사양에서는 어휘 문법과 구문 문법이라는 두 가지 문법을 설명합니다. 어휘 문법은 문자를 조합하여 토큰을 형성하는 방법을 정의합니다. 구문 문법은 토큰을 결합하여 Visual Basic 프로그램을 구성하는 방법을 정의합니다. 조건부 컴파일과 같은 전처리 작업에 사용되는 몇 가지 보조 문법도 있습니다.

이 사양의 문법은 ANTLR 형식으로 작성됩니다. 참조하세요 http://www.antlr.org/.

Visual Basic 프로그램에서는 대/소문자가 중요하지 않습니다. 간단히 하기 위해 모든 터미널은 표준 대/소문자로 제공되지만 대/소문자는 모두 일치합니다. ASCII 문자 집합의 인쇄 가능한 요소인 터미널은 해당 ASCII 문자로 표시됩니다. 또한 Visual Basic은 터미널을 일치시킬 때 너비를 구분하지 않습니다. 따라서 전체 너비 유니코드 문자는 반자 유니코드 문자와 일치하지만 전체 토큰 기준으로만 일치할 수 있습니다. 토큰이 반자 및 전체 너비 문자가 혼합된 경우 일치하지 않습니다.

줄 바꿈 및 들여쓰기는 가독성을 위해 추가할 수 있으며 프로덕션의 일부가 아닙니다.

호환성

프로그래밍 언어의 중요한 기능은 다른 버전의 언어 간의 호환성입니다. 최신 버전의 언어가 이전 버전의 언어와 동일한 코드를 허용하지 않거나 이전 버전과 다르게 해석하는 경우 코드를 한 언어 버전에서 다른 버전으로 업그레이드할 때 프로그래머에게 부담을 줄 수 있습니다. 따라서 언어 소비자에 대한 혜택이 명확하고 압도적인 특성을 갖는 경우를 제외하고 버전 간의 호환성을 유지해야 합니다.

다음 정책은 버전 간 Visual Basic 언어의 변경 내용을 제어합니다. 이 컨텍스트에서 사용되는 용어 언어는 Visual Basic 언어 자체의 구문 및 의미 체계 측면만 참조하며 네임스페이스(및 하위 네임스페이스)의 Microsoft.VisualBasic 일부로 포함된 .NET Framework 클래스는 포함하지 않습니다. .NET Framework의 모든 클래스는 이 문서의 범위를 벗어나는 별도의 버전 관리 및 호환성 정책에서 다룹니다.

호환성 중단의 종류

이상적인 환경에서 호환성은 기존 버전의 Visual Basic과 모든 이후 버전의 Visual Basic 간에 100% 됩니다. 그러나 호환성 중단의 필요성이 프로그래머에게 부과할 수 있는 비용보다 클 수 있는 상황이 있을 수 있습니다. 이러한 상황은 다음과 같습니다.

• 새 경고입니다. 새 경고를 도입하는 것은 호환성 중단이 아닙니다. 그러나 많은 개발자가 "경고를 오류로 처리"를 설정하여 컴파일하므로 경고를 도입할 때 각별한 주의를 기울여야 합니다.

• 새 키워드입니다. 새 언어 기능을 도입할 때 새 키워드를 도입해야 할 수 있습니다. 사용자 식별자와 충돌할 가능성을 최소화하는 키워드를 선택하고 적절한 경우 기존 키워드를 사용하기 위해 합리적인 노력을 기울일 것입니다. 이전 버전에서 프로젝트를 업그레이드하고 새 키워드를 이스케이프하는 데 도움이 제공됩니다.

• 컴파일러 버그. 컴파일러의 동작이 언어 사양에서 문서화된 동작과 상충되는 경우 문서화된 동작과 일치하도록 컴파일러 동작을 수정해야 할 수 있습니다.

• 사양 버그입니다. 컴파일러가 언어 사양과 일치하지만 언어 사양이 명백히 잘못된 경우 언어 사양 및 컴파일러 동작을 변경해야 할 수 있습니다. "명확하게 틀렸습니다"라는 문구는 문서화된 동작이 대다수의 사용자가 기대하는 것과 반대로 실행되고 사용자에게 매우 바람직하지 않은 동작을 생성한다는 것을 의미합니다.

• 사양 모호성. 언어 사양에서 특정 상황에서 발생하는 동작을 철자해야 하지만 그렇지 않은 경우 컴파일러가 일관성이 없거나 명확하게 잘못된 방식으로 상황을 처리하는 경우(이전 지점과 동일한 정의를 사용하여) 사양을 명확히 하고 컴파일러 동작을 수정해야 할 수 있습니다. 즉, 사양에서 a, b, d 및 e의 경우를 다루지만 c의 경우 발생에 대한 언급을 생략하고 컴파일러가 c인 경우 잘못 동작하는 경우 c의 경우를 문서화하고 컴파일러의 동작을 일치하도록 변경해야 할 수 있습니다. (상황에서 발생하는 상황에 대한 사양이 모호하고 컴파일러가 명확하게 잘못되지 않은 방식으로 동작하는 경우 컴파일러 동작은 사실상 사양이 됩니다.)

• 런타임 오류를 컴파일 시간 오류로 만듭니다. 코드가 100% 런타임에 실패하도록 보장되는 경우(즉, 사용자 코드에 명확한 버그가 있음) 상황을 파악하는 컴파일 시간 오류를 추가하는 것이 좋습니다.

• 사양 누락. 언어 사양이 특정 상황을 구체적으로 허용하거나 허용하지 않고 컴파일러가 바람직하지 않은 방식으로 상황을 처리하는 경우(컴파일러 동작이 명확하게 잘못된 경우 사양 누락이 아닌 사양 버그일 경우) 사양을 명확히 하고 컴파일러 동작을 변경해야 할 수 있습니다. 일반적인 영향 분석 외에도 이러한 종류의 변경은 변경의 영향이 매우 최소화된 것으로 간주되고 개발자의 이점이 매우 높은 경우로 제한됩니다.

• 새로운 기능. 일반적으로 새 기능을 도입해도 언어 사양의 기존 부분이나 컴파일러의 기존 동작이 변경되지 않아야 합니다. 새 기능을 도입하려면 기존 언어 사양을 변경해야 하는 상황에서는 영향이 매우 최소화되고 기능의 이점이 높은 경우에만 호환성 중단이 합리적입니다.

• 보안. 특별한 상황에서 보안 문제로 인해 본질적으로 안전하지 않고 사용자에게 명확한 보안 위험을 초래하는 기능을 제거하거나 수정하는 것과 같은 호환성 중단이 필요할 수 있습니다.

다음 상황은 호환성 중단을 도입하는 데 허용되지 않는 이유입니다.

• 바람직하지 않거나 유감스러운 동작입니다. 언어 디자인 또는 컴파일러 동작은 합리적이지만 회고에서 바람직하지 않거나 유감스러운 것으로 간주되는 것은 이전 버전과의 호환성을 손상시키는 근거는 아닙니다. 아래에서 설명하는 언어 사용 중단 프로세스를 대신 사용해야 합니다.

• 다른 것. 그렇지 않으면 컴파일러 동작은 이전 버전과 호환됩니다.

영향 조건

호환성 중단이 허용되는지 여부를 고려할 때 변경의 영향을 결정하는 데 몇 가지 조건이 사용됩니다. 영향이 클수록 호환성 중단을 수락하기 위한 막대가 높아집니다.

조건은 다음과 같습니다.

• 변경 범위는 무엇인가요? 즉, 영향을 받을 가능성이 있는 프로그램은 몇 개인가요? 영향을 받을 가능성이 있는 사용자 수 변경의 영향을 받는 코드를 작성하는 것은 얼마나 일반적인가요?

• 변경 전에 동일한 동작을 가져오기 위한 해결 방법이 있나요?

• 변경 내용은 얼마나 분명합니까? 사용자가 변경된 내용에 대한 즉각적인 피드백을 받거나 프로그램이 다르게 실행될까요?

• 업그레이드 중에 변경 사항을 합리적으로 해결할 수 있나요? 완벽한 정확도로 변경이 발생하는 상황을 찾아서 변경 작업을 위해 코드를 변경할 수 있는 도구를 작성할 수 있나요?

• 변경 내용에 대한 커뮤니티 피드백은 무엇인가요?

언어 사용 중단

시간이 지남에 따라 언어 또는 컴파일러의 일부가 더 이상 사용되지 않을 수 있습니다. 앞에서 설명한 것처럼 더 이상 사용되지 않는 기능을 제거하는 호환성을 중단하는 것은 허용되지 않습니다. 대신 다음 단계를 수행해야 합니다.

1. Visual Studio 버전 A 에 있는 기능이 있는 경우 최종 사용 중단 결정이 내려지기 전에 사용자 커뮤니티에서 기능 사용 중단 및 전체 알림에 대한 피드백을 요청해야 합니다. 사용 중단 프로세스는 사용자 커뮤니티 피드백에 따라 언제든지 취소되거나 중단될 수 있습니다.

2. Visual Studio의 전체 버전(즉, 포인트 릴리스 아님)은 사용되지 않는 사용을 경고하는 컴파일러 경고와 함께 릴리스되어야 합니다. 경고는 기본적으로 켜져 있어야 하며 해제할 수 있습니다. 사용 중단은 제품 설명서 및 웹에 명확하게 문서화되어야 합니다.

3. 해제할 수 없는 컴파일러 경고와 함께 Visual Studio의 전체 버전 C 를 해제해야 합니다.

4. 이후에는 더 이상 사용되지 않는 컴파일러 경고가 컴파일러 오류로 변환된 상태에서 Visual Studio의 전체 버전 D 를 릴리스해야 합니다. D 릴리스는 릴리스 A의 일반 지원 단계(이 작성 기준 5년)가 끝난 후에 발생해야 합니다.

5. 마지막으로 컴파일러 오류를 제거하는 Visual Studio 버전 E 가 릴리스될 수 있습니다.

이 사용 중단 프레임워크 내에서 처리할 수 없는 변경은 허용되지 않습니다.