Eng*_*ock 14 .net c# project code-organization
我和我们公司的teamlead\architect就此主题进行了讨论.
他认为,如果"通过逻辑连接的实体"放在一个cs文件中,那么理解大型项目会更容易.
我引用:
"逻辑和接口以及类的整个结构可以在一个地方看到,这是一个不能反驳的论据.要看到相同的东西但是有一堆文件你需要使用工具,类图,R#用于导航等."
"根据糟糕的理论,我可能会尖叫一大堆分离文件很酷,但是当谈到改变现有代码时,特别是如果你不是这个代码的作者,那么很难理解大量分散的文件.所以在论坛上,你可以写出"一个枚举文件",但实际上这种方法绝对不能用"
"......至于开发人员之间的代码库分离,现在同时编辑同一个文件不是问题.合并不是问题."
我多次听说过,我们必须为每个枚举,类等创建一个.cs文件,这是最好的做法.
但我无法说服他.他说他不相信任何知名程序员,如Jon Skeet.顺便说一句,这里是Skeet对这个主题的看法哪里是定位枚举类型的最佳位置？
你怎么看？有真正的问题吗？或者这是一个品味的问题,应该由组织的编码标准来规范？
在我看来:
较大逻辑类中需要的小枚举和类可以保留在其文件中.
但是如果在该范围之外使用较小的类和枚举,则应该单独使用它们(尽管如果它们在逻辑上链接,它们本身可能在同一个文件中).
所以我同意他的逻辑耦合.
说,我必须说还有其他选择,你可以在项目中创建逻辑文件夹来保存来自相同逻辑环境或连接的类.
今天的IDE通过Go-To功能为您提供了整个解决方案的轻松访问和移动性,因此查找代码不是问题.
将逻辑组件保持在一起(只要它们真正紧密耦合)在扩展时确实具有很大的优势.随着项目变得越来越大,它往往会变得更加混乱,而这正是他试图避免的.
顺便说一下,如果你仔细阅读Skeet的意见,你会注意到:
并假设它们将被其他类使用,将它们作为自己文件中的顶级类型.
| 归档时间： |
|
| 查看次数： |
4655 次 |
| 最近记录： |