Thing is more readable name than IThing. I'm from the school of thought that we should program to interfaces rather than specific implementations. So generally speaking, interfaces should have priority over implementations. I prefer to give the more readable name to the interface rather than the implementation (i.e., my interfaces are named without the 'I' prefix).
个人而言（也许是出于习惯）我喜欢 I 前缀，因为它简洁地标记接口，使我能够与实现类型进行一对一的命名对应。 当您想要提供 base 实现时，这会很有效：IThing 是接口，Thing 是基础（可能是 abstract< /代码>）类型。 派生类型可以是 SomeThing。 我喜欢能够使用如此清晰的速记符号。
I'm sure your question was the topic of many lengthy discussions within the Microsoft team that worked on the .NET Framework and its standards.
I think the most telling example comes from the source itself. Below, I transcribe extracts from Framework Design Guidelines, a book I highly recommend.
From Krzysztof Cwalina, CLR program manager:
The only prefix used is "I" for interfaces (as in ICollection), but that is for historical reasons. In retrospect, I think it would have been better to use regular type names. In a majority of the cases developers don't care that something is an interface and not an abstract class, for example.
From Brad Abrams, CLR and .NET Framework program manager:
On the other hand, the "I" prefix on interfaces is a clear recognition of the influence of COM (and Java) on the .NET Framework. COM popularized, even institutionalized, the notation that interfaces begin with "I." Although we discussed diverging from this historic pattern we decided to carry forward the pattern as so many of our users were already familiar with COM.
From Jeffrey Richter, consultant and author:
Personally, I like the "I" prefix and I wish we had more stuff like this. Little one-character prefixes go a long way toward keeping code terse and yet descriptive. [...] I use prefixes for my private type fields because I find this very useful.
My point is, it WAS on the discussion table. An advantage I see is that it helps avoid name collisions between classes and interfaces, so your names can be both descriptive and compact
Personally--and perhaps out of habit--I like the I prefix, because it succinctly flags interfaces, allowing me to have one-to-one naming correspondence with implementing types. This shines in cases when you want to provide a base implementation: IThing is the interface, Thing is the base (perhaps abstract) type. Derived types can be SomeThing. I love being able to use such crystal clear shorthand notation.
I think it is better than adding a "Impl" suffix on your concrete class. It is a single letter, and this convention is well established. Of course you are free to use any naming you wish.
在我看来，这个“我”只是视觉噪音。 IDE 应该以不同的方式显示类和接口名称。 幸运的是，Java 标准库不使用此约定。
In my opinion this 'I' is just visual noise. IDE should show class and interface names differently. Fortunately Java standard library doesn't use this convention.
不使用 I 接口约定并没有什么问题 - 只要保持一致并确保它不仅适合您而且适合整个团队（如果有的话）。
There is nothing wrong with NOT using I convention for interfaces - just be consistent and make sure it works not just for you but for whole team (if there is one).
Naming an interface should have much deeper meaning than just whether or not you put an "I" at the front of the name.
Neither "Fruit" nor "IFruit" would have a whole lot of meaning for me as an interface. This is because it looks a lot more like a class. Classes define things, whereas interfaces should define functionality.
The "I" naming convention does help differentiate between classes and interfaces so that development is a little bit easier. And while it is not required, it certainly helps avoid common object oriented coding headaches. C#, like Java, only allows for inheritance from a single base class. But you can implement as many interfaces as you want. The caveat is, if you inherit from a class and implement one or more interfaces, the base class has to be named first (i.e. class Trout: Fish, ISwimmer, IDiver ... ).
I really like to name my interfaces both based based on what functionality they provide as well as what type of interface they are (i.e. animate or inanimate interfaces).
If you focus on in functionality that the interface provides you can quickly determine a name for the interface. It also helps you to quickly see if your interface defines unrelated functions.
Interfaces that define inanimate objects (i.e. things that can't act on their own)... I like to name them with ...able at the end IPrintable (such as Document, Invoice) IPlayable (such as Instrument, MediaPlayer) ISavable (such as Document, Image) IEdible (such as Fruit, Beef) IDrivable (such as Car) IFlyable (such as Plane)
Interfaces that define animate objects (i.e. things that act on their own)... I like to name them with ...er at the end ISwimer (such as Fish, Dog, Duck) IDiver (such as Fish, Duck) IFlyer (such as Pilot) IDriver (such as NascarDriver)
In the end, the "I" naming convention helps differentiate between interfaces and classes. But it may make sense to add additional naming logic besides just the "I" at the beginning.
Because you usually have an IThing and a Thing. So instead of letting people come with their own "conventions" for this recurring situation, a uniform one-size-fits all convention was chosen. Echoing what others say, the de facto standardness is reason enough to use it.
It's just a convention that's intent is to prevent name collisions. C# does not allow me to have a class and an interface named Client, even if the file names are Client and IClient, respectively. I'm comfortable using the convention; if I had to offer a different convention I'd suggest using "Contract" as a suffix, e.g. ClientContract.
I don't know exactly why they chose that convention, perhaps partly thinking of ensouling the class with "I" as in "I am Enumerable".
A naming convention that would be more in the line of the rest of the framework would be to incorporate the type in the name, as for example the xxxAttribute and xxxException classes, making it xxxInterface. That's a bit lengthy though, and after all the interfaces is something separate, not just another bunch of classes.
I know the Microsoft guidelines recommends using the 'I' to describe it as an interface. But this comes from IBM naming conventions if I'm not remember wrong, the initiating 'I' for interfaces and the succeeding *Impl for the implementations.
However, in my opinion the Java Naming Conventions is a better choice than the IBM naming convention (and not only in Java, for C# as well and any OO programming language). Interfaces describes what an object can be able to do if it implements the interface and the description should be in verb form. I.e Runnable, Serializable, Invoiceable, etc. IMHO this is a perfect description of what the interface represents.
It's popular for an OS GUI to use different icons for files and folders. If they all shared the same icons, but folders were prefixed with "F", it would be acceptable to use the same icon. But, since humans' image recognition speed is faster than their word recognition speed, we have settled on icons.
Computer programs like IDEs are fully capable of making a file's interface-ness apparent. This would free the namespace of different levels of abstraction happening in the same name. E.g. in "ICare", "I" describes the implementation and "Care" describes the interface's capabilities.
I'm guessing the "I" convention is so popular because we haven't been able to think of anything better, but it's existence is important because it points out a need we have for knowing this kind of information.
Also (this is more of a personal observation than dictated from upon high), interfaces describe what a class does. The 'I' lends itself to this (I'm sure it is a construct in grammar which would be great to whip out right now); an interface that describes classes that validate would be "IValidate". One that describes matching behavior would be "IMatch".
I don't really like this convention. I understand that it helps out with the case when you have an interface and an implementation that would have the same name, but I just find it ugly. I'd still follow it if it were the convention where I am working, of course. Consistency is the point of conventions, and consistency is a very good thing.
I like to have an interface describe what the interface does in as generic a way as possible, for example, Validator. A specific implementation that validates a particular thing would be a ThingValidator, and an implementation with some abstract functionality shared by Validators would be an AbstractValidator. I would do this even if Thing is the only... well... thing that I'm validating, and Validator would be generic.
In cases where only one concrete class makes sense for an interface, I still try to describe something specific about that particular implementation rather than naming the interface differently to prevent a names collision. After all, I'm going to be typing the name of the interface more often than the name of the implementation.
You may add the word "Interface" as a suffix to your customized interface for example "SerializerInterface". For abstract class, "Fruit", for instance, "FruitAbstract" or you can make it "AbstractFruit", just be consistent all through out. That is readable enough, or follow the usual naming convention.
The reason why I personally append the suffix "Interface" is because it is easier to read than the "I" prefix and because the files in the system are listed "grouped". For example:
But that's just personal taste. I think as long as one uses a consistent naming convention throughout the entire project, nothing speaks against using your own naming convention.
Conventions (and criticism against them) all have a reason behind them, so let's run down some reasons behind conventions
Interfaces are prefixed as I to differentiate interface types from implementations - e.g., as mentioned above there needs to be an easy way to distinguish between Thing and its interface IThing so the convention serves to this end.
Interfaces are prefixed I to differentiate it from abstract classes - There is ambiguity when you see the following code:
public class Apple: Fruit
Without the convention one wouldn't know if Apple was inheriting from another class named Fruit, or if it were an implementation of an interface named Fruit, whereas IFruit will make this obvious:
public class Apple: IFruit
Principle of least surprise applies.
Not all uses of hungarian notation are censured - Early uses of Hungarian notation signified a prefix which indicated the type of the object and then followed by the variable name or sometimes an underscore before the variable name. This was, for certain programming environments (think Visual Basic 4 - 6) useful but as true object-oriented programming grew in popularity it became impractical and redundant to specify the type. This became especially issue when it came to intellisense.
Today hungarian notation is acceptable to distinguish UI elements from actual data and similarly associated UI elements, e.g., txtObject for a textbox, lblObject for the label that is associated with that textbox, while the data for the textbox is simply Object.
I also have to point out that the original use of Hungarian notation wasn't for specifying data types (called System Hungarian Notation) but rather, specifying the semantic use of a variable name (called Apps Hungarian Notation). Read more on it on the wikipedia entry on Hungarian Notation.
The reason I do it is simple: because that's the convention. I'd rather just follow it than have all my code look different, making it harder to read and learn.
Well, one obvious consideration would be the (very common) IFoo and Foo pair (when abstracting Foo), but more generally it is often fundamental to know whether something is an interface vs class. Yes it is partly redundant, but IMO is is different from things like sCustomerName - here, the name itself (customerName) should be enough to understand the variable.
But with CustomerRepository - it that a class, or the abstract interface?
Also: expectation; the fact is, right or wrong, that is what people expect. That is almost reason enough.
发布评论
评论（21）
Thing是比IThing更易读的名称。 我的思想流派认为我们应该针对接口而不是特定的实现进行编程。 所以一般来说，接口应该优先于实现。 我更喜欢为接口而不是实现提供更易读的名称（即，我的接口命名时不带“I”前缀）。Thingis more readable name thanIThing. I'm from the school of thought that we should program to interfaces rather than specific implementations. So generally speaking, interfaces should have priority over implementations. I prefer to give the more readable name to the interface rather than the implementation (i.e., my interfaces are named without the 'I' prefix).我确信您的问题是致力于 .NET Framework 及其标准的 Microsoft 团队内部多次长时间讨论的主题。
我认为最有说服力的例子来自来源本身。 下面，我抄录了框架设计指南的摘录，我强烈推荐的一本书。
CLR 项目经理 Krzysztof Cwalina 表示：
来自 CLR 和 .NET Framework 项目经理 Brad Abrams：
顾问兼作家杰弗里·里克特 (Jeffrey Richter) 表示：
我的观点是，它已经在讨论桌上了。 我看到的一个优点是它有助于避免类和接口之间的名称冲突，因此您的名称可以既具有描述性又紧凑。就
个人而言（也许是出于习惯）我喜欢
I前缀，因为它简洁地标记接口，使我能够与实现类型进行一对一的命名对应。 当您想要提供base实现时，这会很有效：IThing是接口，Thing是基础（可能是abstract< /代码>）类型。 派生类型可以是SomeThing。 我喜欢能够使用如此清晰的速记符号。I'm sure your question was the topic of many lengthy discussions within the Microsoft team that worked on the .NET Framework and its standards.
I think the most telling example comes from the source itself. Below, I transcribe extracts from Framework Design Guidelines, a book I highly recommend.
From Krzysztof Cwalina, CLR program manager:
From Brad Abrams, CLR and .NET Framework program manager:
From Jeffrey Richter, consultant and author:
My point is, it WAS on the discussion table. An advantage I see is that it helps avoid name collisions between classes and interfaces, so your names can be both descriptive and compact
Personally--and perhaps out of habit--I like the
Iprefix, because it succinctly flags interfaces, allowing me to have one-to-one naming correspondence with implementing types. This shines in cases when you want to provide abaseimplementation:IThingis the interface,Thingis the base (perhapsabstract) type. Derived types can beSomeThing. I love being able to use such crystal clear shorthand notation.我认为这比在具体类上添加“Impl”后缀更好。 它只是一个字母，而且这个约定已经很完善了。 当然，您可以随意使用任何您想要的命名。
I think it is better than adding a "Impl" suffix on your concrete class. It is a single letter, and this convention is well established. Of course you are free to use any naming you wish.
在我看来，这个“我”只是视觉噪音。 IDE 应该以不同的方式显示类和接口名称。 幸运的是，Java 标准库不使用此约定。
In my opinion this 'I' is just visual noise. IDE should show class and interface names differently. Fortunately Java standard library doesn't use this convention.
不使用 I 接口约定并没有什么问题 - 只要保持一致并确保它不仅适合您而且适合整个团队（如果有的话）。
There is nothing wrong with NOT using I convention for interfaces - just be consistent and make sure it works not just for you but for whole team (if there is one).
为接口命名应该具有比是否在名称前面添加“I”更深刻的含义。
作为一个界面，“Fruit”和“IFruit”对我来说都没有太多意义。 这是因为它看起来更像一个类。 类定义事物，而接口应该定义功能。
“I”命名约定确实有助于区分类和接口，以便开发更容易一些。 虽然这不是必需的，但它确实有助于避免常见的面向对象编码难题。 C# 与 Java 一样，只允许从单个基类继承。 但您可以根据需要实现任意多个接口。 需要注意的是，如果您从一个类继承并实现一个或多个接口，则必须首先命名基类（即类 Trout：Fish、ISwimmer、IDiver ...）。
我真的很喜欢根据它们提供的功能以及它们的接口类型（即动画或无动画接口）来命名我的接口。
如果您关注接口提供的功能，您可以快速确定接口的名称。 它还可以帮助您快速查看您的接口是否定义了不相关的函数。
定义无生命对象（即不能自行行动的事物）的接口...
我喜欢在最后用 ...able 来命名它们
可打印（如文档、发票）
IPlayable（例如 Instrument、MediaPlayer）
ISavable（例如文档、图像）
I 可食用（如水果、牛肉）
IDriveable（例如汽车）
IFlyable（例如 Plane）
定义动画对象（即自行行动的事物）的接口...
我喜欢在最后用...呃来命名它们
ISwimer（例如鱼、狗、鸭）
IDiver（例如鱼、鸭）
IFlyer（例如 Pilot）
IDriver（例如NascarDriver）
最后，“I”命名约定有助于区分接口和类。 但除了开头的“I”之外，添加额外的命名逻辑可能是有意义的。
Naming an interface should have much deeper meaning than just whether or not you put an "I" at the front of the name.
Neither "Fruit" nor "IFruit" would have a whole lot of meaning for me as an interface. This is because it looks a lot more like a class. Classes define things, whereas interfaces should define functionality.
The "I" naming convention does help differentiate between classes and interfaces so that development is a little bit easier. And while it is not required, it certainly helps avoid common object oriented coding headaches. C#, like Java, only allows for inheritance from a single base class. But you can implement as many interfaces as you want. The caveat is, if you inherit from a class and implement one or more interfaces, the base class has to be named first (i.e. class Trout: Fish, ISwimmer, IDiver ... ).
I really like to name my interfaces both based based on what functionality they provide as well as what type of interface they are (i.e. animate or inanimate interfaces).
If you focus on in functionality that the interface provides you can quickly determine a name for the interface. It also helps you to quickly see if your interface defines unrelated functions.
Interfaces that define inanimate objects (i.e. things that can't act on their own)...
I like to name them with ...able at the end
IPrintable (such as Document, Invoice)
IPlayable (such as Instrument, MediaPlayer)
ISavable (such as Document, Image)
IEdible (such as Fruit, Beef)
IDrivable (such as Car)
IFlyable (such as Plane)
Interfaces that define animate objects (i.e. things that act on their own)...
I like to name them with ...er at the end
ISwimer (such as Fish, Dog, Duck)
IDiver (such as Fish, Duck)
IFlyer (such as Pilot)
IDriver (such as NascarDriver)
In the end, the "I" naming convention helps differentiate between interfaces and classes. But it may make sense to add additional naming logic besides just the "I" at the beginning.
因为你通常有一个 IThing 和一个 Thing。 因此，我们没有让人们针对这种反复出现的情况制定自己的“惯例”，而是选择了一种统一的一刀切的惯例。 呼应其他人的说法，事实上的标准性足以成为使用它的理由。
Because you usually have an IThing and a Thing. So instead of letting people come with their own "conventions" for this recurring situation, a uniform one-size-fits all convention was chosen. Echoing what others say, the de facto standardness is reason enough to use it.
这只是一个约定，其目的是防止名称冲突。 C# 不允许我拥有名为 Client 的类和接口，即使文件名分别为 Client 和 IClient。 我很乐意使用惯例； 如果我必须提供不同的约定，我建议使用“Contract”作为后缀，例如 ClientContract。
It's just a convention that's intent is to prevent name collisions. C# does not allow me to have a class and an interface named Client, even if the file names are Client and IClient, respectively. I'm comfortable using the convention; if I had to offer a different convention I'd suggest using "Contract" as a suffix, e.g. ClientContract.
该指南没有解释为什么您应该使用
I前缀，但事实上这已经是一个既定的约定，这应该是足够的理由。删除
I前缀可以获得什么好处？The guideline doesn't explain why you should use the
Iprefix, but the fact that this is now an established convention should be reason enough.What do you have to gain by dropping the
Iprefix?我不知道他们为什么选择这个惯例，也许部分是想用“我”来赋予班级灵魂，就像“我是可枚举的”一样。
与框架其余部分更一致的命名约定是将类型合并到名称中，例如 xxxAttribute 和 xxxException 类，使其成为 xxxInterface。 虽然这有点冗长，毕竟接口是独立的东西，而不仅仅是另一堆类。
I don't know exactly why they chose that convention, perhaps partly thinking of ensouling the class with "I" as in "I am Enumerable".
A naming convention that would be more in the line of the rest of the framework would be to incorporate the type in the name, as for example the xxxAttribute and xxxException classes, making it xxxInterface. That's a bit lengthy though, and after all the interfaces is something separate, not just another bunch of classes.
我知道 Microsoft 指南建议使用“I”来将其描述为界面。 但如果我没记错的话，这来自 IBM 命名约定，起始的“I”代表接口，后续的 *Impl 代表实现。
然而，在我看来，Java 命名约定是比 IBM 命名约定更好的选择（不仅在 Java 中，对于 C# 以及任何 OO 编程语言也是如此）。 接口描述了一个对象在实现该接口的情况下能够执行的操作，并且该描述应该采用动词形式。 即可运行、可序列化、可发票等。恕我直言，这是对接口所代表内容的完美描述。
I know the Microsoft guidelines recommends using the 'I' to describe it as an interface. But this comes from IBM naming conventions if I'm not remember wrong, the initiating 'I' for interfaces and the succeeding *Impl for the implementations.
However, in my opinion the Java Naming Conventions is a better choice than the IBM naming convention (and not only in Java, for C# as well and any OO programming language). Interfaces describes what an object can be able to do if it implements the interface and the description should be in verb form. I.e Runnable, Serializable, Invoiceable, etc. IMHO this is a perfect description of what the interface represents.
在我看来，它看起来像匈牙利语。 匈牙利语通常被认为是强类型语言中的威胁。
由于 C# 是 Microsoft 产品，而匈牙利表示法是 Microsoft 的发明，因此我可以看出 C# 可能会在哪些方面受到其影响。
It looks Hungarianish to me. Hungarian is generally considered a menace in strongly-typed languages.
Since C# is a Microsoft product and Hungarian notation was a Microsoft invention, I can see where C# might be susceptible to its influence.
操作系统 GUI 对文件和文件夹使用不同的图标是很流行的。 如果它们都共享相同的图标，但文件夹以“F”为前缀，则使用相同的图标是可以接受的。 但是，由于人类的图像识别速度比文字识别速度快，所以我们选择了图标。
像 IDE 这样的计算机程序完全能够使文件的界面性变得明显。 这将释放同名中发生的不同抽象级别的名称空间。 例如，在“ICare”中，“I”描述实现，“Care”描述接口的功能。
我猜“我”约定之所以如此受欢迎，是因为我们想不出更好的东西，但它的存在很重要，因为它指出了我们了解此类信息的需要。
It's popular for an OS GUI to use different icons for files and folders. If they all shared the same icons, but folders were prefixed with "F", it would be acceptable to use the same icon. But, since humans' image recognition speed is faster than their word recognition speed, we have settled on icons.
Computer programs like IDEs are fully capable of making a file's interface-ness apparent. This would free the namespace of different levels of abstraction happening in the same name. E.g. in "ICare", "I" describes the implementation and "Care" describes the interface's capabilities.
I'm guessing the "I" convention is so popular because we haven't been able to think of anything better, but it's existence is important because it points out a need we have for knowing this kind of information.
将接口与类分开。
另外（这更多的是个人观察，而不是高层的指示），接口描述了类的作用。 “我”适合于此（我确信这是语法中的一个构造，现在就可以快速提出）； 描述验证类的接口是“IValidate”。 描述匹配行为的一个是“IMatch”。
To separate interfaces from classes.
Also (this is more of a personal observation than dictated from upon high), interfaces describe what a class does. The 'I' lends itself to this (I'm sure it is a construct in grammar which would be great to whip out right now); an interface that describes classes that validate would be "IValidate". One that describes matching behavior would be "IMatch".
事实上，每个人都理解它，编写更好的代码的一部分就是使其易于阅读和理解。
The fact of the matter is that everyone understands it and part of writing better code is making it easy to read and understand.
我不太喜欢这个大会。 我知道当你有一个接口和一个具有相同名称的实现时，它会有所帮助，但我只是觉得它很难看。 当然，如果这是我工作的会议，我仍然会遵循它。 一致性是约定的要点，一致性是一件非常好的事情。
我喜欢让接口以尽可能通用的方式描述接口的功能，例如，
Validator。 验证特定事物的特定实现将是ThingValidator，而具有由Validator共享的某些抽象功能的实现将是AbstractValidator。 即使Thing是我正在验证的唯一...嗯...东西，并且Validator是通用的，我也会这样做。在只有一个具体类对接口有意义的情况下，我仍然尝试描述有关该特定实现的特定内容，而不是以不同的方式命名接口以防止名称冲突。 毕竟，我将比输入实现的名称更频繁地输入接口名称。
I don't really like this convention. I understand that it helps out with the case when you have an interface and an implementation that would have the same name, but I just find it ugly. I'd still follow it if it were the convention where I am working, of course. Consistency is the point of conventions, and consistency is a very good thing.
I like to have an interface describe what the interface does in as generic a way as possible, for example,
Validator. A specific implementation that validates a particular thing would be aThingValidator, and an implementation with some abstract functionality shared byValidators would be anAbstractValidator. I would do this even ifThingis the only... well... thing that I'm validating, andValidatorwould be generic.In cases where only one concrete class makes sense for an interface, I still try to describe something specific about that particular implementation rather than naming the interface differently to prevent a names collision. After all, I'm going to be typing the name of the interface more often than the name of the implementation.
您可以将“Interface”一词作为后缀添加到您的自定义界面，例如“SerializerInterface”。 对于抽象类，“Fruit”，例如“FruitAbstract”，或者您可以将其设为“AbstractFruit”，只需始终保持一致即可。 这是足够可读的，或者遵循通常的命名约定。
You may add the word "Interface" as a suffix to your customized interface for example "SerializerInterface". For abstract class, "Fruit", for instance, "FruitAbstract" or you can make it "AbstractFruit", just be consistent all through out. That is readable enough, or follow the usual naming convention.
只是我的 2 美分：
我个人附加后缀“Interface”的原因是因为它比“I”前缀更容易阅读，并且因为系统中的文件是“分组”列出的。 例如：
不太好：
更好：
但这只是个人品味。 我认为只要在整个项目中使用一致的命名约定，就没有什么可以反对使用自己的命名约定。
Just my 2 cents:
The reason why I personally append the suffix "Interface" is because it is easier to read than the "I" prefix and because the files in the system are listed "grouped". For example:
Not so good:
Better:
But that's just personal taste. I think as long as one uses a consistent naming convention throughout the entire project, nothing speaks against using your own naming convention.
约定（以及针对它们的批评）都有其背后的原因，所以让我们来分析一下约定背后的一些原因
接口以 I 为前缀，以区分接口类型和实现 - 例如，如上所述需要有一种简单的方法来区分
Thing及其接口IThing，因此约定用于此目的。接口以 I 为前缀，以区别于抽象类 - 当您看到以下代码时会产生歧义：
公共课苹果：水果如果没有约定，人们就无法知道
Apple是否继承于另一个名为Fruit的类，或者它是否是一个名为Fruit的接口的实现，而IFruit将使这一点显而易见：苹果公共类：IFruit适用最小惊喜原则。
并非所有匈牙利表示法的使用都受到谴责 - 匈牙利表示法的早期使用表示表示对象类型的前缀，然后是变量名称，有时在变量名称之前有下划线。 这对于某些编程环境（例如 Visual Basic 4 - 6）很有用，但随着真正的面向对象编程的日益流行，指定类型变得不切实际且多余。 当涉及到智能感知时，这变得尤其重要。
如今，匈牙利符号可以用来区分 UI 元素与实际数据以及类似的关联 UI 元素，例如，
txtObject表示文本框，lblObject表示关联的标签该文本框，而文本框的数据只是对象。我还必须指出，匈牙利表示法的最初用途不是用于指定数据类型（称为系统匈牙利表示法），而是指定变量名称的语义使用（称为应用程序匈牙利表示法）。 在有关匈牙利表示法的维基百科条目上了解更多相关信息。
Conventions (and criticism against them) all have a reason behind them, so let's run down some reasons behind conventions
Interfaces are prefixed as I to differentiate interface types from implementations - e.g., as mentioned above there needs to be an easy way to distinguish between
Thingand its interfaceIThingso the convention serves to this end.Interfaces are prefixed I to differentiate it from abstract classes - There is ambiguity when you see the following code:
public class Apple: FruitWithout the convention one wouldn't know if
Applewas inheriting from another class namedFruit, or if it were an implementation of an interface namedFruit, whereasIFruitwill make this obvious:public class Apple: IFruitPrinciple of least surprise applies.
Not all uses of hungarian notation are censured - Early uses of Hungarian notation signified a prefix which indicated the type of the object and then followed by the variable name or sometimes an underscore before the variable name. This was, for certain programming environments (think Visual Basic 4 - 6) useful but as true object-oriented programming grew in popularity it became impractical and redundant to specify the type. This became especially issue when it came to intellisense.
Today hungarian notation is acceptable to distinguish UI elements from actual data and similarly associated UI elements, e.g.,
txtObjectfor a textbox,lblObjectfor the label that is associated with that textbox, while the data for the textbox is simplyObject.I also have to point out that the original use of Hungarian notation wasn't for specifying data types (called System Hungarian Notation) but rather, specifying the semantic use of a variable name (called Apps Hungarian Notation). Read more on it on the wikipedia entry on Hungarian Notation.
我这样做的原因很简单：因为这是惯例。 我宁愿遵循它，也不愿让我的所有代码看起来都不同，从而使其更难阅读和学习。
The reason I do it is simple: because that's the convention. I'd rather just follow it than have all my code look different, making it harder to read and learn.
好吧，一个明显的考虑因素是（非常常见的）
IFoo和Foo对（当抽象Foo时），但更一般而言，它通常是基本的知道某个东西是接口还是类。 是的，它有部分冗余，但 IMO 与sCustomerName之类的东西不同 - 在这里，名称本身 (customerName) 应该足以理解该变量。但是对于
CustomerRepository- 它是一个类，还是抽象接口？还有：期望； 事实是，无论对错，这就是人们的期望。 这几乎就足够了。
Well, one obvious consideration would be the (very common)
IFooandFoopair (when abstractingFoo), but more generally it is often fundamental to know whether something is an interface vs class. Yes it is partly redundant, but IMO is is different from things likesCustomerName- here, the name itself (customerName) should be enough to understand the variable.But with
CustomerRepository- it that a class, or the abstract interface?Also: expectation; the fact is, right or wrong, that is what people expect. That is almost reason enough.