命名约定:amountPaid 与paidAmount
这里有两个示例,有两种不同的变量命名方法:
decimal amountDue = 1000; decimal amountPaid = 800;
vs.
decimal dueAmount = 1000; decimal paidAmount = 800;
您通常更喜欢哪一种?为什么?
here is two samples with two different approaches to naming variables:
decimal amountDue = 1000; decimal amountPaid = 800;
vs.
decimal dueAmount = 1000; decimal paidAmount = 800;
Which one would you usually prefer and why?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
你应该使用哪个读起来更好的英语句子。 例如应付给客户的金额是1000美元。 在我看来#1 更好。 因为如果您编写客户应付金额 1000 美元,则会破坏实际变量的措辞。
You should use which ever one reads better as an english sentence. Such as the amount due to the customer is 1000 dollars. In my opinion #1 is better. Because if you write the customer is due the amount of 1000 dollars, it breaks up the wording of the actual variable.
在给定上下文中最具可读性的内容。 我可以看到这从你的任何一个选择到简单的“已付款”和“到期”。
例如:
Whatever is most readable in the given context. I could see this ranging from either of your options to simply "paid" and "due".
For example:
第一个 (amountDue) 意味着在获得有用的智能感知之前输入七个字符。 我会选择第二名。
The first one (amountDue) means typing seven characters before getting useful intellisense. I'd opt for number two.
“Paid”有几个属性:paidAmount、paidDate、paidBy、paidTo 等。
“Amount”是数据类型(本质上是货币或 BigDecimal 或您的语言使用的任何内容),并没有多大意义。
"Paid" has several attributes: paidAmount, paidDate, paidBy, paidTo, etc.
"Amount" is the data type (essentially currency or BigDecimal or whatever your language uses) and doesn't mean much.
为了稍微搅动一下锅(如果每个人都同意,那就没有乐趣了),我会选择选项1。
To stir the pot a little (and there's no fun if everyone agrees), I would choose option 1.
正如其他人所说,选项#1 更好,因为命名遵循人们在句子中使用这些概念的方式,而不会听起来很奇怪。 但是,我认为您还应该注意您正在建模以命名变量的业务领域。 在特定业务领域中,一个概念可能会用非常独特的名称或术语来引用,但在该业务领域之外的句子中使用时听起来并不正确。 如果是这种情况,那么我会使用业务领域正在使用的术语,以便代码用业务领域术语来表达。 这有助于开发人员熟悉业务领域,也使与客户的沟通变得更容易,因为每个人都说同一种语言。
例如,在这种特殊情况下,如果我注意到业务文件和客户在提及预期付款时使用到期金额而不是到期金额,我会使用到期金额。
As others said, option #1 is better as naming follows how one would use those concepts in a sentence without sounding weird. However, I think you should also pay attention the business domain that you're modeling to name your variables. A concept may be referred to with a very unique name or terminology in a particular business domain that would not sound right when used in a sentence out of that business domain. If this is the case, then I would go with the terminology that the business domain is using so that the code is expressed in business domain terminology. This helps developers getting familiar with the business domain and also makes communications with clients easier as everyone speaks the same language.
For example, in this particular case, if I notice that the business documents and cliens are using due amount instead of amount due in referring to a payment expected, I would go with due amount.