最佳实践 - 命名约定问题 [英] Best Practices -- Naming Convention Question
问题描述
愚蠢的问题：
我一直想要用
$来创建类和属性b $ b同名并且当前受欢迎的命名约定不会自动区分它们......（两者都是Pascal Case而没有
领先或尾随限定词）。
例如......我会为某些东西建模，例如一台电脑，我会
创建一些课程：
显示器，CPU，键盘，鼠标...
然后我会定义一个电脑班......
班电脑
监听_monitor;
cpu _cpu;
键盘_键盘;
然后我设置了一些简单的访问器而且我坚持使用
倾向于这样做：
Monitor Monitor {get ... set ...}
Cpu Cpu {get ... set ...}
键盘键盘{get ... set ...}
现在这可以编译，但我认为它使代码更难以理解，
迟早我将不得不手动清除
额外资格者的歧义或处理与编写Cpu思维相关的构建错误
属性但是编译器确定的是一个类，我将面临
特别是神秘的构建错误消息。或者更糟糕的是：
如果碰巧成功建造就会出现神秘行为。
而且我真的不希望我的访问者称为TheMonitor和作为命名类CMonitor或clsMonitor的
实践等已经消失了
失宠...
那么其他人在做什么？
问候，
Dave
Hi,
Stupid question:
I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren''t
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).
For example... I''ll be modelling something, e.g. a computer, and I''ll
create some classes:
Monitor, Cpu, Keyboard, Mouse...
And then I''ll define a Computer Class...
class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;
and then I get to setting some simple accessors and I''m stuck with the
inclination to do this:
Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}
Now this does compile, but I think it makes the code more unreadable,
and sooner or later I''ll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i''ll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.
And I don''t really want my accessors called ''TheMonitor'' and as the
practice of naming the classes "CMonitor or clsMonitor" etc have gone
out of favour...
So what are others doing?
regards,
Dave
推荐答案
" 42" <无**** @ nospam.com> skrev i en meddelelse
新闻：MP ************************ @ shawnews.vf.shawca ble.net .. 。
"42" <no****@nospam.com> skrev i en meddelelse
news:MP************************@shawnews.vf.shawca ble.net...
我一直想要创建具有相同名称的类和属性，并且当前喜欢的命名约定不会自动区分它们......（两者都是是Pascal案例，没有
前导或尾随限定符。
例如......我会建模，例如一台电脑，我会创建一些课程：
监视器，Cpu，键盘，鼠标...
然后我会定义一个电脑班......
班电脑
监听_monitor;
Cpu _cpu;
键盘_键盘;
然后我就开始设置一些简单的访问器，我坚持这样做的倾向：
Monitor Monitor {get ... set ...}
Cpu Cpu {get ..设置...}
键盘键盘{get ... set ...}
现在这可以编译，但我认为它使代码更难以理解，
迟早我将不得不用额外的限定符来手动清除歧义，或处理与编写Cpu思想属性相关的构建错误，但编译器确定这是一个类，我将面临
特别是神秘的构建错误消息。或者更糟糕的是：如果碰巧成功建造，就会出现神秘的行为。
而且我并不是真的希望我的访问者被称为TheMonitor，而是作为
的实践命名类CMonitor或clsMonitor等等已经失宠了
那么其他人在做什么？
I keep bumping into the desire to create classes and properties with the
same name and the current favored naming conventions aren''t
automatically differentiating them... (both are "Pascal Case" with no
leading or trailing qualifiers).
For example... I''ll be modelling something, e.g. a computer, and I''ll
create some classes:
Monitor, Cpu, Keyboard, Mouse...
And then I''ll define a Computer Class...
class Computer
Monitor _monitor;
Cpu _cpu;
Keyboard _keyboard;
and then I get to setting some simple accessors and I''m stuck with the
inclination to do this:
Monitor Monitor {get ... set...}
Cpu Cpu {get ... set...}
Keyboard Keyboard {get ... set ...}
Now this does compile, but I think it makes the code more unreadable,
and sooner or later I''ll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i''ll be facing
especially cryptic build error messages as a result. Or perhaps worse:
cryptic behaviour if it happens to build successfully.
And I don''t really want my accessors called ''TheMonitor'' and as the
practice of naming the classes "CMonitor or clsMonitor" etc have gone
out of favour...
So what are others doing?
我去了监视器监视器 {get;组; }"办法。我和你一样认为它看起来很丑陋。我也认为实例变量的下划线看起来很难看，但是你去的地方是
。
我仍然想要恢复我在java中的方式，写了
getters和setters（以小写字母开头）：
监听getMonitor（）{
返回监视器;
}
void setMonitor（监视器监视器）{
this.monitor = monitor;
}
例如。 （我个人喜欢这个 - 我可以看到获取
和设置的方法，对我来说很明显他们做了什么。如果我只看到一个属性
名为Monitor，如果你可以获得和设置，或者只是
得到的话，目前还不清楚。
彼得
42写道：
42 wrote:
那么其他人在做什么？
我按照你描述的方式去做，只有我没有在
字段中使用下划线。
私人监视器监视器;
public Monitor Monitor {get {...}}
我理解你关于歧义的论点，但反驳的论点是
这个命名约定对某人来说很明显
读取你的代码，你的类的Monitor属性最多
可能是同名的类型。
我认为至少约会命名字段我的方式是
MS指南的一部分，虽然我忘了我曾经发现的地方。
Oliver Sturm
-
omnibus ex nihibo ducendis sufficit unum
插入空格以防止谷歌电子邮件销毁：
MSN oliver @ sturmnet.org Jabber sturm @ amessage.de
ICQ 27142619 http://www.sturmnet.org/blog
42< no **** @ nospam.com>写道：
< snip>
42 <no****@nospam.com> wrote:
<snip>
现在这可以编译，但我认为它使代码更难以理解，
迟早我将不得不用额外的限定符来手动清除歧义，或处理与编写Cpu思想属性相关的构建错误，但编译器确定这是一个类，我将面临
特别是神秘的构建错误消息。
Now this does compile, but I think it makes the code more unreadable,
and sooner or later I''ll have to manually clear up ambiguities with
extra qualifers or deal with build bugs related to writing Cpu thinking
property but which the compiler determines is a class and i''ll be facing
especially cryptic build error messages as a result.
我同意它看起来有点奇怪，但它确实有效 - 我非常
很少有歧义问题。这绝对是MS
进入各种API的方式，而且它对客户端代码来说非常易读。
-
Jon Skeet - < sk *** @ pobox.com>
http://www.pobox.com/~skeet
如果回复小组，请不要给我发邮件
I agree it looks a bit odd to start with, but it does work - I very
rarely have any problems with ambiguities. It''s definitely the way MS
go in various APIs, and it''s very readable for client code.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
这篇关于最佳实践 - 命名约定问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
