问题标签 [code-readability]

当我开始在我的代码中添加更多跟踪时，我意识到它增加了很多混乱。我知道 Visual Studio 允许您隐藏和显示代码，但是，我希望能够将代码分组为“跟踪”代码，然后在阅读代码时随意隐藏和显示。我想它可以为每个文件或每个类或每个函数执行此操作。

有没有办法做到这一点？你们是做什么的？

添加一些说明

隐藏当前功能允许您执行此操作，但当代码被隐藏时，您无法判断它是否跟踪。您也不能说“隐藏所有跟踪代码”和“显示所有跟踪代码”，这在读取函数时很有用，具体取决于您要执行的操作。

在您忽略/投票关闭这个问题之前，我认为这是一个有效的问题，因为代码清晰度是一个重要的讨论主题，它对于编写可维护的代码至关重要，我非常感谢那些以前遇到过这个问题的人的回答.

我最近遇到了这个问题，由于大量的嵌套，LINQ 查询很快就会变得非常讨厌。

以下是我提出的格式差异的一些示例（对于相同的相对不复杂的查询）

无格式

提升格式

块格式

列表格式

我想提出一个 linq 格式的标准，以便它最大限度地提高可读性和理解性，并且看起来干净和专业。到目前为止，我无法决定，所以我将问题转向这里的专业人士。

我今天遇到了 ReSharper 提供的 C# 语言功能，?? 操作员。这有助于使代码比我最初的尝试更加简洁。请参阅下面的迭代以改进代码的行/长度/可读性。

第一次尝试可能是这样的..

重构为..

最初我认为上述将是最有效/简洁的版本，但还有第三步......

我想知道您是否有任何类似的示例，其中 C# 语言功能有助于减少代码行并提高可读性？

我怎样才能修改下面的代码，以便更好地提高代码的可读性：

a）将“workThreadMethod（）”移动到它自己的类中

b）此工作线程类中没有任何代码引用主“程序”类中的静态变量

c）以上是主要的两个要求，但是我希望作为副作用，这将确保工作线程类方法的可测试性更容易测试，并且理想情况下适合通过 IOC 进行测试（例如 Ninject）概念[如果这没有意义，那么出于问题的目的忽略这一点]

我不确定要解决的主要挑战是如何处理原始线程和新线程之间的两个不同的共享变量（其中一个是新线程添加到的 ConcurrentQueue，另一个是原始线程添加的布尔变量线程用于向新线程指示何时停止）

我们大多数人使用等宽字体编写代码，而“m”字符通常（取决于字符组合）在等宽字体中看起来很糟糕。它在太小的空间内使用了太多的像素。

我很好奇是否有人同意我的观点。

这纯粹是一个代码可读性相关的问题，类的性能不是问题。

这是我构建这个 XMLHandler 的方式：

对于与应用程序相关的每个元素，我在“ElementName”中有一个布尔值，我在解析过程中根据我的位置将其设置为 true 或 false：问题，我现在在课堂开始时有 10+ 个布尔声明，它越来越大。

在我的 startElement 和 endElement 方法中，我有数百行

其中包含不同的解析规则（如果我在 xml 文件中处于此位置，请执行此操作，否则，请执行此操作等...）

编写新的解析规则和调试变得越来越痛苦。

编写 sax 解析器的最佳实践是什么，我可以做些什么来使我的代码更具可读性？

在 .NET 中调用立即返回的方法的开销是多少（因为不满足内部第一个代码的条件）？

我认为无论您的应用程序多么实时，开销都可以忽略不计，并且无论如何分析应该显示事实，可读性更重要，但是一些同事不同意我的观点并说您应该总是避免那些电话......

还有什么意见吗？

我确实开始.h以最好的意图组织我的文件，但不知何故，它们变得令人作呕的混乱。

下面是一个例子（这不是那么糟糕，但我见过更糟糕的！）。我尝试过将部分分组，#pragma mark但看起来更混乱。

所有的 UILabel 和 UIButton 都是必需的（如上所述），因为它们显示来自 Web 服务请求的数据，所以如果我们使用 Interface Builder 来设计我们的 GUI，它们都是必需的。例如，标签可能是产品的“重量”或“高度”特征。

有没有人对如何以最可维护/可读的方式组织这些有什么好的建议？

干杯

在《单元测试的艺术》一书中，它谈到了想要创建可维护和可读的单元测试。在第 204 页左右，它提到应该尽量避免在一个测试中使用多个断言，并且可能将对象与覆盖的 Equals 方法进行比较。当我们只有一个对象来比较预期结果和实际结果时，这很有效。但是，如果我们有一个所述对象的列表（或集合）怎么办。

考虑下面的测试。我有不止一个断言。事实上，有两个单独的循环调用断言。在这种情况下，我将得到 5 个断言。2 检查一个列表的内容是否存在于另一个列表中，2 反之亦然。第 5 个比较列表中的元素数量。

如果有人有改进此测试的建议，我会全力以赴。我目前正在使用 MSTest，尽管我将 MSTest 的 Assert 替换为 NUnits 以获得流畅的 API (Assert.That)。

当前重构代码：

原始多断言单元测试：

我刚开始使用 Resharper。它的特点之一是它建议基于良好的编码实践对代码进行更改。

它建议的更改之一是在分配期间将变量类型更改为 var。我一直在改变，现在代码到处都有 var 。不知何故，我觉得“var”关键字使代码有点难以理解。

尽可能使用“var”是一种好的编码习惯，还是坚持使用实际类型更好。（除了需要使用“var”的匿名类型）

谢谢。