我尝试尽可能准确地命名一个类(也是成员,属性等).但有时我不确定如果类名变大(50个字符以上),这是否如此聪明.处理是令人不舒服的,代码变得难以阅读.
这个问题很少发生在我身上,因此我没有太多使用这么长的名字的经验,但不时(现在)它会发生.其他人如何处理这个？你有一个近似的上限,然后做缩写或是否值得痛苦处理这么长的名字？
更新
这里要求这样一个长类名称的例子.
ProjectContractChargingPeriodProjectAccountReferenceVM
第一个Project表示域,可以省略它,因为命名空间意味着它已经处理了项目.问题是,如果我用这个类名做这个,那么我必须用这个命名空间的所有类来完成它,并且我明确地不喜欢,因为这个命名空间的许多(短)类名将丢失它们表现力.
[Project] ContractChargingPeriod描述了对象,这个类用于和ProjectAccountReference意味着该类是对a的引用ProjectAccount.使用ProjectAccount与ProjectContract的问题相同.仅使用帐户没有意义,因为在应用程序中还存在其他帐户类.该参考有点弱,因为实际上它只是一个参考,但这是一般目的.该虚拟机是一个缩写,我一直用它代表视图模型.我认为这是合法的,因为与WPF合作的每个人都知道VM意味着什么.
我不得不说,这个类用于从ORM中包装一个类,这个ORM是用很久以前创建的老式工具构建的.那里的类代表准1:1的ERM,我知道这不是最优的,但改变它将是一项重大努力.
我有一个类的名称可能不必要地繁琐，其中包含许多我在其他地方使用的静态方法。
而不是用很多填充我的代码
VeryUnnecessarilyLongCumbersomeName.doThingFoo();
VeryUnnecessarilyLongCumbersomeName.doThingBar();
VeryUnnecessarilyLongCumbersomeName.doThingEgg();
VeryUnnecessarilyLongCumbersomeName.doThingSpam();
我宁愿有
VeryUnnecessarilyLongCumbersomeName thing = new VeryUnnecessarilyLongCumbersomeName();
thing.doThingFoo();
thing.doThingBar();
thing.doThingEgg();
thing.doThingSpam();
但是，这得到了警告
"the static method doThingFoo() should be accessed in a static way."
我知道这里有多种解决方案。使用更好的类名。让它不是静态的。忽略它，因为它只是一个警告。
但我实际上并不认为这应该是一个警告。这样做有什么危害？是否有一种更优雅/正确的方法可以使我的代码不那么笨拙，这不是上述解决方案之一？
注意：我怀疑这可能需要coding-style标记，因此被认为是题外话并被拒绝。然而，我认为这里有这样一个问题的空间，所以我把它留给你们。