C#如果是坏习惯，还有别的办法逃脱吗？

我的意思是，如果我希望if语句有一个else语句，但是有一个嵌套的if语句“在我的方式中”，所以我使用一个空白的else语句，比如“else；”或“else{}”来转义它，这会是一种不好的做法吗

例：

vs:

甚至：

if (lsvAddons.SelectedItems.Count > 0)
{
    foreach (ListViewItem A in lsvAddons.SelectedItems)
    {
        if (Addons[A.Index] != null) 
        { 
            Addons[A.Index].DoHelp();
        }
    }
}
else
{
    Console.WriteLine(_GenericHelpString)
}

---

使用第三种格式

if (lsvAddons.SelectedItems.Count > 0)
{
    foreach (ListViewItem A in lsvAddons.SelectedItems)
    {
        if (Addons[A.Index] != null) 
        { 
            Addons[A.Index].DoHelp();
        }
    }
}
else
{
    Console.WriteLine(_GenericHelpString)
}

---

如果你问哪一个代码更好，更干净，那么最后一个

---

我不知道为什么开发人员如此努力地将他们的代码压缩成越来越令人困惑的形式。额外的括号可能不会告诉编译器任何不同之处，但这只是好的编码之战的一半。让它清晰易读，您的同事和软件用户将感谢您减少了错误

空代码块是不好的做法

else { }

使用大括号（

{

和

}

）指定您的

else

所属的

。默认情况下，它属于同一范围内最接近它的
（花括号）。使用括号还可以提高您将来和其他可能阅读它的开发人员的可读性

所以，使用第二种格式来解决您的问题

if (lsvAddons.SelectedItems.Count > 0)
{
    foreach (ListViewItem A in lsvAddons.SelectedItems)
        if (Addons[A.Index] != null) Addons[A.Index].DoHelp();
}
else Console.WriteLine(_GenericHelpString);

不过，为了便于阅读，我更喜欢您给出的第三个示例。
大括号是您的朋友。

如果你克制住省略大括号的冲动，你就会走在前面。第三种形式是完全明确的，更容易阅读，并将帮助您避免意外错误。我不知道你的情况，但我能马上理解第三种形式的行为。。前两种形式需要更多的思考和心理分析才能正确

许多开发人员试图去掉大括号，使用
if
语句的隐式形式。不幸的是，当您遇到以下情况时，您会怎么做：

if( someCondition... )
    DoSomething();
    DoAnotherThing();

开发人员只是缩进不正确吗？或者两种方法都属于同一种情况？事后很难说。。。并且是缺陷的主要来源。下面是一个更糟糕的例子：

if( someCondition );
    DoSomething();
    DoAnotherThing();

你注意到这里的细微错误了吗

从长远来看，如果你能使你的代码明确无误，减少这些问题的发生，你会过得更好

开发人员经常争论省略大括号，以便他们的代码更短、更容易理解。现在，避免使用长方法肯定有好处（有些人甚至认为方法应该始终为单屏幕长）。。。但我认为这种简洁所带来的风险通常不值得回报。请记住，有一些方法可以重新构造方法以避免过度嵌套，而且它们通常比省略大括号更能提高可读性

我个人的口头禅是：

让它正确
说清楚
要简洁
快点。。。按这个顺序
你的第二个版本是“最佳实践”。ReSharper会抱怨空代码块，通常使用更少的关键字比使用更多的关键字更好。是的，版本2占用了更多的空白，但这不一定是坏事，而且它的非空白字符更少。
空的else是否会使代码更可读？不，但是大括号是这样的。
我花了一段时间才理解第一个例子中的所有东西都属于什么，所以我认为这是一种不好的做法

else { }

我个人

永远不要嵌套无支架控制结构，因为它可能很难读取
在
if
和
else
上使用大括号，或者两者都不使用
因此，我将其格式化如下：

if (lsvAddons.SelectedItems.Count > 0)
{
    foreach (ListViewItem A in lsvAddons.SelectedItems)
    {
        if (Addons[A.Index] != null) 
            Addons[A.Index].DoHelp();
    }
}
else
{
    Console.WriteLine(_GenericHelpString)
}

过多的大括号是不必要的，也是令人讨厌的。

我不介意大括号，我认为如果你有几个嵌套级别，你应该使用它们，即使只有一个语句。但你不应该一直虔诚地使用它们

对于一些非常简单的事情，比如

if (some_condition)
    Console.WriteLine("some info");

使用大括号将完全是多余的，并且会使您更难看到周围代码的整体情况（因为您可以在屏幕上显示较少的内容）。
我的问题在标题中，解释在文章中。但我只是为那些容易忘记的人清理了一下；）如果您不需要编写else语句，只需将其忽略即可。。。如果我在查看其他人的代码时看到一个空的else语句，我首先想到的是这个人可能遗漏了他的一段代码。这个问题是主观的和有争议的。请投票结束。我只能附和那些说第三个是我喜欢的格式的家伙。虽然第二个不是太坏。在我看来，除了第一个，任何东西都可以。第三个看起来像是由用线付费的人发明的。我更喜欢第二个，我想他知道这一点，这就是为什么在第一个例子中，他在else上加了一个空格，以表明他们是否属于谁to@Fiona我开始回答时，他还没有解释这个问题。我现在已经更新了答案。您以前使用过Visual Studio吗？它自动且正确地缩进代码，因此它总是显示
if
一个
else
属于哪个
。我只是忍不住想，我的类文件中的代码块越大，阅读它的人一开始会觉得越难理解，即使它是隔开的。也要想知道你的想法在同一行，又名：
else控制台。WriteLine（\u GenericHelpString）@Blam:这是一样的。不要忽略大括号。我见过许多缺陷，这些缺陷是由于开发人员误解了语句的预期范围或内聚性造成的。相信我。。。从长远来看，这两个额外的角色可以帮你省去麻烦。嗯，你用过Visual Studio吗？事实上，在这种情况下，很难将缩进弄错——你必须故意这样做@伊布什金：是的，他们是。使用错误的工具是一个坏习惯。使用好工具是一个好习惯。此外，在我使用VisualStudio的5年时间里，我从未见过自动格式化功能在语句之后错误缩进语句
if (some_condition)
    Console.WriteLine("some info");