如果说硬性规定一个类的代码行数不能超过x行，你能忍受的限度会是多少行?
最近几天，我天天写了代码，无聊统计了下，发现自己的构建类的代码行最多不会超过200行。于是，想了想，要不要定条死规则——如果我的构建类的代码行超出200行，就一定要重构！

书《Clean Code》的Tenth Chapter有提到上帝之类（God Class），就说一个类所承担的职责太多了，导致是个超级类。而它的一个很直观的表现就是代码行会很多！当然书中说计量类的职责来判断是否为God Class,但作者好像没有给出职责的量化计算标准。所以就有了下面的假想：

1年前写代码，
一个类超出200行很正常，那时我从极少单元测试的！看了《JUnit in Action》后，就没有出现过此情况了！

1年前写代码，
我经常把最初定义的项目分层依赖结构打破（model/persistences/services/web），例如：web层的MemberManagerServlet竟然有如此方法定义（SetManagerAbstractFactory），这不显然打破了层间的层次依赖结构吗，WEB层就不应该有此类方法。但使用了集成Maven的IDE—M2Eclipse后，最初层间依赖的打破也成了绝不允许了。

如我了解到Maven有一个源代码质量检查工具～或者自己可以实现一个代码行检测的Maven扩展。

如果说硬性规定一个类的代码行数不能超过x行（200、300也或更多），你能忍受的限度会是多少行！

如果你的项目经理搞出一个这样的要求，你会接受的了吗？


------解决方案--------------------
额。。。只要有outline 有足够的备注 类名不要写的太抽象 自己觉得写500行内就ok
不过看过sakai 某些类动辄10000行+ 蛋疼不已。。。
------解决方案--------------------
去java类库看，有些.java文件三四兆

理论是理论，现实没有理论那么完美，有时候不得不折中
------解决方案--------------------
2000
超过了要拆分
------解决方案--------------------
光是註釋就好幾百行了

探讨

去java类库看，有些.java文件三四兆

理论是理论，现实没有理论那么完美，有时候不得不折中