假设您继承了一个C#代码库,该代码库使用一个具有200个静态方法的类来提供核心功能(例如数据库查找).在那个班级的许多噩梦中,有大量使用匈牙利符号(坏类型).
你会重构变量名来删除匈牙利表示法吗,还是会让他们独自一人？
如果您选择更改所有变量以删除匈牙利表示法,那么您的方法是什么？
我正在使用系统匈牙利符号的旧式COM C ++项目。因为这是对遗留代码的维护，所以约定以原始样式编写代码-我们的较新代码不是用这种方式编码的。因此，我对更改该标准或对我们过去的罪过进行讨论不感兴趣=）
是否有针对系统匈牙利符号的在线备忘单？
到目前为止，我能找到的最好的文章是堆栈溢出之前的讨论帖子，但是它并没有我过去需要的所有东西。有人还有其他链接吗？
（制作此社区Wiki，希望它能成为一个自我填充的列表）
我已经阅读了整个网络上的教程,并在游戏中指定了不同类型的教程(但事实证明这很普遍).
是否有任何理由为什么许多开发人员将他们的变量命名为:
mContext
对我来说,默认只是将其命名为"上下文"或类似的东西.
之前有"m"的原因吗？(我知道这是一个风格问题,但我只是好奇它代表什么)
我必须对使用匈牙利表示法的遗留代码(以及匈牙利语系统)进行一些维护.不幸的是,从代码库中清除它是不切实际的.
本地Eclipse用户声称可以配置Eclipse,以便自动生成的访问器和诸如忽略匈牙利前缀的东西(这可能是他们能够与他们共存这么久的原因).
IDEA 10.5中是否有类似的功能？如果'找到用法' m_sInstruction足够智能,可以意识到这getInstruction()是一个吸气剂,并给我'你想搜索存取器吗？' 例如,提示,或者如果'生成getter和setter'可以告诉该类已经为几乎所有字段提供了它们.
我完全同意我们不应该使用匈牙利表示法来命名变量.但似乎匈牙利表示法对名称控件(尤其是Winform控件)仍然有用.考虑这些:
GridView grvUsers
TextBox txtPassword
等等...
我真的怀疑在这种情况下我们应该避免使用匈牙利符号吗？如果应该,这是名称控件的替代解决方案？
编写异常安全代码时,必须考虑所有调用函数的异常安全保证(无,基本,强或无抛出).由于编译器没有提供任何帮助,我认为函数命名约定在这里可能会有所帮助.是否有任何已建立的标准标准,表明功能提供的异常安全保证水平？我正在思考匈牙利式的事情:
void setFooB(Foo const& s); // B, offers basic guarantee
int computeSomethingS(); // S, offers strong guarantee
int getDataNT() throws(); // NT, offers no-throw
void allBetsAreOffN(); // N, offers no guarantee
编辑:我同意评论这种命名惯例是丑陋的,所以请允许我详细说明我的建议理由.
假设我重构了一些代码,并在此过程中,更改函数提供的异常安全级别.如果保证已经从强到基(从可能通过提高速度来证明)得到改变,则必须重新考虑调用重构函数的每个函数的异常安全性.如果保证的更改也触发了函数名称的更改,那么它将允许编译器帮助我一点点,至少标记已更改函数的所有用法.这是我建议上面的命名约定的理由,尽管有问题.这与const非常相似,其中函数const的整体变化对其他调用函数具有级联效应,但在这种情况下,编译器会提供非常有效的帮助.
所以我想我的问题是,为了确保代码实际上满足其预期的异常保证,特别是在代码维护和重构期间,人们开发了什么样的工作习惯.
我有这门课:
class DoSomething
{
private int timesDone;
...
}
命名变量'timesDone'的正确方法是什么？
有时我看到名为m_timesDone.它是否正确？我在哪里可以找到有关命名指南的信息？
谢谢!
我正在研究的项目规定了类成员变量的匈牙利表示法.例:String m_foo;
是否有可能在生成getter和setter时使Eclipse剥离匈牙利语前缀？我使用的是太阳神和它表明(这并不奇怪)getM_foo和setM_foo,但我想getFoo和setFoo.代码模板看起来没有帮助.
我知道这个问题已经被问了一下,从它的外观来看,这个问题没有明确的是或否答案,但是,我仍然对某些事情感到困惑.
通常在我编程时,我遵循一些关于前缀的规则:
我现在有一份新工作,我注意到代码中没有使用前缀.我问为什么,他们回答说IDE完成了跟踪成员变量是什么以及什么是局部变量的所有工作.现在我在想,可能是这样,但是使用前缀不是更容易吗？
我的意思是,如果我有一个成员,一个静态和一个名为"机器人"的局部变量,在编写方法时引用它是不是很麻烦？这可能是一个不切实际的例子,但我喜欢在我的头脑中设置一个良好的规则,即使是在不切实际的条件下,我也可以始终如一地应用.
这个例子是否适合使用匈牙利表示法？
我想我会制作一个优点/缺点列表并在我了解更多信息时对其进行编辑.
反对匈牙利人的论点:
Class.Robot 要么 Robot
this.robot
robot
不需要匈牙利人.
计数器:
仍然存在不一致性,机器人在不同的方法中可能意味着不同的东西.为了保持一致,你应该在每个Robot变量之前为Class或this(或没有)添加前缀.
最重要的是,假设你想要访问静态变量Strawberry,你怎么知道名为Strawberry的成员变量没有定义？也许它是在另一个你看不到的文件中定义的,所以你可能会得到意想不到的结果.现在您可能会说这是通过IDE可见的,但我认为使用前缀是优越的,因为您看到了您正在引用的内容,而您可能会错过IDE告诉您的内容.当然,您也可以使用此/ Classname前缀,但这种做法违背了不使用匈牙利表示法的目的.
反对匈牙利人的论点:
当在字段和变量的命名中使用匈牙利表示法时,会违反此规则.在C++代码中使用匈牙利表示法已经很普遍,但C#的趋势是为变量使用更长,更具描述性的名称,这些名称不是基于变量的类型,而是描述变量的用途.
计数器:
我提到的前缀不是基于变量的类型,前缀实际上指定了变量的用途.
反对匈牙利人的论点:
现代代码编辑器(如Visual Studio)可以轻松识别变量或字段的类型信息,通常是将鼠标光标悬停在变量名称上.这减少了对匈牙利表示法的需要.
计数器:
虽然这是真的,但除非发生错误,否则我自己几乎不会将鼠标悬停在变量名称上方.相反,使用匈牙利表示法,您可以立即看到变量在类中的位置.
备注:
Microsoft不推荐使用匈牙利表示法来表示文件名吗？我读到接口文件前缀为I是一种惯例,这是匈牙利表示法的一种形式.虽然这与我上面的问题没有直接关系,但它确实提出了有时建议使用匈牙利符号的观点.
我是 RTOS 和 C 编程的新手，而且我仍在习惯 C 的良好实践。因此，我打开了一个使用 FreeRTOS 的项目，我注意到操作系统文件使用匈牙利表示法。我知道一点符号，但在文件中遇到了一些新的“标准” FreeRTOS.h，它们是：
#ifndef configASSERT
#define configASSERT( x )
#define configASSERT_DEFINED 0
#else
#define configASSERT_DEFINED 1
#endif
在那之下，
#ifndef INCLUDE_xTaskGetSchedulerState
#define INCLUDE_xTaskGetSchedulerState 0
#endif
#ifndef INCLUDE_xTaskGetCurrentTaskHandle
#define INCLUDE_xTaskGetCurrentTaskHandle 0
#endif
我到处都看到过这个x - 就像x TaskGetCurrentTaskHandle一样。此外，v、pd和类似的变量名称，如728相关标题行中所示：
#if configENABLE_BACKWARD_COMPATIBILITY == 1
#define eTaskStateGet eTaskGetState
#define portTickType TickType_t
#define xTaskHandle TaskHandle_t
#define xQueueHandle QueueHandle_t
#define xSemaphoreHandle SemaphoreHandle_t
#define xQueueSetHandle QueueSetHandle_t
#define xQueueSetMemberHandle QueueSetMemberHandle_t
#define xTimeOutType TimeOut_t
#define …