临时命名公约 [英] Naming Convention for Temporaries

查看:74
本文介绍了临时命名公约的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

您好:


您是否想要一份客户ID列表,但必须先获得一份

客户列表?


我非常认真对待风格和好的变量名称,所以我很想b / b
想知道其他人在某些临时或

中等的情况下做了什么步骤是必要的。


IEnumerable< Customercustomers = getCustomers();

List< CustomerlistOfCustomers = new List< Customer>(customers);

List< intcustomerIds = listOfCustomers.ConvertAll< int>(委托

(客户当前)

{

return current.ID; < br $>
});


listOfCustomers对我来说似乎很脏。我的意思是,我可以制作一行

代码,但随后可读性受到影响。


只是好奇其他人是否有更好的命名约定。 />

谢谢,

Travis

Hello:

Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?

I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.

IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
List<intcustomerIds = listOfCustomers.ConvertAll<int>(delegate
(Customer current)
{
return current.ID;
});

listOfCustomers seems dirty to me. I mean, I could make that one line
of code, but then readibility suffers.

Just curious if other people have a better naming convention.

Thanks,
Travis

推荐答案

je ********** @ gmail.com 写道:

您是否想要一份客户ID列表,但必须首先获得一份

客户列表?
Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?



可以''说我有。 :-)

Can''t say that I have. :-)


我非常认真对待风格和好的变量名称,所以我很想知道其他人在某些情况下做了什么临时或

中间步骤是必要的。


IEnumerable< Customercustomers = getCustomers();

List< CustomerlistOfCustomers = new List< ;客户>(客户);

列表< intcustomerIds = listOfCustomers.ConvertAll< int>(代表

(客户当前)

{

返回current.ID;

});
I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.

IEnumerable<Customercustomers = getCustomers();
List<CustomerlistOfCustomers = new List<Customer>(customers);
List<intcustomerIds = listOfCustomers.ConvertAll<int>(delegate
(Customer current)
{
return current.ID;
});



让我们看看。没有C#3.0,我接受了吗?否则就不需要笨拙的

委托语法。或者是临时名单。


我不会为客户申报临时名单。将

作为中间结果是没有意义的,因为您可以使用它进行枚举

(通常一次)。所以我只做一点重命名:


List< Customercustomers = new List< Customer>(getCustomers());

Let''s see. No C# 3.0, I take it? Otherwise there''d be no need for the clumsy
delegate syntax. Or a temporary list.

I would not declare a temporary for "customers". There''s no point to having
this as an intermediary result, since all you can do with it is enumerate it
(once, usually). So I''d just do a little renaming:

List<Customercustomers = new List<Customer>(getCustomers());


listOfCustomers对我来说似乎很脏。我的意思是,我可以制作一行

的代码,但随后可读性受到影响。
listOfCustomers seems dirty to me. I mean, I could make that one line
of code, but then readibility suffers.



旁观者的眼睛等我会的如果你没有首先没有

的临时变量,那么你应该给你的临时变量提供名称,这是毫无疑问的。而且我不会考虑在我的代码中使用

显式IEnumerable<以使其更具可读性。

有多个表达不同的变量"视图"相同的数据

通常会非常麻烦(例如,对于原始值和解析的值,请考虑使用customerIdString和

customerId - 您可以

想到更好的名字,但它并没有改变你有两个

变量引用相同数据的事实。 br />

至于不太可读,与填充*一切*相比没什么*

一行:


List< intcustomerIds = new

List< Customer>(getCustomers())。ConvertAll< int>(del egate(Customer current){

return current.ID; });


现在这就是我称之为不太可读的东西。值得庆幸的是,我们现在为LINQ提供这些单行的

...


-

J.

Eye of the beholder, etc. I will say that there''s no point worrying about
the names you should give to your temporary variables if you don''t have the
temporary variables in the first place. And I wouldn''t consider having an
explicit IEnumerable<in my code to make it more readable, on the contrary.
Having multiple variables that express a different "view" of the same data
usually gets quite bothersome (think having "customerIdString" and
"customerId" for the raw value and the parsed value, for example -- you can
think of better names, but it doesn''t change the fact that you''ve got two
variables referring to the "same" data).

And as for less readable, it''s nothing compared to stuffing *everything* in
one line:

List<intcustomerIds = new
List<Customer>(getCustomers()).ConvertAll<int>(del egate (Customer current) {
return current.ID; })));

Now that''s what I''d call less readable. Thankfully we have LINQ now for
these one-liners...

--
J.


2008年7月11日星期五07:36:35 -0700, je * *********@gmail.com

< je ********** @ gmail.comwrote:
On Fri, 11 Jul 2008 07:36:35 -0700, je**********@gmail.com
<je**********@gmail.comwrote:

您是否想要一份客户ID列表,但必须首先获得一份

客户列表?


我我非常认真对待风格和好的变量名称,所以我想知道其他人在某些情况下做什么时候需要一个临时的或者是
中间步骤。
Have you ever wanted a list of customer IDs, but had to get a list of
Customers first?

I am pretty conscientious about style and good variable names, so I am
wonder what other people do in certain situations when a temporary or
middle step is necessary.



好​​吧,既然你问过...... :)


我喜欢匈牙利命名约定的一个方面是它b / b
删除了这些如何命名这个变量?的问题。如果你需要一个变量,它只是一个临时持有者的东西,你只需要使用T和b。后缀。例如,如果正常的匈牙利标签将是b&b客户,那么变量

的临时持有者的变量将是customerT。


在这种情况下你真的不需要一个临时变量。

正如Jeroen建议的那样,代码可以合并以避免这种需要。

即使你确实使用中间的
变量找到了更易读的代码(这样做是一个很好的理由),你可能找不到

特殊情况足以开始学习匈牙利语。


但为了以防万一,请查看:
http://www.byteshift.de/msg/hungaria...n-doug-klunder


当然,请记住,这篇文章是几十年前编写的,并且

还有空间扩展其中描述的概念

帐户更长的类型和变量名称以及新的基本类型

存在于Java和C#等语言中。这是一个起点,而不是最后一个

字。


甚至维基百科关于这个话题的文章:
http://en.wikipedia.org/wiki/Hungarian_notation

(特别注意系统和

应用程序之间的区别匈牙利......尽可能远离系统

方言,因为它特别没有意义和尴尬。


Pete

Well, since you asked... :)

One of the things I like about the Hungarian naming convention is that it
removes these sorts of "how do I name this variable?" questions. If you
need a variable that''s simply a temporary holder for something, you simply
use the "T" suffix. For example, if the normal Hungarian tag would be
"customer", then a variable that''s a temporary holder for the variable
would be "customerT".

It''s not clear that you actually need a temporary variable in this case.
As Jeroen suggests, the code could be consolidated to avoid that need.
And even if you do find the code more readable using an intermediate
variable (which is a fine justification for doing so), you may not find
that particular situation compelling enough to start learning Hungarian.

But just in case, check out:
http://www.byteshift.de/msg/hungaria...n-doug-klunder

Keeping in mind, of course, that the article was written decades ago and
there''s room for extending the concepts described there to take into
account longer type and variable names and new fundamental types that
exist in languages like Java and C#. It''s a starting point, not the last
word.

And maybe even the Wikipedia article on the topic:
http://en.wikipedia.org/wiki/Hungarian_notation
(paying particular note to the distinction made between "systems" and
"apps" Hungarian...stay away, as far as possible, from the "systems"
dialect, as it''s particularly pointless and awkward).

Pete


7月11日,10日: 58 * am,Jeroen Mostert< jmost ... @ xs4all.nlwrote:
On Jul 11, 10:58*am, Jeroen Mostert <jmost...@xs4all.nlwrote:

我不会为客户声明临时性。将

作为中间结果是没有意义的,因为所有你能用它做的是enumerateit
I would not declare a temporary for "customers". There''s no point to having
this as an intermediary result, since all you can do with it is enumerateit



除非有显着的性能问题(即用户可能会注意到的那些问题)然后我选择尽可能多的中间

变量用于调试目的。没有什么能比我更好地惹恼我了b $ b比调试代码更像:


返回SomeMethod(AnotherMethod(SomeObject.Property));


我希望看到一些中间变量。有了足够的b / b
复杂的代码库和各种虚拟方法调用,这种风格可以让你快速丢失,让你忘记你实际上是什么

调试。

Unless there are significant performance issues (i.e. ones that a user
could possibly notice) then I opt to make as many intermediate
variables as possible just for debugging purposes. Nothing annoys me
more than debugging code like:

return SomeMethod( AnotherMethod( SomeObject.Property) );

And I want to see some intermediate variables. With a sufficiently
complex code base and various virtual method calls this style can get
you lost real quick and make you forgot what you were actually
debugging.


这篇关于临时命名公约的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆