代码风格的换行的讲究
虽然你完全可以在C# 里将所有的代码都连在一行里书写，但想必没有人愿意这么做，谁也不会自己折磨自己的眼睛，何况大多数鼠标对于上下翻页的支持都比左右翻滚好得多。我相信，这也是大多数人接受将每条语句分行书写的原因，很少有人会怀疑这一点的合理性。例如下面这行代码，虽然结构很简单，但是它实在太长了，所以被分成了两行： 由于代码过长而进行断行
bitmap = new Bitmap(size.Width, size.Height,
System.Drawing.Imaging.PixelFormat.Format32bppArgb);
这一点我相信大家都能理解并愿意遵循，然而问题的焦点并不在于要不要换行，而在于在什么位置换行。 通过断行使代码更加清晰
if (f == ImageFormat.Jpeg.Guid
||f == ImageFormat.Tiff.Guid
||f == ImageFormat.Png.Guid
||f == ImageFormat.Exif.Guid)
{
supportsPropertyItems = true;
}
else
{
supportsPropertyItems = false;
}
原本一个很长的条件表达式，通过在“||”运算符处换行，显得更加的清晰。有一点需要我们注意的是，当我们进行折行时，要将折行位置处的分隔符（如前一例中的逗号，这一例中的“||”运算符等）留在上一行的行末，给人以“此行并未结束”的直观印象。这就好像在英文书写中，如果你需要将一个单词拆开，就需要在前一行末尾加上连字符，以表示那个单词并没有结束。
可以看出，换行在防止代码超出屏幕边界的同时，还影响着代码的表达。因此如何选择合适的换行位置也是很有讲究的。有的时候，我们并不一定非要在临近右边界的时候才去换行，如果存在更为合理的分法，就应当采用，例如下面的情况：
double containerAspectRatio = (double)container.ClientWidth /
container.ClientHeight;
按理说这样的断行并没有什么问题，它在表达式的两项之间断开，并将运算符留在了上一行的行末。但是，我相信如果换一种断行方式的话，能够更加清楚地表达出原来的逻辑： 寻找最佳的断行位置
double containerAspectRatio =
(double)container.ClientWidth / container.ClientHeight;
如此一来，这个除法算术表达式就显得较为完整，相比前一种写法而言更能体现其内在的逻辑关系。通常我们会选择整个表达式中最高的关系层次进行断行，例如上述代码中的“赋值号”和“除号”都是可以考虑的断行点，但相比较而言，除号连接的这个算术表达式只是整个赋值表达式的右半部分，如果在除号处断行，那么不但整个表达式会被截断，连局部的这个除法表达式也会被截断；反之，我们选择在赋值号处换行，可以保持除法表达式的完整，最大限度地减少换行对语句整体结构的破坏。
同样的道理，为了将逻辑体现得更为清晰，我们甚至可以将函数调用中的每一个参数都分行书写，如同下面这样： 将函数调用中的每一个参数都分行书写
Rectangle imageBounds = new Rectangle(
itemBounds.X + padding,
itemBounds.Y + padding,
itemBounds.Width - padding * 2,
itemBounds.Height - padding * 2
);
当参数数量较多，参数较长或者包含表达式的时候，这种排版比起单独写成一行更为直观醒目。
对于LINQ查询表达式来说，将每个子句单独写成一行也是好的习惯。因为这同时符合了T-SQL语言的文化传统。例如： 将LINQ查询表达式中的每个子句单独写成一行
IEnumerable<int> highScoresQuery =
from score in scores
where score > 80
orderby score descending
select score; 如果说换行是为了防止屏幕左右滚动的话，那么当这个情况不存在的时候，一些人就开始打算充分利用屏幕空间了：
private static void Swap(object a, object b)
{
object temp;
temp = a; a = b; b = temp;
}
看起来好像确实没有占据多少屏幕空间，这只是把三条很短的语句凑在一行了而已——关键的理由是：它不会引起屏幕的左右滚动。但是当人们已经习惯于一行一条语句的时候，很可能就会忽视这里有三条语句这个事实（不要指望每次遇到的都像这个例子一样地简单）。更为重要的一点是，编译器总是按行来进行设计的，将多条语句写在一行会引起不必要的麻烦，例如：你将永远无法把断点设置在后面的语句上（如图1-1）：
图1-1：一行代码包含多条语句时的断点设置
有的读者会觉得，如果代码复杂，当然应该分开书写，没有必要去节省那点屏幕，但是如果像这个例子中这么简单，写在一起也不会带来什么麻烦。单纯地看来，他的话不无道理，可是，对于一个开发团队，或者将要进入开发团队的人来说，最重要的是“统一”。如果我们允许将多条语句合并到同一行代码内，那么怎样的代码才算“简单”到可以合并的程度？是宽度小于50个字符的可以合并，还是宽度小于51个字符的可以合并？当一条规定无法被准确地定义的时候，它也就无法执行，从而必将在整个开发团队中产生不一致性，最终导致更多的混乱。 我们再来看一种情况，这类代码出现的几率更为频繁，它是将相同数据类型的几个变量声明放在了同一条语句中：
int num, factor, index, length;
如果我说我反对这种写法，一定会有读者大叫起来：这明明是单独的一条语句，何况C# 允许我们在一条语句内声明多个变量，如此一来还可以少写几个“int”，为什么不行？
这种写法，显而易见会给注释带来很大的麻烦。把它们都写在一起以后，我怎么给每个变量添加注释呢？如果是分开书写的，那么我可以很容易地为每一个变量添加单独的注释，就像这样：
代码示例1-6：将每个变量分行定义将有助于单独注释
// 要计算的数值
int num;
// 表示影响因子
int factor;
// 元素所在的索引号
int index;
// 数据列表的总长
int length;
如果觉得这种写法较为繁琐，一定要节约那几个“int”，以强调它们的数据类型相同的话，也可以采取下面的写法：
代码示例1-7：变量分行定义的折衷方案
int num, // 要计算的数值
factor, // 表示影响因子
index, // 元素所在的索引号
length; // 数据列表的总长
这种方式只使用了一条声明语句，但是每个变量都书写在单独的行上，便于有针对性的注释。
