C#、Visual Basic 和 C++ .NET 行数统计工具

• 下载源代码 - 38.9 KB
• 下载可执行文件 - 20.39 KB

引言

附件的程序是一个用 C# 编写的行数统计工具。这个

• 工具可以统计 .NET 解决方案、项目或单个代码文件的行数。
• 支持 C#、Visual Basic 和 C++（仅限 .NET 解决方案和项目）。
• 支持 Visual Studio 2003/.NET 1.1 和 Visual Studio 2005/.NET 2.0（但需要 .NET 2.0 才能运行）。
• 提供可排序的结果网格，方便您轻松查找最大的项目或最大的代码文件。
• 在所有级别缓存结果并提供视图。对于解决方案，您可以查看所有项目及其大小、所有代码文件及其大小，或者一个结合了项目和代码文件的视图。
• 显示每个级别的空行数。
• 显示每个级别由代码生成器自动生成的代码行数（例如，窗体上的布局代码，或类型化数据集代码）。
• 显示每个级别的注释行数。
• 统计解决方案或项目中的文件总数。
• 允许将网格复制到剪贴板，并能直接粘贴到 Excel 中。
• 采用迷人的绿色和白色配色方案。

背景

我最近被问到我们当前的 C# 项目有多少行代码，以及与另一个类似项目相比如何。‘另一个’项目在资源方面（开发人员数量）要大得多，尽管它的运行时间比我们的项目略短。我们的项目大约有一年时间，有两到三名开发人员在工作。

我搜索了互联网上的一些行数统计工具，但找不到我喜欢的。于是我升级了我几年前写的一个旧 VB6 行数统计工具。我最初使用了 VB6 到 VB.NET 升级向导。我仍然很惊讶升级向导竟然能工作，但在这种情况下，我得到了一个 VB.NET 项目（带有 VB6 风格的代码），并且可以立即编译。稍作修改后，我让它统计了单个 C# 项目中的代码。

这个程序告诉我，我们的整个 C# 解决方案大约有 180,000 行代码。如果进行计算，相当于每位开发人员每周约 1500 行代码，或每天超过 300 行。

每位开发人员每天 300 行生产代码似乎非常高，所以我决定需要一个能够更详细地分析数据的工具。这个程序就是为此而生的。下面我将讨论为什么我们的开发人员（包括我自己）的效率远远没有初步分析表明的那么高，以及原因。

Using the Code

启动时，应用程序会打开一个对话框，允许用户选择程序最初将要运行的解决方案、项目或代码文件（*.vb、*.cs）。一旦选择了文件，应用程序将计算该项的行数，并显示如下结果。这里选择了一个解决方案文件，并在生成的网格中显示了项目文件和单个代码文件。

网格可以像往常一样通过单击列标题进行排序。这里按单个代码文件中的行数进行了排序。

传统的菜单和上下文菜单都提供了附加功能。这些功能可以用于隐藏代码文件，只显示项目文件，网格中每行代表一个项目文件（通过清除“显示代码文件”旁边的复选标记）。

为了在代码文件级别获得更简单的视图，应用程序还可以只显示代码文件（通过选中“显示代码文件”并清除“显示项目文件”）。细分列（空行数、代码设计器行数和注释数）也可以通过“显示细分”菜单选项隐藏。

菜单上的其他功能都非常直观。

如果您想将网格复制到 Excel，只需选中整个网格（Ctrl+A），复制到剪贴板（Ctrl+C），然后启动 Excel 并粘贴（Ctrl+V）。在应用程序的后续版本中，我将添加一个菜单选项来完成所有这些操作。

关注点

设计

这个应用程序的设计相对简单。但是我在这篇文章的扩展版本中放入了一些关于设计的更多细节，该版本可以在我的博客上找到。

问题

关于自动生成代码的统计，这个应用程序存在一些问题，尤其是对于 Visual Studio 2003 项目。在 Visual Studio 2005 中，自动生成的代码被整齐地分成部分“设计器”文件，这使得识别和统计更加容易。对于 Visual Studio 2003，我曾试图识别自动生成的代码区域，但不得不通过查找这些区域前面的 #Region 或 #region string 来实现。这可能不是识别这些代码的最准确方法。

分析

行数统计程序显示，虽然我们的项目确实有 180,000 行代码，但其中 100,000 行是由 Microsoft 的代码生成器自动生成的。

在 100,000 行自动生成代码中，有 73,000 行在我们数据访问组件中。我们的应用程序是一款低销量但相当复杂的产品，为了方便开发，我们广泛使用了类型化数据集来从数据库中获取数据。这 73,000 行代码主要存在于这些类型化数据集中。此外，还有 22,000 行自动生成代码（在 100,000 行中）存在于我们的表示层。正如您所料，这些主要是我们窗体和用户控件的自动生成布局代码。

因此，我们还剩下 80,000 行由开发人员编写的代码。其中，另外 10,000 行是空行，另外 10,000 行是注释。即使这样也夸大了实际应用程序代码的大小，因为我们可以看到我们的单元测试项目有 16,000 行代码。

我预计这些数字对于企业级 .NET 应用程序来说并不罕见。我对其他项目的统计数据很感兴趣。

至于我上面提到的“另一个”项目，它有 50,000 行代码，10,000 行自动生成，5,000 行空行，6,000 行注释（没有单元测试）。

结论

最终，这一切都支持了所有开发人员凭直觉知道的事情：使用代码行数作为应用程序“大小”的指标真的没有多大意义。也许这就是为什么我一开始找不到一个像样的行数统计程序的原因。

但是，统计行数可以提供一些有趣的分析。我们可以一目了然地看到我们最大的类是什么，这些类显然是重构的目标。此外，如果您仔细查看屏幕截图，您会发现我们的表示层中可能比模型层（中间层业务层）有太多的逻辑。我们早就知道了，但行数统计数据将其放大了。

如上所述，这篇文章的扩展版本可以在我的博客这里找到。