大小写约定

标识符的大小写规则

PascalCasing：如HtmlTag  IOStream

camelCasing：如htmlTag  ioStream

• 要把PascalCasing用于由多个单词构成的名字空间、类型、以及成员的名字；
• 要把camelCasing用于参数的名字。

通用命名约定

单词的选择

对框架中标识符的名字来说，很重要的一点是一目了然。

名字的意思清楚比长度短更重要。名字应该与场景、系统的逻辑组成或物理组成以及为人熟知的概念相对应，而不应该与技术或框架相对应。

• 要为标识符选择易于阅读的名字；
• 要更看重可读性，而不是更看重简短性；
• 不要使用下划线、连字符以及其他任何既非字母也非数字的字符；
• 不要使用匈牙利命名法；
• 避免使用与广泛使用的编程语言的关键字有冲突的标识符。

使用单词缩写和首字母缩写词

一般来说，不要在标识符中使用单词缩写或首字母缩写：宁可名字长一点，也不要别人看不懂。  尤其不要使用未被广泛接受的单词缩写和首字母缩写词。

• 不要使用缩写词或缩略词作为标识符名字的一部分
  用GetWindow  不用GetWin
• 不要使用未被广泛接受的首字母缩写词
  多谓广泛接受：用搜索引擎在网上搜索该首字母缩写词，如果返回的前几个结果与期望相符，那么该首字母缩写词才有资格被称为众所周知。

避免使用语言特有的名字

• 要给类型名使用语义上有意义的名字，而不要使用特有的关键字
  GetLength比GetInt要好
• 要使用CLR的通用类型名，而不要使用语言特有的别名
• 要使用常见的名字，比如value或item，而不要重复类型的名字

为已有API的新版本命名

当用新类型和新成员接替或取代已有的类型或成员时，如何选择名字：

• 使用与旧API相似的名字
• 要优先使用后缀而不是前缀来表示已有API的新版本
  这样有助于在浏览文档或使用Intellisense时发现新版本：按字母排序
• 可以考虑使用全新但有意义的标识符
• 要使用数字后缀来表示已有API的新版本
  有些名字（或工业标准）不宜添加后缀或改名
• 不要在标识符中使用“Ex”“New”等类似的后缀来区分相同API的不同版本
• 要在引入64位整数（long）而非32位整数进行操作的新版本API时使用“64”后缀，反之亦然。

程序集和DLL的命名

程序集是一个部署单元，同时还代表托管代码程序的身份。虽然程序集可以分布一个或多个文件中，但一般来说一个程序集仅与一个DLL相对应。

名字空间与DLL程序集的区别：

名字空间：一组逻辑实体

DLL和程序集：打包和部署时的一个单

• 要为程序集和DLL选择提示性的名字，比如System.Data，这样很容易就知道它的大致功能。
• DLL命名：<Company>.<Component>.dll

名字空间的命名

<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]

• 要用公司名称作为名字空间的前缀，不要用缩写
• 要用稳定的与版本无关的产品名称作为名字空间的第二层
• 不要根据公司的组织架构来决定名字空间的层次结构，因为公司内部组织的名称一般来说不会持续太长的时间
• 要使用PascalCasing大小写风格，并用点号来分隔名字空间的各部分。
  如Microsoft.Office.PowerPoint
• 考虑适当的时候在名字空间中使用复数形式。  首字母缩写词例外
  System.Collections
  System.IO
• 不要用相同的名字来命名名字空间与位于该名字空间中的类型
  如：不要将名字空间命名为Debug，然后又在该名字空间中提供一个名为Debug的类。

名字空间和类型冲突

• 不要引入太一般化的类型名，比如Element、Node、Log以及Message。

不同类型的名字空间，有不同的规范来避免类型名的冲突：

• 应用程序模型名字空间（application model namespace）
  属于单个应用程序模型的名字空间经常一起使用，但是它们几乎不合属于其他应用程序模型的名字空间一起使用
  System.Windows*
  System.UI*
• 基础设施名字空间（infrastructure namespace）
  此类别包含一些在开发常用应用程序时很少会导入的名字空间
• 核心名字空间（core namespace）
  包含了所有的System名字空间，但应用程序模块名字空间和基础设施名字空间除外。  包括System、System.IO、System.Xml以及System.Net等等
• 技术名字空间组（technology namespace group）
  此类别包含所有那些以相同的两个前缀（<Company>.<Technology>*）开始的名字空间。

类、结构和接口的命名

一般来说类型名应该是名词词组。如果无法为类型找到一个名词词组，那么应该重新考虑类型的总体设计。

另一个中重要的考虑因素：最易于识别的名字应该用于最常用的类型。

最常用的类型名应该反映出使用场景，而不是继承层次。

• 要用名词词组来给类型命名。使用PascalCasing风格
• 不要给类名加前缀
  只有接口才能（可以）被加前缀“I”，那是因为.NET框架受到COM及Java的影响
• 考虑让派生类的名字以其基类结尾
  public class FileStream : Stream {...}
• 要确保一对类/接口的名字只差一个“I”前缀，如果该类是该接口的标准实现。
  public interface IComponent {...}
  public class Component : IComponent {...}

泛型类型参数的命名

• 要用描述性的名字来命名
• 考虑用T来命名参数类型
• 要给描述性的类型参数名加上T前缀
• 考虑在类型参数中显示出施加于该类型参数上的限制

枚举类型的命名

• 要用单数名词来命名枚举类型，除非它表示的是位域（bit field）
• 不要给枚举类型的名字添加“Enum”后缀，也不要添加“Flag”、“Flags”等后缀
• 不要给枚举类型值的名字添加前缀
  此规范与C++中通常所使用的恰好相反。在C++中给枚举的每个成员加上完成的限定符是很重要的，因为它们可能在枚举名的作用域之外被访问。但是在托管代码中，枚举成员只能通过枚举名的作用域来访问。

类型成员的命名

类型：方法、属性、事件、构造函数、字段

方法的命名

要尽量根据方法所对应的任务来给它们命名，而不要根据一些实现细节。

• 要用动词或动词词组来命名方法

属性的命名

• 要用名词、名词词组或形容词来命名属性
• 不要让属性名看起来与“Get”方法的名字相似
• 要用肯定性的短语（CanSeek而不是CantSeek）来命名布尔属性
• 考虑用属性的类型名来命名属性
  public enum Color {...}
  public class Control
  {
      public Color Color
      {
          get {...}
          set {...}
      }
  }

事件的命名

• 要用动词或动词短语来命名事件
  事件总是表示一些动作，要么正在发生，要么已经发生
• 要用现在时和过去时来赋予事件名之前和之后的概念
  窗口关闭之前发生的close事件：Closing
  窗口关闭之后发生的close时间：Closed
• 不要用Before和After前缀或后缀来区分前置和后置事件
• 要在命名事件处理函数（用作事件类型的委托）时加上“EventHandler”后缀
• 要在事件处理函数中用sender和e作为两个参数的名字
  sender：触发事件的对象，在整个.NET框架中，sender为object类型
• 要在命名事件的参数类型时加上“EventArgs”后缀

字段的命名

• PascalCasing风格
• 名词或名词短语
• 不要给字段名添加前缀

参数的命名

• camelCasing风格
• 要使用描述性的参数名
  参数名要具备足够的描述性，使得在大多数情况下，用户根据参数的名字和类型就能够确定它的意思
• 考虑根据参数的意思而不是参数的类型来命名参数

资源的命名

本地化的资源就好比是属性，可以通过特定的对象来引用。因此，它的命名规范与属性的相似。

• 要在命名属性关键字（resource key）时使用PascalCasing大小写风格
• 要使标识符的名字具有描述性而不是使名字变短
• 不要使用各主要CLR编程语言特有的关键字
• 要在命名资源时使用字母、数字和下划线
• 要用点号来给标识符清楚地划分层次
• 要在为异常消息资源命名是遵循下面的命名约定：
  资源标识符应该是异常的类型名加一个简短的异常标识符，之间以点号分隔

• 调用基类上已被其他方法重写的方法

  1 public override void GetInfo()
  2 {
  3 base.GetInfo(); // 调用基类上的GetInfo方法
  4 }

• 指定创建派生类实例时应用的基类构造函数

  1 public MyDerived() : base() // 调用基类的构造函数
  2 {}

1 class MyType
2 {
3 public static explicit operator MyType(int i)
4     {
5 // 从int转换到MyType类型的代码
6     }
7 }

显式转换运算符必须通过类型转换调用

1 int i;
2 MyType x = (MyType)i; // int到MyType类型的转换需要进行类型转换

    如果转换操作可能导致异常或信息丢失，则应用explicit关键字标记它。
    implicit：用于声明用户定义的隐式转换运算符 

1 class MyType
2 {
3 public static implicit operator int(MyType m)
4     {
5 // 从MyType转换到int类型的代码
6     }
7 }

1 MyType x;
2 int i = x;  // 隐式地调用MyType的MyType到int类型的转换运算符

隐式转换可以通过消除不必要的类型转换来提高源代码的可读性。
    一般情况下，调用某一个隐式转换时，应当绝不会引发异常，并且不会造成信息丢失。否则，应将其标记为explicit。
方法参数关键字
    如果声明方法的参数时没有指明ref或out，该参数将具有与该方法相关的值。这个值在方法中能被更改，但是当程序返回到调用过程时，这种改动不会被保留。

    params：用于指定在参数数目可变时带有参数的方法参数
    在方法声明中的params关键字之后不允许引入任何其他参数，但在其前面可以有其他参数。而且在方法声明中只允许使用一个params关键字。

 1 public static void UseParams(params int[] list)
 2 {
 3 for(int i = 0; i < list.Length; i++)
 4     {
 5         Console.WriteLine(list[i]);
 6     }
 7 }
 8
 9 public static void Main()
10 {
11     UseParams（1,2,3）;
12 int[] myArray = new int[3] { 10,11,12 };
13     UseParams(myArray);
14 }

    ref、out  使方法可以引用传递到该方法的那一个变量，当程序转至调用方法时，在方法中对参数所做的任何改动都将传给该变量。
    ref参数的值将被传递到ref参数，故必须首先初始化；而out参数不然，它的值不会被传递到该out参数，故不必首先初始化，但它必须在方法返回以前为out参数赋值。
    属性不是变量，不能作为ref/out参数。

一个成功的通用框架必须是为广大具有不同的需求、技能和背景的开发人员而设计的。框架设计师面临的最大挑战是为这些多样化的用户群提供即简单又功能强大的框架。

• 要设计即功能强大又易于使用的框架。
  80/20原则。 要把精力集中在框架中使用最为频繁的部分（20%）
• 要明确地为具有不同编程风格、需求、技能以及使用不同编程语言的开发人员设计框架。
• 要了解哪些使用多语言框架的广大开发人员。
  我们往往会只为自己设计API，而没有清楚地考虑用户的真正需求。

渐进框架

针对不同的使用场景，为不同的开发团体提供不同的产品，这种多框架的方法在某种程度上说是成功的，比如MS有Visual Basic程序库，有Win32程序库，也有MFC和ATL，但它也存在严重的缺点：多框架使得使用某个框架的开发人员难以将他们的知识转移到下一个技能等级或使用场景（这通常需要另一个框架）。

• .NET框架所做的是把VB、MFC、ATL、ASP等这些模型统一起来。无论开发人员使用何种编程语言或者选择何种编程模型，可供使用的API始终都是一致的。
  一个更好的方法是提供渐进框架（Progresive framework）。  从无到有，慢慢积累知识，并应用到以后更高级的使用场景中去。
• .NET框架就是一个渐进框架。
  渐进框架的目标是覆盖广大的开发人员，但并不是所有可能的开发人员。
  这也应了没有十全十美这句话：不可能满足每一个开发人员的需求。

框架设计的基本原则：

对用户而言，真正的开发效率来自能够轻易地创造非凡的产品，而并非来自能够轻易地创造垃圾。

1. 场景驱动设计原则
2. 低门栏原则
3. 自说明对象原则
4. 分层架构原则

• 考虑对框架进行分层，使高层API能提供最佳的开发效率，低层API能提供最强大的功能和最丰富的表现力。
  通俗地讲，象我这样的菜鸟只能用高层API，太低层都不懂，而牛人们都是想用也更愿意用低层API的强大功能的（个人意见）。ps：这边的高层跟低层不是指高深的意思。而是从易用性方面考虑的！
• 避免把低层API和高层API混在同一名字空间中，如果低层API非常复杂的话（即包含了许多类型）。
• 要确保单个特性域中不同的层能很好的集成在一起。

昨天是星期日：基督徒做礼拜的日子！

自从呆子去年去了英国，也有一年多没见到她了。昨天我们越好见面的，还有冲哥和晓丹！昨天也是她要做礼拜的日子：她在英国受洗了！我以前也从来没有见识过基督教做礼拜的场景，所以跟呆子说，也想看看。我到富阳的时候他们的仪式已经开始了，我到的时候，上面是长老在做报告类似的，因为讲得是富阳话，我不大听得懂；不过这个很快也就结束了（大概是在我来之前已经讲了很久了:-P）。然后，他们就开始唱圣歌，唱了很多，我个人感觉那个旋律还不错，也很容易上口，也跟着唱了几首。圣歌中都是些赞颂耶稣，赞颂主的，也有一些是说希望主不要摒弃他们的，还有就是希望主收留他们。呆子，一直都在非常虔诚的唱，而且每次低头祷告的时候都非常虔诚（我作为外人，自然体会不到其中的滋味）。唱完圣歌，过后是讲了一段圣经上的内容，我们四个人，除了呆子，其他的都没有认真的在听，所以也不知道具体地讲了些什么。不过我听到一个故事印象非常深刻：有一对夫妻，妻子是基督徒。故事就讲到那个丈夫，如果打他妻子，她绝对不会还手，而且还是笑脸相迎！ 这个也许就是常说的那个故事：如果有人打你左脸，你要把右脸让他打！这个礼拜好像还有圣餐，不过呆子说我们没有受洗过，不能接受的！

后来，也跟呆子聊了很多。也大致了解了基督教的一些东西。她也说她自己变了很多，在英国最重要的事就是找到了自己的主。在我看来她在英国最重要的的确是找到了自己的主，找到了自己一生的寄托。

我从来不会觉得因为有宗教信仰，呆子就是另类了。在我看来呆子还是呆子，唯独变的只是她找到了一个可以倾诉的对象！

在学校里，一直都知道，做事情（开发）要有规范，应该先怎样，然后怎样，最后做什么，这些都是知道的，而且还是学的重点。可是，真真到了岗位上，真真要自己动手的时候，什么都抛掉了！

只图方便，只图快捷，根本就不管什么可读性，什么可维护性，连注释都没有，更不用说什么文档的。昨晚也想到要好好的写写文档，可是今天到了公司，又不愿意写了。其实，也是另有内情：我实在是不知道，到底该如何下手。

所以，我也请晓鸣能够把他以前写的文档，借我看看，让我好有个参考，看看到底大致该怎么写，应该写些什么内容。

当然，这次，我也暂且先不写，一方面，考虑到，目前为在做的只是一个试用版，日后一定会再做过的；另一方面，钱好像急着想用它，就先完成它再说吧（也许完成后，再来写文档也好，我知道，这个不可取，可总比没有好）。

刚刚，我也想到，等这个完成，给钱之后，让他先去跑跑看；然后，我再抛掉所有的东西，重头做过。到时候要好好的做！

可是，我把这个想法跟晓鸣说了之后，问他我有没有可能重新做过，他却说不大可能。郁闷......看不起我！呵呵......也以此为鉴吧！希望我日后，不要如晓鸣所言，而且，这个算是我的第一个项目，一定要好好做才行。

写此文以记之，望日后自省，望同仁提点！

PS：我也深刻认识到，没有写文档所带来的麻烦：尽管大致的结构、功能，心理都清楚，可是很多小地方，细节的东西，都是到了临时才会想起来，这样的开发，不仅没有质量保证，而且效率也不高！很多时候，还要仔细地想清楚，到底有没有什么细节没有考虑进去。

我知道这是因为我以前都没有做过项目，我也提过了，原来课程上的那些项目只要写些文档就搞定了，而且还是很多人一起写文档，所以并不能真真的理解这个文档的作用，当然也不知道如何下手喽！我也知道文档的重要性，至少学校里的老师和书都是这么说的......呵呵！

下午，草草地写完了概要设计（其实很多条目还空着），然后完成了数据库表的设计，还有点时间多，我就继续了下前几天写的访问数据库的操作。

因为我是一个超级菜鸟，而且是那种没有飞过的菜鸟，所以所有的东西都是从头开始的。关于那个数据库操作，也是前几天我请晓鸣教我的，那天晚上是顺利的去出了menu表中的数据。今天，我想自己依着那天的思路，写一个函数：getDishByName。居然出了个错，于是我马上就僵死在那边了，郁闷啊！只能回头再请教晓鸣了!一遍又在感慨自己的没用......

不过，我还是感觉自己收获颇丰的，特别是那天晓鸣教我具体的数据库操作的时候。因为，我也知道，其实这些都不难，平常在看代码的时候也基本上能懂，但自己却不知道怎么下手写自己的数据库操作函数.......呵呵。可是，那天晓鸣教了下后，感觉豁然开朗......不过今天马上受挫！无奈......

看来，还得不断的努力啊！  呵呵，没有急功近利的意思，只是鞭策一下自己！

各位，多给我提提意见啊，希望知无不言，言无不尽！  谢谢......

作为第一次使用Popfly，我选择了创建我的第一个Mashup，是根据它的向导来做的，做得不好，还请大家多多包涵。不过，我把它看作是一个起点......

4. TextBox控件

文本框的主要用途是让用户输入文本，用户可以输入任何字符，也可以限制用户只输入数值。

.NET Framework内置了两个基本控件来提取用户输入的文本：TextBox和RichTextBox。这两个控件都派生于TextBoxBase，而TextBoxBase又派生于Control。

TextBoxBase提供了在文本框中处理文本的基本能力，例如选择文本、剪切和从剪切板上粘帖，以及许多事情。

4.1 TextBox控件的属性

常用属性：

• CausesValidation：当控件的这个属性为true，且该控件获得了焦点时，会引发两个事件：Validating和Validated。可以处理这些事件，以便验证失去焦点的控件中数据的有效性。
• CharacterCasing：这个值表示TextBox是否会改变输入的文本的大小写。可能的值有：

1. Lower：文本框中输入的所有文本都转换为小写；
2. Normal：不变；
3. Upper：都转换为大写。

• MaxLength：这个值指定输入到TextBox中的文本的最大字符长度。如果设为0，表示最大字符长度仅受限于可用的内存。
• Multiline：表示该控件是否是一个多行控件。多行控件可以显示多行文本。
• PasswordChar：指定是否用密码字符替换在单行文本框中输入的字符。如果Multiline属性为true，这个属性就不起作用。
• ReadOnly：这个Boolean值表示文本是否为只读。
• ScrollBars：指定多行文本框是否显示滚动条。
• SelectedText：在文本框中选择的文本。
• SelectionLength：在文本中选择的字符数。如果这个值设置得比文本中的字符数大，则控件会把它重新设置为字符总数减去SelectionStart的值。
• SelectionStart：文本框中被选中文本的开头。
• WordWrap：指定在多行文本框中，如果一行的宽度超出了控件的宽度，其文本是否应自动换行。

4.2 TextBox控件的事件

TextBox提供了以下所示的事件：

• Enter、Leave、Validating、Validated：这4个事件按照列出的顺序引发。它们统称为焦点事件，当控件的焦点发生改变时引发，但有两个例外：Validating和Validated仅在控件接收了焦点，且其CausesValidation属性设置为true时引发。接收焦点的控件引发事件的原因是有时即使焦点改变了，我们也不希望验证控件的有效性。
• KeyDown、KeyPress、KeyUp：这三个事件称为“键事件”。它们可以监视和改变输入到控件中的内容。KeyDown和KeyUp接收与所按下键对应的键码，这样就可以确定是否按下了特殊的键Shift或Control和F1。另一方面，KeyPress接收与键对应的字符。这表示字母a的值与A的值不同。
• Change：只要文本框的文本发生了改变，就会引发该事件。

对于这个，郭老师，好像也很支持的样子，感觉他也是有兴趣做这一块的事情的。我也认识到，我现在确实也没什么事情在做（或者说是能做），所以，我也主动提出由我来做做看（当时，好像是指界面）。

今天，在提起来的时候，我也感觉我非常想做这个系统，毕竟可以是我的一个切入口，学习和工作的切入口。我要好好的努力，抓住这个机会。况且，郭老师，也提过我可以做做这个系统，毕竟可以（要）慢慢地锻炼起来。

另一方面，我也认识到，其实这个系统不难，而且郭老师和晓鸣最近也很忙，所以我也是应该是主要的参与人员，或者说，基本上要由我来完成，我也想挑战一下。当然，期间会得到很多来自郭老师、晓鸣还有钱的帮助。

今天算是计划启动吧，初步确定启动。

定一下明天的任务：确定界面的选择（不过按照钱的意思，好像是三种方案都要做出来 ......然后，还有就是写一下需求文档，再有就是稍微确定下详细设计）。

Come on！