For some reason I never see this done. Is there a reason why not? For instance I like _blah for private variables, and at least in Windows Forms controls are by default private member variables, but I can't remember ever seeing them named that way. In the case that I am creating/storing control objects in local variables within a member function, it is especially useful to have some visual distinction.
出于某种原因,我从未见过这样。有没有理由呢?例如,我喜欢_blah用于私有变量,并且至少在Windows窗体控件中默认是私有成员变量,但我不记得曾经看到它们以这种方式命名。在我在成员函数中的局部变量中创建/存储控制对象的情况下,具有一些视觉区别特别有用。
11 个解决方案
#1
13
This might be counter-intuitive for some, but we use the dreaded Hungarian notation for UI elements.
对于某些人来说,这可能是违反直觉的,但我们对UI元素使用可怕的匈牙利符号。
The logic is simple: for any given data object you may have two or more controls associated with it. For example, you have a control that indicates a birth date on a text box, you will have:
逻辑很简单:对于任何给定的数据对象,您可能有两个或更多与之关联的控件。例如,您有一个控件,指示文本框上的出生日期,您将具有:
- the text box
- a label indicating that the text box is for birth dates
- a calendar control that will allow you to select a date
文本框
表示文本框用于出生日期的标签
日历控件,允许您选择日期
For that, I would have lblBirthDate for the label, txtBirthDate for the text box, and calBirthDate for the calendar control.
为此,我将标签为lblBirthDate,文本框为txtBirthDate,日历控件为calBirthDate。
I am interested in hearing how others do this, however. :)
不过,我有兴趣听听别人怎么做。 :)
#2
4
Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.
匈牙利符号与否,如果人们将m_或_或其他用于标准私有成员变量的内容添加到前面,我会更好奇。
#3
1
I personally prefix private objects with _
我个人用_前缀私有对象
Form controls are always prefixed with the type, the only reason I do this is because of intellisense. With large forms it becomes easier to "get a labels value" by just typing lbl and selecting it from the list ^_^ It also follows the logic stated by Jon Limjap.
表单控件总是以类型为前缀,我这样做的唯一原因是因为intellisense。对于大型表单,通过输入lbl并从列表中选择它来“获取标签值”变得更容易^ _ ^它也遵循Jon Limjap所述的逻辑。
Although this does go again Microsofts .NET Coding Guidelines, check them out here.
虽然这确实再次出现在微软.NET编码指南中,但请在此处查看。
#4
1
For me, the big win with the naming convention of prepending an underscore to private members has to do with Intellisense. Since underscore precedes any letter in the alphabet, when I do a ctrl-space to bring up Intellisense, there are all of my _privateMembers, right at the top.
对我而言,以私人成员为前缀的命名惯例的巨大胜利与Intellisense有关。由于下划线在字母表中的任何字母之前,当我执行ctrl-space来调出Intellisense时,我的所有_privateMembers都在顶部。
Controls, though, are a different story, as far as naming goes. I think that scope is assumed, and prepending a few letters to indicate type (txtMyGroovyTextbox, for example) makes more sense for the same reason; controls are grouped in Intellisense by type.
然而,就命名而言,控制是一个不同的故事。我认为范围是假设的,并且前面几个字母表示类型(例如txtMyGroovyTextbox)因为同样的原因而更有意义;控件按类型分组在Intellisense中。
But at work, it's VB all the way, and we do mPrivateMember. I think the m might stand for module.
但是在工作中,它一直是VB,我们做mPrivateMember。我认为m可能代表模块。
#5
1
I came through VB and have held onto the control type prefix for controls. My private members use lower-camel case (firstLetterLowercase) while public members use Pascal/upper-camel case (FirstLetterUppercase).
我来自VB,并保持控件的控件类型前缀。我的私人成员使用lower-camel case(firstLetterLowercase),而公共成员使用Pascal / upper-camel case(FirstLetterUppercase)。
If there are too many identifiers/members/locals to have a 90% chance of remembering/guessing what it is called, more abstraction is probably necessary.
如果有太多的标识符/成员/本地人有90%的机会记住/猜测它的名称,那么可能需要更多的抽象。
I have never been convinced that a storage type prefix is useful and/or necessary. I do, however, make a strong habit of following the style of whatever code I am using.
我从未确信存储类型前缀是有用和/或必要的。但是,我确实养成了遵循我使用的任何代码风格的强烈习惯。
#6
0
I don't, but I appreciate your logic. I guess the reason most people don't is that underscores would look kind of ugly in the Properties window at design time. It'd also take up an extra character of horizontal space, which is at a premium in a docked window like that.
我没有,但我很欣赏你的逻辑。我猜大多数人不这样做的原因是,在设计时,下划线在“属性”窗口中看起来有些难看。它还占据了水平空间的额外特征,在这样的停靠窗口中非常珍贵。
#7
0
Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.
匈牙利符号与否,如果人们将m_或_或其他用于标准私有成员变量的内容添加到前面,我会更好奇。
Luke,
I use _ prefix for my class library objects. I use Hungarian notation exclusively for the UI, for the reason I stated.
我使用_前缀作为我的类库对象。由于我说的原因,我专门为UI使用匈牙利表示法。
#8
0
I never use underscores in my variable names. I've found that anything besides alpha (sometimes alphanumeric) characters is excessive unless demanded by the language.
我从不在变量名中使用下划线。我发现除了alpha(有时是字母数字)字符之外的任何东西都是过量的,除非语言要求。
#9
0
I'm in the Uppercase/Lowercase camp ("title" is private, "Title" is public), mixed with the "hungarian" notation for UI Components (tbTextbox, lblLabel etc.), and I am happy that we do not have Visual Case-Insensitive-Basic developers in the team :-)
我在大写/小写营地(“标题”是私人的,“标题”是公开的),与UI组件的“匈牙利”符号混合(tbTextbox,lblLabel等),我很高兴我们没有Visual Case-Insensitive-团队中的基础开发人员:-)
I don't like the underscore because it looks kinda ugly, but I have to admit it has an advantage (or a disadvantage, depending on your point): In the debugger, all the private Variables will be on top due to the _ being on top of the alphabet. But then again, I prefer my private/public pair to be together, because that allows for easier debugging of getter/setter logic as you see the private and public property next to each other,
我不喜欢下划线,因为它看起来有点难看,但我必须承认它有一个优势(或者是一个缺点,取决于你的观点):在调试器中,所有私有变量都将位于顶部,因为_是在字母表顶部。但话说回来,我更喜欢我的私有/公共对在一起,因为当你看到彼此相邻的私有和公共属性时,它允许更容易调试getter / setter逻辑,
#10
0
I write down the name of the database column they represent.
我写下它们代表的数据库列的名称。
#11
-3
I use m_ for member variables, but I'm increasingly becoming tempted to just using lowerCamelCase like I do for method parameters and local variables. Public stuff is in UpperCamelCase.
我使用m_作为成员变量,但我越来越倾向于使用lowerCamelCase,就像我对方法参数和局部变量一样。公共资料在UpperCamelCase中。
This seems to be more or less accepted convention across the .NET community.
这似乎是.NET社区中或多或少被接受的约定。
#1
13
This might be counter-intuitive for some, but we use the dreaded Hungarian notation for UI elements.
对于某些人来说,这可能是违反直觉的,但我们对UI元素使用可怕的匈牙利符号。
The logic is simple: for any given data object you may have two or more controls associated with it. For example, you have a control that indicates a birth date on a text box, you will have:
逻辑很简单:对于任何给定的数据对象,您可能有两个或更多与之关联的控件。例如,您有一个控件,指示文本框上的出生日期,您将具有:
- the text box
- a label indicating that the text box is for birth dates
- a calendar control that will allow you to select a date
文本框
表示文本框用于出生日期的标签
日历控件,允许您选择日期
For that, I would have lblBirthDate for the label, txtBirthDate for the text box, and calBirthDate for the calendar control.
为此,我将标签为lblBirthDate,文本框为txtBirthDate,日历控件为calBirthDate。
I am interested in hearing how others do this, however. :)
不过,我有兴趣听听别人怎么做。 :)
#2
4
Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.
匈牙利符号与否,如果人们将m_或_或其他用于标准私有成员变量的内容添加到前面,我会更好奇。
#3
1
I personally prefix private objects with _
我个人用_前缀私有对象
Form controls are always prefixed with the type, the only reason I do this is because of intellisense. With large forms it becomes easier to "get a labels value" by just typing lbl and selecting it from the list ^_^ It also follows the logic stated by Jon Limjap.
表单控件总是以类型为前缀,我这样做的唯一原因是因为intellisense。对于大型表单,通过输入lbl并从列表中选择它来“获取标签值”变得更容易^ _ ^它也遵循Jon Limjap所述的逻辑。
Although this does go again Microsofts .NET Coding Guidelines, check them out here.
虽然这确实再次出现在微软.NET编码指南中,但请在此处查看。
#4
1
For me, the big win with the naming convention of prepending an underscore to private members has to do with Intellisense. Since underscore precedes any letter in the alphabet, when I do a ctrl-space to bring up Intellisense, there are all of my _privateMembers, right at the top.
对我而言,以私人成员为前缀的命名惯例的巨大胜利与Intellisense有关。由于下划线在字母表中的任何字母之前,当我执行ctrl-space来调出Intellisense时,我的所有_privateMembers都在顶部。
Controls, though, are a different story, as far as naming goes. I think that scope is assumed, and prepending a few letters to indicate type (txtMyGroovyTextbox, for example) makes more sense for the same reason; controls are grouped in Intellisense by type.
然而,就命名而言,控制是一个不同的故事。我认为范围是假设的,并且前面几个字母表示类型(例如txtMyGroovyTextbox)因为同样的原因而更有意义;控件按类型分组在Intellisense中。
But at work, it's VB all the way, and we do mPrivateMember. I think the m might stand for module.
但是在工作中,它一直是VB,我们做mPrivateMember。我认为m可能代表模块。
#5
1
I came through VB and have held onto the control type prefix for controls. My private members use lower-camel case (firstLetterLowercase) while public members use Pascal/upper-camel case (FirstLetterUppercase).
我来自VB,并保持控件的控件类型前缀。我的私人成员使用lower-camel case(firstLetterLowercase),而公共成员使用Pascal / upper-camel case(FirstLetterUppercase)。
If there are too many identifiers/members/locals to have a 90% chance of remembering/guessing what it is called, more abstraction is probably necessary.
如果有太多的标识符/成员/本地人有90%的机会记住/猜测它的名称,那么可能需要更多的抽象。
I have never been convinced that a storage type prefix is useful and/or necessary. I do, however, make a strong habit of following the style of whatever code I am using.
我从未确信存储类型前缀是有用和/或必要的。但是,我确实养成了遵循我使用的任何代码风格的强烈习惯。
#6
0
I don't, but I appreciate your logic. I guess the reason most people don't is that underscores would look kind of ugly in the Properties window at design time. It'd also take up an extra character of horizontal space, which is at a premium in a docked window like that.
我没有,但我很欣赏你的逻辑。我猜大多数人不这样做的原因是,在设计时,下划线在“属性”窗口中看起来有些难看。它还占据了水平空间的额外特征,在这样的停靠窗口中非常珍贵。
#7
0
Hungarian notation or not, I'm more curious if people prepend m_ or _ or whatever they use for standard private member variables.
匈牙利符号与否,如果人们将m_或_或其他用于标准私有成员变量的内容添加到前面,我会更好奇。
Luke,
I use _ prefix for my class library objects. I use Hungarian notation exclusively for the UI, for the reason I stated.
我使用_前缀作为我的类库对象。由于我说的原因,我专门为UI使用匈牙利表示法。
#8
0
I never use underscores in my variable names. I've found that anything besides alpha (sometimes alphanumeric) characters is excessive unless demanded by the language.
我从不在变量名中使用下划线。我发现除了alpha(有时是字母数字)字符之外的任何东西都是过量的,除非语言要求。
#9
0
I'm in the Uppercase/Lowercase camp ("title" is private, "Title" is public), mixed with the "hungarian" notation for UI Components (tbTextbox, lblLabel etc.), and I am happy that we do not have Visual Case-Insensitive-Basic developers in the team :-)
我在大写/小写营地(“标题”是私人的,“标题”是公开的),与UI组件的“匈牙利”符号混合(tbTextbox,lblLabel等),我很高兴我们没有Visual Case-Insensitive-团队中的基础开发人员:-)
I don't like the underscore because it looks kinda ugly, but I have to admit it has an advantage (or a disadvantage, depending on your point): In the debugger, all the private Variables will be on top due to the _ being on top of the alphabet. But then again, I prefer my private/public pair to be together, because that allows for easier debugging of getter/setter logic as you see the private and public property next to each other,
我不喜欢下划线,因为它看起来有点难看,但我必须承认它有一个优势(或者是一个缺点,取决于你的观点):在调试器中,所有私有变量都将位于顶部,因为_是在字母表顶部。但话说回来,我更喜欢我的私有/公共对在一起,因为当你看到彼此相邻的私有和公共属性时,它允许更容易调试getter / setter逻辑,
#10
0
I write down the name of the database column they represent.
我写下它们代表的数据库列的名称。
#11
-3
I use m_ for member variables, but I'm increasingly becoming tempted to just using lowerCamelCase like I do for method parameters and local variables. Public stuff is in UpperCamelCase.
我使用m_作为成员变量,但我越来越倾向于使用lowerCamelCase,就像我对方法参数和局部变量一样。公共资料在UpperCamelCase中。
This seems to be more or less accepted convention across the .NET community.
这似乎是.NET社区中或多或少被接受的约定。