我尽可能准确地命名一个类(也是成员,属性等)。但有时我不确定如果类名变大(50个字符以上),这是否如此聪明。处理是令人不舒服的,代码变得难以阅读。
这个问题很少发生,因此我没有太多使用这么长的名字的经验,但不时(现在)它发生了。其他人如何处理这个?你有一个近似的上限,然后做缩写或是否值得痛苦处理这么长的名字?
更新
这里要求提供这样一个长类名称的例子。
ProjectContractChargingPeriodProjectAccountReferenceVM
第一个 Project 代表域,它可能会被省略,因为命名空间意味着它已经处理了项目。问题是,如果我用这个类名做这个,那么我必须用这个命名空间的所有类来做,而且我肯定不喜欢因为这个命名空间的许多(短)类名将丢失它们表现力。
[Project] ContractChargingPeriod 描述对象,此类用于和 ProjectAccountReference 表示该类是对ProjectAccount
的引用。使用 ProjectAccount 与 ProjectContract 的问题相同。仅使用帐户没有意义,因为在应用程序中还存在其他帐户类。 Reference 有点弱,因为实际上它只是一个参考,但这是一般目的。 VM 是我一直使用的缩写,它代表 ViewModel 。我认为这是合法的,因为每个使用WPF的人都知道 VM 意味着什么。
我不得不说,该类用于将一个类包装在ORM之外,该ORM是使用我很久以前创建的老式工具构建的。那里的类代表准1:1的ERM,我知道这不是最优的,但改变它将是一项重大努力。
答案 0 :(得分:13)
(我使用Java / C ++,并且使用过其他OO语言,但不使用C#,我在这里说的几乎适用于我使用的所有语言)
我使用描述性的类名。我不认为我已经达到了50个字符:-) 通常长类名称不公开,通常隐藏在接口和工厂后面。该接口的名称比类短得多。
您可能会做的一件事是,假设您有许多密切相关的长命名类,请将它们放入包中。发现这种情况的一种方法是,所有类都具有相同的前缀字。如果有许多类都以相同的名称开头,那么也许名称应该是一个包。
答案 1 :(得分:9)
你有一个近似的上限 然后做缩写或是它 值得痛苦的处理这么久 名字?
都不是。没有缩写,除了URL或HTTP之类的非常好的知识。也许对于范围非常小的局部变量。否则,要更加思考如何获取既具有描述性又不长的名称(我会说任何超过30个字符的内容都太长了。)
通常,长名称包含可以省略的冗余或不相关的信息。例如,不要在那里放置已经从上下文提供的信息(即成员名称中已经存在于类名中的信息)。并避免使用“数据”,“信息”,“处理程序”,“管理器”,“帮助程序”,“计算”,“处理器”等非特定填充词 - 它们几乎描述了所有代码,因此不包含任何实际信息(以及它们反映了程序性概念,几乎就是代码的味道。
答案 2 :(得分:5)
其他人如何处理这个问题?你有一个近似的上限,然后做缩写或是否值得痛苦处理这么长的名字?
一个类应该代表一种东西:它是一个名词(不是一个动词,当然不是一个完整的句子)。
我喜欢用一两个词来形容我的东西,也许是三个:只有一个名词,或一个复合名词(如德语),或者可能是形容词和名词。
例如,这是一个项目中我的一些类的列表:
Ancestors.cs
Block.cs
BlockCollection.cs
BlockDocument.cs
BlockInline.cs
BlockInlineText.cs
BlockListBullet.cs
BlockListItem.cs
BlockP.cs
BlockSequence.cs
BlockTable.cs
BlockText.cs
BlockTextParent.cs
Border.cs
BorderEdges.cs
Box.cs
Canvass.cs
CaretLocation.cs
CaretLocationAndNode.cs
CaretLocationAndPoint.cs
CaretLocationData
CaretLocationPair.cs
CaretLocationPairAndPoint.cs
CaretsInBlock.cs
DebugDumpDom.cs
DebugOutput.cs
Display.cs
Displayed.cs
DocumentHandle.cs
DomDocument.cs
DomDocumentFragment.cs
DomElementBody
DomElementHandle.cs
DomElementTag.cs
DomEvent.cs
DomList.cs
DomNode.cs
DomNodeChild.cs
DomRange.cs
DomRangeBase.cs
DomTextBody.cs
DomTextHandle.cs
Edge.cs
Editing.cs
EditingState.cs
Editor.cs
EditorAction
EditorActions
EditorMutations.cs
EditorTransaction
EventListeners.cs
ExtractedRangeInDomDocument.cs
ExtraDebugInformation.cs
FormControl.cs
... etc ...
如您所见,大多数类名只是两个单词(复合名词)。
我还使用命名空间将类分成不同的类别和不同的项目(这有助于保持类的名称更短:因为一些或大多数分层信息在命名空间名称中,而不是类名)。
如果我很幸运,那么在前几个字母之后,类名是唯一的或几乎唯一的:所以如果我输入前几个字母,我可以使用Intellisense选择特定的类。因此,我不需要使用缩写。
答案 3 :(得分:3)
关于ProjectContractChargingPeriodProjectAccountReferenceVM
的示例,您可以将其重构为以下内容:
namespace Project
{
public class ContractChargingPeriod implements IAccountReference
{
...
}
public interface IAccountReference
{
...
}
}
ContractChargingPeriod
正在处理与合同收费期相关的所有业务逻辑。它实现IAccountReference
的事实也告诉对象引用一个帐户,但没有在类名中指定它。
您可以创建反映这些类型内容的简单视图模型,但视图模型本身不应包含任何业务逻辑。视图模型可以使用与上面示例相同的结构,但应该在单独的命名空间中定义。
答案 4 :(得分:3)
每当你对自己的长名称感到不满时,请尝试查看此课程超过5秒钟。我告诉你:
它的大姐姐:
不要为此感到难过,名字应该是自我解释的,所以只要你的班级名称比它所包含的代码短,我认为我们都很好。
答案 5 :(得分:2)
长班名可能暗示你的班级有很多责任(注意我说'可能')。
有关详细信息,请参阅SRP(对不起,我匆忙^^)。
答案 6 :(得分:1)
50个字符正在推动类名的大端,但这并不是不可思议的。就Java而言,完全限定类名(包括包)的最大限制为2 bytes。
在野外,Spring库因长类名而臭名昭着。例如,类AbstractTransactionalDataSourceSpringContextTests有49个字符。这提供了注入spring bean的单元测试(SpringContextTests
);数据源注入(DataSource
);测试具有事务意识(Transactional
);有问题的类是抽象的(Abstract
)。
试图将其压缩到少于49个字符将是一个挑战。此信息可以在文档中提供,但对于使用/扩展此类的类,这些类不会立即显而易见。这可能会降低对开发人员阅读单元测试的理解,所以这里肯定会有一个权衡,你必须要考虑。