放开匈牙利表示法 [英] Letting go of Hungarian Notation

问题描述

只是寻求一些建议（或安慰）...

我是唯一一个无法释放符号的人吗？我在C ++工作多年前有过丰富的经验（在我大学期间进入VB3之前以及在我的VB职业生涯中多次进入
），我欢迎丰富的类型 ; .NET

框架。但是，在给它机会差不多*两年之后，我仍然坚持使用常用符号表示
（主要是值类型）类型

（字符串，整数，布尔值等）非常有用。我可以立即看到我在我的程序中处理一个声明的变量，而不是一个

属性或一些框架对象。即使使用o也是如此。表示其他

实例化（引用）对象是有益的，因为我可以立即看到

我正在处理一个实际的实例化对象而不是一些

共享 Class。


以下是我在.NET工作近两年后获得的一些标准。

）使用所有旧的VB标准用于内在类型（s，i，b，dt等等 - 是的，我用

在几年前删除了简单类型的3字母符号）和一些新的

常用Framework对象的补充（对于StringBuilder为sb，对于

实例）。

2）" o"对于所有其他较少使用的框架类型和实例化对象。

3）所有旧的VB符号用于最常见的控件（lbl，btn，txt，pic，

等。 ）。衍生控件和花哨的自定义控件根据其目的或根源（即花式按钮仍然得到btn符号）得到注释。

4）" ; M_"或更多c＃-like_表示模块级变量。

5）g_对于全局变量。

6）全局常量的全部上限。

7）我甚至试图将符号从我的程序参数中删除......但是

决定我也喜欢那些（虽然我同意他们看到

通过intellisense时很难看。）


等等等等。我还应该注意到，我不是一个电阻器....我试着很难保持开放的态度。我已经热情地接受了很多

..NET约定（结构化错误处理，严格选项，使用

框架对象与传统VB等价物相对立）其中

合适...即Mid / Left / Right仍然击败String.Substring（），如果

只是因为优雅的错误处理））。


有什么意见，建议吗？ （PS我不是一个古老的模糊（28）......但是我从13岁开始就一直在编码。也许这就是问题！）*叹气。*

Just seeking some advice (or solace)...
Am I the only who''s having trouble letting go of notation? Having extensive
experience in C++ years ago (both before I jumped into VB3 in college and at
various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I''m dealing with a declared variable in my procedure rather than a
property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I''m dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I''ve adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I
dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pic,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation).
4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they''re ugly when seen
through intellisense).

So on and so forth. I should also note that I''m not a "resistor".... I tried
very hard to be open-minded. I''ve enthusiastically accepted a lot of the
..NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substring() anyday if
only because of the graceful error handling )).

Any comments, advice? (P.S. I''m not an old fogey (28).... but I have been
coding since I was 13. Maybe that''s the problem!) *Sigh.*

推荐答案

我同意你的意见。


但是，我懒得用s，i等标识符作为前缀并且更多地依赖

适当的评论和编写良好的代码来协助可维护性

和可读性。


因此我倾向于不使用前缀，除了像btn，lbl

这样的控件。我总是使用大写字母表示常量

-


OHM（Terry Burns）

。 。 。单手人。 。

< cm **** @ nospam.com>在消息中写道

新闻：嗯************** @ TK2MSFTNGP11.phx.gbl ...

I agree with you.

However, I am too lazy to prefix identifiers with s, i etc and rely more on
appropriately commented and well written code to assist in maintainability
and readability.

Therefore I tend not to use prefixes except with controls such as btn, lbl
as you do. I do allways use upper case for constants though
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
<cm****@nospam.com> wrote in message
news:um**************@TK2MSFTNGP11.phx.gbl...

只是寻求一些建议（或安慰）...
我是唯一一个在放弃记谱法时遇到麻烦的人吗？拥有
多年前在C ++方面的丰富经验（在我大学期间进入VB3并在我的VB职业生涯中不同时间进入
），我欢迎丰富的类型。 .NET
框架。但是，在给它机会差不多*两年之后，我仍然坚持使用常用符号表示法。 （主要是值类型）类型
（字符串，整数，布尔值等）是非常有益的。我可以立即看到我在我的程序中处理一个声明的变量而不是
一个属性或一些框架对象。即使使用o也是如此。表示其他实例化（引用）对象是有益的，因为我可以立即看到
我正在处理一个实际的实例化对象而不是一些
共享对象。类。

以下是我在.NET工作近两年后所采用的一些标准。
1）使用所有旧的VB标准用于内在类型（s，i，b，dt等等 - 是的
我在几年前删除了简单类型的3字母符号），并为常用的Framework对象增加了一些新的
（String用于StringBuilder，用于
实例）。
2）o对于所有其他较少使用的框架类型和实例化对象。
3）所有旧的VB符号用于最常见的控件（lbl，btn，txt，pic，
等）。衍生控件和花哨的自定义控件根据其目的或根来注明（即花式按钮仍然得到btn
符号）。 4）m_或更多c＃-like_表示模块级变量。
5）g_对于全局变量。
6）全局常量的全部上限。
7）我甚至试图将符号从我的程序参数中删除......但是
决定我也喜欢它们（虽然我同意通过intellisense看到它们是丑陋的。

等等。我还应该注意到，我不是一个电阻器....我b $ b非常努力地想要开放。我已经热情地接受了很多
.NET约定（结构化错误处理，严格选项，使用
框架对象与传统的VB等价物相对应（其中
适当...即中/左/右仍然击败String.Substring（）任何
，如果只是因为优雅的错误处理））。

任何评论，建议？ （PS我不是一个古老的模糊（28）....但我从13岁开始编码。也许这就是问题！）*叹气。*

Just seeking some advice (or solace)...
Am I the only who''s having trouble letting go of notation? Having extensive experience in C++ years ago (both before I jumped into VB3 in college and at various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I still
insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly
see that I''m dealing with a declared variable in my procedure rather than a property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly see
that I''m dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I''ve adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated objects.
3) All the old VB notations for the most common controls (lbl,btn,txt,pic,
etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn" notation). 4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they''re ugly when seen
through intellisense).

So on and so forth. I should also note that I''m not a "resistor".... I tried very hard to be open-minded. I''ve enthusiastically accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substring() anyday if only because of the graceful error handling )).

Any comments, advice? (P.S. I''m not an old fogey (28).... but I have been
coding since I was 13. Maybe that''s the problem!) *Sigh.*

（开玩笑......有点）我也不喜欢过于评论的代码！它让它变得难以阅读。我曾经有一个合作伙伴评论他的代码（没有

笑话！）：


''如果x大于y

如果x>然后

....


他会乱扔这些宝石，然后是整个地方。它让他的代码成为一个绝对的噩梦。


:-)


One Handed Man（ OHM - Terry Burns） < news.microsoft.com>在消息中写道

news：uo ************** @ tk2msftngp13.phx.gbl ...

(in jest... sort of) I dislike overly commented code too!.. It makes it
harder to read. I once had a partner who commented his code as such (no
joke!):

''if x is greater than y
If x > y then
....

He would litter these gems and then some all over the place. It made
maintaining his code an absolute nightmare.

:-)

"One Handed Man ( OHM - Terry Burns )" <news.microsoft.com> wrote in message
news:uo**************@tk2msftngp13.phx.gbl...

我同意你的看法。

然而，我懒得用s，i等标识前缀标识符，并且在适当注释和编写良好的代码上依赖更多
来协助可维护性和可读性。

因此，我倾向于不使用前缀，除了像btn，lbl
这样的控件。我总是使用大写字母来表示常量
-

OHM（Terry Burns）
。 。 。单手人。 。

< cm **** @ nospam.com>在消息中写道
新闻：嗯************** @ TK2MSFTNGP11.phx.gbl ...

I agree with you.

However, I am too lazy to prefix identifiers with s, i etc and rely more on appropriately commented and well written code to assist in maintainability
and readability.

Therefore I tend not to use prefixes except with controls such as btn, lbl
as you do. I do allways use upper case for constants though
--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
<cm****@nospam.com> wrote in message
news:um**************@TK2MSFTNGP11.phx.gbl...

只是寻求一些建议（或安慰）。 ..
我是唯一一个在放弃记谱法时遇到麻烦的人吗？在C ++工作年前有很多

Just seeking some advice (or solace)...
Am I the only who''s having trouble letting go of notation? Having extensive

经验（我在大学期间跳入VB3
和

experience in C++ years ago (both before I jumped into VB3 in college and at

在我的VB职业生涯中不同时间），我欢迎 ;丰富类型的" .NET
框架。但是，在给它机会差不多*两年之后，我

various times during my VB career), I welcomed the "richly-typed" .NET
framework. But, after almost *two years* of "giving it a chance," I

仍坚持使用common符号表示（主要是值类型）类型
（字符串，整数，布尔值等）是非常有益的。我可以
立刻看到我在我的程序中处理声明的变量而不是
而不是

still insist that using notation for the "common" (mostly value-types) types
(string, integer, boolean, etc.) is extremely beneficial. I can instantly see that I''m dealing with a declared variable in my procedure rather than a

属性或某个框架对象。即使使用o也是如此。表示其他实例化（引用）对象是有益的，因为我可以立即

property or some framework object. Even using "o" to denote other
instantiated (reference) objects is beneficial because I can instantly

看到我正在处理一个实际的实例化对象而不是一些
共享对象。类。

以下是我在.NET工作近两年后所采用的一些标准。
1）使用所有旧的VB标准用于内在类型（s，i，b，dt等.--
是的我

see that I''m dealing with an actual instantiated object rather than some
"Shared" Class.

Here are some of the standards I''ve adopted after almost two years of
experience in .NET.
1) Use all the old VB standards for intrinsic types (s,i,b,dt, etc.-- yeah I

在几年前删除了简单类型的3个字母表示法）以及常用Framework的一些新增加的
对象（对于StringBuilder，对于
实例）。
2）o对于所有其他较少使用的框架类型和实例化的

dropped the 3 letter notation for simple types years ago) with some new
additions for commonly used Framework objects (sb for StringBuilder, for
instance).
2) "o" for all other lesser used framework types and instantiated

对象。 3）最常见的所有旧VB符号控制
（lbl，btn，txt，pic等）。派生控件和花哨的自定义控件根据其目的或根源（即花式按钮仍然获得btn

objects. 3) All the old VB notations for the most common controls (lbl,btn,txt,pic, etc.). Derived controls and fancy custom controls get noted according to
their purpose or roots (i.e. "fancy buttons" still get the "btn"

表示法）进行注释。

notation).

4）m_或更多c＃-like_表示模块级变量。
5）g_对于全局变量。
6）全局常量的全部上限。
7）我甚至试图将符号从我的程序参数中删除......但是
决定我也喜欢它们（虽然我同意通过intellisense看到它们是丑陋的。

等等。我还应该注意，我不是一个电阻器....我

4) "m_" or the more c#-like "_" to denote module-level variables.
5) "g_" for global variables.
6) All Caps for global constants.
7) I even tried to keep notation out of my procedure parameters... but
decided I liked those too (although I agree that they''re ugly when seen
through intellisense).

So on and so forth. I should also note that I''m not a "resistor".... I

尝试

很难开放。我已经热情地接受了很多
.NET约定（结构化错误处理，严格选项，使用
框架对象与传统的VB等价物相对应（其中
适当...即中/左/右仍然击败String.Substring（）任何日子

very hard to be open-minded. I''ve enthusiastically accepted a lot of the
.NET conventions (structured error handling, options strict on, using
framework objects as oppossed to the legacy VB equivalents (where
appropriate... i.e. Mid/Left/Right still beats String.Substring() anyday

如果

只是因为优雅的错误处理））。

任何评论，建议？ （PS我不是一个古老的模糊（28）......但是我从13岁开始编码
。也许这就是问题！）*叹气。*

only because of the graceful error handling )).

Any comments, advice? (P.S. I''m not an old fogey (28).... but I have been coding since I was 13. Maybe that''s the problem!) *Sigh.*

''如果x大于y
如果x>然后
他会把这些宝石扔掉，然后是整个地方。它使得代码成为绝对的噩梦。

''if x is greater than y
If x > y then
He would litter these gems and then some all over the place. It made
maintaining his code an absolute nightmare.

有了这个，你直接回答，Cobol是第一个自我文件

程序语言，当你看到老Fortran程序员使用它时，它就变成了一个噩梦。


VB有可能使用名字使它非常好使用Cobol语言达到大多数其他语言的额外费用，不要用作

a Fortran或C类型语言，这通常需要大量额外的文档

行就像你上面看到的那样。


VB是案例性的，最好的是在我看来使用你自己的

它的自然语言风格。 （这两种方式在世界上是非常不同的。

）。


我知道我踢了很多程序员，不过这是我的想法，不是

我是怎么做的。


Cor

With this you give direct an answer, Cobol was the first selfdocumentating
program language, when you saw old Fortran programmers use it, it became
direct a nightmare.

VB has the possibility to use names which makes it very good reach that
extra in the language of Cobol above most other languages, do it not use as
a Fortran or C type language, which needs often a lot of extra documentation
rows as the one you see above.

VB is case insensetive, the nicest would be in my opinion to use your own
natural language styles for it. (Which are very different in the world by
the way).

I know I kicking to a lot of programmers, however this are my thoughts, not
how I am doing it.

Cor

这篇关于放开匈牙利表示法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！