C#项目文件是规范吗？

一个C#程序员重写了一个Delphi6程序（没有GUI，只有文件输入文件输出，大约50个过程和函数，总计不到1200行==57kb的击键），该程序作为一个.DPR文件存在

他交付了一个包含58个文件（其中52个是.CS文件）的项目，这些文件位于13个不同程度嵌套的文件夹中，总容量超过330kb

---

这是典型的C#项目吗？C#程序员通常使用什么策略来决定如何分割和组织他们的项目？

Delphi是一种很棒的语言，但它不是一种神奇的语言。所以不，你看到的不是一个典型的场景

如果不知道你的程序做了什么，就很难做出有意义的评论来解释为什么你的程序员决定a）重写它，b）为什么他这么做了

---

尽管如此，我还是要说，当开发人员不了解其他人的源代码时，尤其是当他们确实了解需求时，他们会选择重写而不是重构。这是我们在这个行业中一次又一次看到的东西。

没有看到原始代码或新代码的实际代码，我无法通过知道行数、方法数和文件大小来告诉您新组织的代码设计是否正确。在C#中，我通常：

将每个类和接口分离到自己的文件中

静态助手方法按函数分组

我通常按层将文件分成文件夹。例如GUI层、业务逻辑层等

扩展方法由它们相关的类或接口分隔，有时也由函数分隔

---

现在，新代码可以分解为更面向对象的设计，但我不能不看代码就说出来。

这更多是开发人员使用Visual Studio IDE（VS）的产物，而不是C#/.NET本身的问题。使用VS工具时，倾向于将每个类放在自己的.cs文件中，因为“解决方案资源管理器”窗口以树状结构显示文件/文件夹，允许程序员快速直观地确定其类的目标

此外，VisualStudio的“添加新项”对话框鼓励采用“每个文件一类”的方法，每次向项目中添加类时都会生成一个新文件

程序的名称空间层次结构通常使用解决方案资源管理器中的目录文件夹进行模拟（尽管不需要匹配），但这只是另一种直观的快捷方式

示例：

（来源：）

---

如果程序员在visualstudio环境之外工作，您的腹泻可能会少很多。EWW…

代码文件大小是确定项目价值的可怕指标，尤其是在业务线项目中。原因有三：

1） 小代码文件比大代码文件更容易理解，但这可能会导致某些构造的重复（使用声明、名称空间声明等），并且肯定会增加项目中的文件数量

2） 小班比大班更容易理解。这是代码新手的一大好处。如果他们能围绕任何一门课，他们就能从那里扩展他们的理解

3） 好代码比小代码大。当您添加适当的错误检查、文档和描述性方法/变量名时，您的代码更具弹性和可维护性，但也更大。那很好

---

说到这里，当然有很多情况下代码很大，仅仅是因为程序员不知道他们在做什么。你可以通过查看最大的文件来识别它；如果您看到大量重复的完全相同的代码。。。或者如果你看到大量的字符串连接。。。。或者你根本看不到任何注释（或者注释没有告诉你任何有用的东西），那么你可能手头上有一些好的老式代码膨胀。

你把一个合理的问题埋在了很多垃圾中。你把一个合理的问题埋在了很多“口头”腹泻中。作为一个涉猎过C的Delphi程序员，我发现在一个DPR文件中包含50个方法的想法和58个文件/13个文件夹都令人担忧！我怀疑JDK的解释是正确的。通常在DPR（Delphi项目文件）中只有很少的代码。您的确切问题在哪里？有些东西存储在X而不是Y很多文件中（X和Y在同一范围内）不适合作为参数。或者您的1024*1024*1024 KB磁盘驱动器上没有330 KB？Gerry：没有方法，只有过程/函数。它是一个DLL，在一个大型数据结构上进行大量普通的传递，没有将代码分解为多个文件（因此是一个DPR）的特殊优势。为什么小型代码文件更容易理解？我发现上下翻页导航代码比切换窗口容易得多。你确定吗？点击PageDn二十次（或者是十次，还是三十次？这取决于！）以获得执行特定任务的代码部分的速度不会像按Ctrl+Tab并切换到包含该代码的命名良好的文件那样快。您可以在列表中看到文件名，因此知道需要击多少次键才能访问该文件。。。。当你在一个非常大的文件中滚动时，你没有那个好处。+1写得很好，但是Ctrl+Tab是Visual Studio中我开始非常讨厌的一种行为。为什么？为什么他们决定在按住Ctrl键的同时使用MRU列表，而不是从左向右（就像我使用的所有其他软件一样，我可能会添加）。Lieven，Windows自己的alt-tab功能使用MRU排序，而不是Mozilla样式的打开排序。我同意，对于他们来说，添加在这两种方法之间切换的功能是非常理想的，但MRU订购不应该让任何人感到意外。：-）