在VB.NET开发中使用Option Compare Text与Option Compare Binary进行标准化的利弊是什么？
---编辑---
只是一些背景知识，因为这似乎会有所帮助——我的开发团队发现，由于Option Strict On、Option Infer On和Option Explicit与其他产品相比具有明显的优势，因此在它们上进行标准化要容易得多。我们还没有发现像Option Compare Text/Binary那样容易标准化，因为这两者似乎都有优点和缺点，不同的开发人员也有不同的意见。双方的一些论点如下：
选项比较文本的一些优点/论据：
- 它消除了对
StringComparer、.ToLower()调用和StringComparison.OrdinalIgnoreCase的所有需求，从而减少了代码中的冗长性 - 数据需求很少与外壳有关，大多数数据库对大小写不敏感就是明证。在进行数据比较时，您很少真正想区分
THIS、This和this - 当您不必担心套管时，某些特定的用例会更简单。例如，处理ASP.NET控制事件（其中命令作为字符串发送到代码绑定）和大小写问题很难追踪，因为编译器无法帮助您。以
<asp:repeater>事件的Select Case语句为例 - 对文本比较提出的许多担忧都与国际化有关，而国际化往往与许多应用程序无关
- VB作为一种语言是不区分大小写的，尽管Visual Studio至少通过在大小写中增强一致性来帮助您。SQL也不区分大小写。字符串是你唯一需要记住担心的地方，这突出了尴尬，如果你到处担心它，你通常不会注意到它
Option Compare Binary:的一些优点/参数
- 像大多数其他语言一样，C#也是这样工作的。有交替的行为有些出乎意料，而且这种出乎意料的行为在编程中并不好
- 编译时生成的IL证明了Option Compare Text会对性能造成轻微影响。Option Compare Binary没有这个惩罚
- 选项"比较文本"仅使字符串处理的某些部分不区分大小写。但是，它并不能使字典索引之类的东西在默认情况下不区分大小写。所以，这并不是说Option Compare Text真的做到了，这样你就不必担心大小写了。如果它只起到一半的作用，为什么要麻烦呢
- 编程很难。最好不要试图掩盖那个事实。担心钻柱套管是交易的一部分。人类对
THIS的识别不同于This和tHiS。当然，您的代码也应该如此——毕竟，它们并不是完全相同的字符串
所以我真的只是想知道是否还有其他考虑因素。
--编辑2-
如果我定义一下我认为答案是什么，也许会有所帮助。如果你能指出任何权威的外部资源，更彻底地讨论这些问题，或者指出一个标准和最佳实践的讨论或书籍，为这个主题提供指导，那当然很重要。
使用Option Compare Text，在比较字符串时无需担心大小写问题。这可能是一个很大的好处，可以避免将所有内容都转换为小写（或大写），以实现字符串相等。
这起作用的另一个地方是字符串排序。Option Compare Text的排序与Windows中的文件列表类似，但Option Compare Binary的排序与Unix文件列表类似（所有大写文件名都出现在小写文件名之前）。
更新
在阅读了评论和其他答案，并思考了更多之后，我认为Option Compare Binary是与.Net框架的其他部分保持一致的方法。如果字典键等是区分大小写的，而不管Option Compare设置如何，那么在整个代码中默认使用二进制比较就是一致的。然后你需要担心的是，对于一个特定的比较，你是否需要它不区分大小写，并为此编写代码。
如果你使用Option Compare Text，那么你不仅需要担心你是否需要一个特定的比较来区分大小写，你还需要意识到当前环境中的默认行为。
然后，它就变成了一个论点，不是与其他语言一致，而是与您正在开发的框架一致。
使用二进制，因为这是大多数其他语言的默认值，而则是.NET类的默认值。
把一个字弄混不应该破坏你的整个档案。
如果确实需要文本（这并不常见），那么只需使用String.Compare或String.Equals。
如果您需要执行大量不区分大小写的比较，请编写一个带有一些简洁命名的辅助方法的模块，并将其包含在您的项目中。虽然CaseInsenstiveEquals(S1, S2)或（使用扩展方法）S1.CaseInsensitiveEquals(S2)比S1 = S2更详细，但许多应用程序需要区分大小写和不区分大小写的混合比较。使用equals运算符作为包含不同字符序列的相等字符串进行报告会增加区分大小写比较的冗长程度。此外，还有许多方法可以执行不区分大小写的比较。如果使用一个helper方法，该方法的代码将准确地显示它使用的方法。相比之下，如果使用Option Compare Text，那么将更难知道如何处理所有不同的角落案例。
SQL不区分大小写，但LINQ中的查询是区分大小写的。它是一些内部虫子的来源。
解决方案是不使用文本作为键。必要时，确保数据库中的案例一致。最后，当这不可能时，只需根据需要使用tolower。除非需要，否则我不会建议使用tolower，因为这确实会让代码变得丑陋。