GirişIntroduction
Microsoft ® Visual Basic ® programlama dili, Microsoft .NET Framework için üst düzey bir programlama dilidir.The Microsoft® Visual Basic® programming language is a high-level programming language for the Microsoft .NET Framework. Ulaşılabilir ve öğrenilmesi kolay bir dil olmak üzere tasarlanmış olsa da, deneyimli programcıların ihtiyaçlarını karşılamak için yeterince güçlü bir işlemdir.Although it is designed to be an approachable and easy-to-learn language, it is also powerful enough to satisfy the needs of experienced programmers. Visual Basic programlama dilinin, Visual Basic kodun açıklık ve okunabilirliğini sağlayan, Ingilizce 'ye benzer bir sözdizimi vardır.The Visual Basic programming language has a syntax that is similar to English, which promotes the clarity and readability of Visual Basic code. Anlamlı sözcüklerin veya deyimlerin her yerde kısaltmalar, kısaltmalar veya özel karakterler yerine kullanılır.Wherever possible, meaningful words or phrases are used instead of abbreviations, acronyms, or special characters. Gereksiz veya gereksiz sözdizimine genellikle izin veriliyor ancak gerekli değildir.Extraneous or unneeded syntax is generally allowed but not required.
Visual Basic programlama dili kesin bir tür veya gevşek yazılmış bir dil olabilir.The Visual Basic programming language can be either a strongly typed or a loosely typed language. Gevşek yazma, bir program zaten çalışmaya ana kadar tür denetlemesi yükünü çok fazla erteler.Loose typing defers much of the burden of type checking until a program is already running. Bu, metot çağrılarının yalnızca dönüştürmelerin tür denetimini değil, bir yöntem çağrısının bağlamasının çalışma zamanına kadar ertelenebileceği anlamına gelir.This includes not only type checking of conversions but also of method calls, meaning that the binding of a method call can be deferred until run-time. Bu, geliştirme hızının yürütme hızına kıyasla daha önemli olduğu Prototiplerde veya diğer programlar oluştururken kullanışlıdır.This is useful when building prototypes or other programs in which speed of development is more important than execution speed. Visual Basic programlama dili, derleme zamanında tüm tür denetimini gerçekleştiren ve yöntem çağrılarının çalışma zamanı bağlamasına izin vermeyen kesin olarak belirlenmiş semantikler de sağlar.The Visual Basic programming language also provides strongly typed semantics that performs all type checking at compile-time and disallows run-time binding of method calls. Bu, maksimum performansı güvence altına alır ve tür dönüştürmelerin doğru olmasını sağlamaya yardımcı olur.This guarantees maximum performance and helps ensure that type conversions are correct. Bu, yürütme hızının ve yürütme hızının önemli olduğu üretim uygulamaları oluştururken kullanışlıdır.This is useful when building production applications in which speed of execution and execution correctness is important.
Bu belgede Visual Basic dili açıklanmaktadır.This document describes the Visual Basic language. Dil Öğreticisi veya kullanıcının başvuru el ile değil, bir dil açıklaması olması amaçlanmıştır.It is meant to be a complete language description rather than a language tutorial or a user's reference manual.
Dilbilgisi gösterimiGrammar Notation
Bu belirtim iki dilbilgisinde açıklanmaktadır: sözcük temelli dilbilgisi ve sözdizimsel dilbilgisi.This specification describes two grammars: a lexical grammar and a syntactic grammar. Sözlü dilbilgisi, karakterlerin belirteçlerin form ile nasıl birleştirileceğini tanımlar; sözdizimsel dilbilgisi belirteçleri, Visual Basic programları biçimlendirmek için nasıl birleştirilebilecek tanımlar.The lexical grammar defines how characters can be combined to form tokens; the syntactic grammar defines how the tokens can be combined to form Visual Basic programs. Koşullu derleme gibi ön işleme işlemleri için kullanılan birkaç ikincil dilbilgisi de vardır.There are also several secondary grammars used for preprocessing operations like conditional compilation.
Bu belirtimde bulunan dilmars, ANTLR biçiminde yazılmıştır--bkz http://www.antlr.org/ ..The grammars in this specification are written in ANTLR format -- see http://www.antlr.org/.
Büyük/küçük harf Visual Basic programlarda önemli değildir.Case is unimportant in Visual Basic programs. Kolaylık olması için tüm terminallerde standart büyük küçük harf olarak verilecek, ancak büyük küçük harflere sahip olacak.For simplicity, all terminals will be given in standard casing, but any casing will match them. ASCII karakter kümesinin yazdırılabilir öğeleri, bunlara karşılık gelen ASCII karakterleriyle temsil edilir.Terminals that are printable elements of the ASCII character set are represented by their corresponding ASCII characters. Visual Basic terminallerde aynı zamanda genişlikle, tam genişlikteki Unicode karakterlerinin yarı genişlikte Unicode eşdeğerlerine ve yalnızca tam belirteç temelinde eşleşmesini sağlar.Visual Basic is also width insensitive when matching terminals, allowing full-width Unicode characters to match their half-width Unicode equivalents, but only on a whole-token basis. Karışık yarım genişlik ve tam genişlikli karakterler içeriyorsa belirteç eşleşmeyecektir.A token will not match if it contains mixed half-width and full-width characters.
Satır sonları ve girintileme okunabilirlik için eklenebilir ve üretimin bir parçası değildir.Line breaks and indentation may be added for readability and are not part of the production.
UyumlulukCompatibility
Programlama dilinin önemli bir özelliği, dilin farklı sürümleri arasında uyumlulukta olur.An important feature of a programming language is compatibility between different versions of the language. Bir dilin daha yeni bir sürümü dilin önceki bir sürümüyle aynı kodu kabul etmezse veya önceki sürümden farklı şekilde yorumlayacağından, kodu dilin bir sürümünden başka bir sürümüne yükseltirken bir programcıya bir yük yerleştirilebilecek.If a newer version of a language does not accept the same code as a previous version of the language, or interprets it differently than the previous version, then a burden can be placed on a programmer when upgrading his code from one version of the language to another. Bu nedenle, dil tüketicilerine yönelik avantajın açık ve çok daha fazla olması dışında sürümler arasındaki uyumluluğun korunması gerekir.As such, compatibility between versions must be preserved except when the benefit to language consumers is of a clear and overwhelming nature.
Aşağıdaki ilke sürümler arasındaki Visual Basic dilde yapılan değişiklikleri yönetir.The following policy governs changes to the Visual Basic language between versions. Bu bağlamda kullanılan dil terimi, yalnızca Visual Basic dilin sözdizimi ve anlam yönlerini ifade eder ve Microsoft.VisualBasic ad alanının (ve alt ad alanları) bir parçası olarak dahil edilen .NET Framework sınıfları içermez.The term language, when used in this context, refers only to the syntactic and semantic aspects of the Visual Basic language itself and does not include any .NET Framework classes included as a part of the Microsoft.VisualBasic namespace (and sub-namespaces). .NET Framework tüm sınıflar, bu belgenin kapsamı dışında ayrı bir sürüm oluşturma ve uyumluluk ilkesiyle kapsanır.All classes in the .NET Framework are covered by a separate versioning and compatibility policy outside the scope of this document.
Uyumluluk sonlarının türleriKinds of compatibility breaks
İdeal bir dünyada uyumluluk, Visual Basic mevcut sürümü ve Visual Basic sonraki tüm sürümleri arasında %100 olur.In an ideal world, compatibility would be 100% between the existing version of Visual Basic and all future versions of Visual Basic. Ancak, bir uyumluluk kesmesi gereksinimi, programcılar üzerinde getirebileceği maliyetten daha fazla ücret verebilir.However, there may be situations where the need for a compatibility break may outweigh the cost it may impose on programmers. Bu gibi durumlar şunlardır:Such situations are:
Yeni uyarılar.New warnings. Yeni bir uyarı tanıtımı, bir uyumluluk kesmesi başına değildir.Introducing a new warning is not, per se, a compatibility break. Ancak, birçok geliştirici "uyarıları hata olarak değerlendir" özelliği açık olarak derlendikleri için, uyarılarla ilgili ek dikkatli olunmalıdır.However, because many developers compile with "treat warnings as errors" turned on, extra care must be taken when introducing warnings.
Yeni anahtar sözcükler.New keywords. Yeni dil özelliklerine giriş yaparken yeni anahtar sözcükler gerekli olabilir.Introducing new keywords may be necessary when introducing new language features. Kullanıcıların tanımlayıcılarıyla çakışma olasılığını en aza indirecek ve var olan anahtar kelimeleri kullanmanın anlamlı olduğu anahtar sözcükleri seçmek için makul çalışmalar yapılır.Reasonable efforts will be made to choose keywords that minimize the possibility of collision with users' identifiers and to use existing keywords where it makes sense. Önceki sürümlerden projeleri yükseltmek ve yeni anahtar sözcüklerden çıkmak için yardım sunulacaktır.Help will be provided to upgrade projects from previous versions and escape any new keywords.
Derleyici hataları.Compiler bugs. Derleyicinin davranışı, dil belirtiminde belgelenmiş bir davranış ile Odd 'de olduğunda, belgelenen davranışla eşleşecek şekilde derleyici davranışını düzeltmek gerekebilir.When the compiler's behavior is at odds with a documented behavior in the language specification, fixing the compiler behavior to match the documented behavior may be necessary.
Belirtim hatası.Specification bug. Derleyici dil belirtimiyle tutarlıdır ancak dil belirtimi açık bir şekilde yanlış ise, dil belirtiminin ve derleyici davranışının değiştirilmesi gerekebilir.When the compiler is consistent with the language specification but the language specification is clearly wrong, changing the language specification and the compiler behavior may be necessary. "Açıkça yanlış" ifadesi, belgelenen davranışın, kullanıcıların açık ve çok büyük bir çoğunluğunun kullanıcılar için ne kadar beklendiğini ve daha istenmeyen bir davranış ürettiğini belirten sayaç çalıştırdığı anlamına gelir.The phrase "clearly wrong" means that the documented behavior runs counter to what a clear and unambiguous majority of users would expect and produces highly undesirable behavior for users.
Belirtim belirsizlik.Specification ambiguity. Dil belirtiminin belirli bir durumda ne olduğunu, ancak bunu belirten bir şekilde açıklaması olması gerekir ve derleyici, durumu tutarsız veya açıkça yanlış bir şekilde işler (önceki noktadan aynı tanımı kullanarak), belirtimi ve derleyici davranışını düzeltmeyi açıklığa kavuşturun gerekli olabilir.When the language specification should spell out what happens in a particular situation but doesn't, and the compiler handles the situation in a way that is either inconsistent or clearly wrong (using the same definition from the previous point), clarifying the specification and correcting the compiler behavior may be necessary. Diğer bir deyişle, belirtim servis taleplerini a, b, d ve e kapsadığında, ancak c durumunda ne olduğunu ve derleyicinin durum c 'de yanlış davrandığı zaman, c durumunda ne olacağını belgelemek ve derleyicinin davranışını eşleşecek şekilde değiştirmek gerekebilir.In other words, when the specification covers cases a, b, d and e, but omits any mention of what happens in case c, and the compiler behaves incorrectly in case c, it may be necessary to document what happens in case c and change the behavior of the compiler to match. (Belirtim bir durumda olduğu gibi belirsizse ve derleyicinin açık bir şekilde yanlış olmayan bir şekilde davrandığı, derleyici davranışının de asıl belirtimine dönüşdiğine unutmayın.)(Note that if the specification was ambiguous as to what happens in a situation and the compiler behaves in a manner that is not clearly wrong, the compiler behavior becomes the de facto specification.)
Derleme zamanı hatalarıyla çalışma zamanı hataları oluşturma.Making run-time errors into compile-time errors. Kodun, çalışma zamanında başarısız olmasına neden olan %100 olması durumunda (Kullanıcı kodu bunun üzerinde belirsiz bir hata nedeniyle), durumu yakalayan bir derleme zamanı hatası eklenmesi istenebilir.In a situation where code is 100% guaranteed to fail at runtime (i.e. the user code has an unambiguous bug in it), it may be desirable to add a compile-time error that catches the situation.
Belirtim atlama.Specification omission. Dil belirtimi özellikle belirli bir duruma izin vermediğinde ya da engellemez ve derleyici bu durumu istenmeyen bir şekilde işler (derleyici davranışı açık bir şekilde yanlış ise, belirtim hatası değil bir belirtim hatası olur), belirtimi Açıklığa kavuşturmanız ve derleyici davranışını değiştirmeniz gerekebilir.When the language specification does not specifically allow or disallow a particular situation and the compiler handles the situation in a way that is undesirable (if the compiler behavior was clearly wrong, it would a specification bug, not a specification omission), it may be necessary to clarify the specification and change the compiler behavior. Normal etki analizine ek olarak, bu türdeki değişiklikler değişikliğin etkisinin son derece en düşük olduğu kabul edildiği ve geliştiricilere yönelik avantajın çok yüksek olduğu durumlarda daha da kısıtlıdır.In addition to the usual impact analysis, changes of this kind are further restricted to cases where the impact of the change is considered to be extremely minimal and the benefit to developers is very high.
Yeni özellikler.New features. Genel olarak, yeni özelliklere giriş, dil belirtiminin varolan bölümlerini veya derleyicinin var olan davranışını değiştirmemelidir.In general, introducing new features should not change existing parts of the language specification or the existing behavior of the compiler. Yeni bir özelliği tanıtma, var olan dil belirtiminin değiştirilmesini gerektiren durumlarda, bu tür bir uyumluluk kesmesi yalnızca etki son derece en düşük olabildiğinde ve özelliğin avantajı yüksek olduğunda makul olur.In the situation where introducing a new feature requires changing the existing language specification, such a compatibility break is reasonable only if the impact would be extremely minimal and the benefit of the feature is high.
Güven.Security. Olağandışı durumlarda güvenlik sorunları, doğal olarak güvenli olmayan bir özelliği kaldırma veya değiştirme, kullanıcılar için açık bir güvenlik riski oluşturan bir uyumluluk kesmesini gerektirebilir.In extraordinary situations, security concerns may necessitate a compatibility break, such as removing or modifying a feature that is inherently insecure and poses a clear security risk for users.
Aşağıdaki durumlar, uyumluluk sonlarına giriş için kabul edilebilir nedenler değildir:The following situations are not acceptable reasons for introducing compatibility breaks:
İstenmeyen veya regretable davranışı.Undesirable or regrettable behavior. Uygun olmayan ancak istenmeyen ya da regektable olarak kabul edilen dil tasarımı veya derleyici davranışı geriye dönük uyumluluğun kesilmesi için bir gerekçe değildir.Language design or compiler behavior which is reasonable but considered undesirable or regrettable in retrospect is not a justification for breaking backward compatibility. Bunun yerine, aşağıda ele alınan dil kullanımdan kaldırma işlemi kullanılmalıdır.The language deprecation process, covered below, must be used instead.
Başka birşey var mı.Anything else. Aksi takdirde, derleyici davranışı geriye doğru uyumlu kalır.Otherwise, compiler behavior remains backwards compatible.
Etki ölçütleriImpact Criteria
Bir uyumluluk kesmenin kabul edilebilir olup olmadığını düşünürken, değişikliğin etkisinin ne olabileceğini belirlemek için birkaç ölçüt kullanılır.When considering whether a compatibility break might be acceptable, several criteria are used to determine what the impact of the change might be. Etkisi arttıkça, uyumluluk sonlarını kabul etmek için çubuğun daha yüksek olması gerekir.The greater the impact, the higher the bar for accepting the compatibility breaks.
Ölçütler şunlardır:The criteria are:
Değişikliğin kapsamı nedir?What is the scope of the change? Diğer bir deyişle, kaç tane programın etkilenmesi olasıdır?In other words, how many programs are likely to be affected? Kaç kullanıcının etkilenmesi olasıdır?How many users are likely to be affected? Değişiklik, değişiklikten etkilenen kodu yazmak için ne sıklıkta olacaktır?How common will it be to write code that is affected by the change?
Değişiklik öncesinde aynı davranışı almak için herhangi bir geçici çözüm var mı?Do any workarounds exist to get the same behavior prior to the change?
Değişiklik ne kadar açıktır?How obvious is the change? Kullanıcılar bir şeyin değiştiği veya programları farklı şekilde yürütmek için kullanıcılara anında geri bildirim alacak mı?Will users get immediate feedback that something has changed, or will their programs just execute differently?
Yükseltme sırasında değişiklik makul bir şekilde çözülebilir mi?Can the change be reasonably addressed during upgrade? Değişikliğin kusursuz doğrulukla gerçekleştiği durumu bulabilen ve değişikliği aşmak için kodu değiştiren bir araç yazmak mümkün midir?Is it possible to write a tool that can find the situation in which the change occurs with perfect accuracy and change the code to work around the change?
Değişiklik hakkında topluluk geri bildirimi nedir?What is the community feedback on the change?
Dil kullanımdan kaldırıldıLanguage deprecation
Zaman içinde, dilin veya derleyicinin parçaları kullanım dışı kalabilir.Over time, parts of the language or compiler may become deprecated. Daha önce anlatıldığı gibi, kullanım dışı bırakılmış özellikleri kaldırmak için uyumluluğu kesmeniz kabul edilebilir değildir.As discussed previously, it is not acceptable to break compatibility to remove such deprecated features. Bunun yerine, aşağıdaki adımlar izlenmelidir:Instead, the following steps must be followed:
Visual Studio 'nun sürümünde bulunan bir özellik verildiğinde, geri bildirimin, özelliğin kullanımdan kalkması ve tüm son kullanım dışı bırakma kararından önce verilen tam duyuru olması durumunda Kullanıcı topluluğundan verilmesi gerekir.Given a feature that exists in version A of Visual Studio, feedback must be solicited from the user community on deprecation of the feature and full notice given before any final deprecation decision is made. Kullanımdan kaldırma işlemi, kullanıcı topluluğu geri bildirimlerine bağlı olarak herhangi bir noktada ters veya durdurulmuş olabilir.The deprecation process may be reversed or abandoned at any point based on user community feedback.
Visual Studio 'nun tam sürümü (yani bir nokta yayını değil), kullanım dışı kullanım uyarısı olan Derleyici uyarıları ile birlikte yayınlanmalıdır.full version (i.e. not a point release) B of Visual Studio must be released with compiler warnings that warn of deprecated usage. Uyarılar varsayılan olarak açık olmalıdır ve kapatılabilir.The warnings must be on by default and can be turned off. Kullanımdan kalklıklar, ürün belgelerinde ve Web 'de açıkça açıklanmalıdır.The deprecations must be clearly documented in the product documentation and on the web.
Visual Studio 'nun tam sürümü, devre dışı bırakılandan sonra derleyici uyarıları ile birlikte yayınlanmalıdır.A full version C of Visual Studio must be released with compiler warnings that cannot be turned off.
Daha sonra, Visual Studio 'nun tam sürümü daha sonra derleyici hatalarına dönüştürülen kullanım dışı Derleyici uyarıları ile birlikte yayınlanmalıdır.A full version D of Visual Studio must subsequently be released with the deprecated compiler warnings converted into compiler errors. D sürümü, a yayınının (Bu yazarken 5 yıl) temel destek aşamasının sonundan sonra gerçekleşmelidir.The release of D must occur after the end of the Mainstream Support Phase (5 years as of this writing) of release A.
Son olarak, derleyici hatalarını kaldıran Visual Studio 'nun bir sürümü serbest bırakılamayabilir.Finally, a version E of Visual Studio may be released that removes the compiler errors.
Bu kullanımdan kaldırma çerçevesi içinde işlenebilecek değişikliklere izin verilmez.Changes that cannot be handled within this deprecation framework will not be allowed.