不错呦！smile@林凯西，确保“准备文件”中的几个文件都有安装，S...您好，看了您这篇帖子觉得很有帮助。但是有个问题想请...我的修改过了怎么还被恶意注册呢 @jjjjiiii 用PJ快9年了，主要是A...PJ3啊，貌似很少有人用PJ了，现在不是WP就是z...@332347365，我当时接入时错误码没有-10...楼主，ChkValue值应为-103是什么意思呢？...大哥 你最近能看到我发的信息，请跟我联系，我有个制...
技术总监谈好的程序员如何写代码[转]
编辑:dnawo 日期:2010-01-05
要判断一个程序员是不是好的程序员，主要看他写的代码，因为程序员最重要的事是写代码。
即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。
再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。
即便不去理解代码的意图，只要看一眼，好的程序员写的代码与差的程序员写的代码基本上就可以看出来。好的程序员写的代码，整洁而规范，视觉上自然有一种美感。空白错落有致，注释恰到好处，命名和排版遵守统一的规范。差的程序员写的代码则经常出现过长的函数，前后不一致的命名方式和排版，过深的嵌套结构，非常复杂的表达式，随处可见的数字等毛病。
再去粗粗阅读，对好的程序员还是差的程序员就会更有把握。好的程序员写的代码，有一种精心雕琢而成的一致性。好的程序员一致会遵守统一的命名方式，如camelCase，而差的程序员的变量命名时不时的就会偏离统一规范。好的程序员的代码中拼写错误几乎不可见，而差的程序员的拼写错误要多得多。好的程序员对于同一类动作，不会忽而用这个动词，忽而又用那个同义词，如add/insert混用。好的程序员采用一致的简写规则，差的程序员则时而不简写，时而简写。好的程序员会很注意名称中形容词与名词谁在前谁在后，而差的程序员没有规则，时而在前时而在后。好的程序员很少会写出大段大段的重复代码，差的程序员却经常搞不定重复代码，他们难以将重复的代码抽取出一个统一的概念进行重用。好的程序员对于对外的API会注重注释与代码的一致性，差的程序员经常注释中的参数名称与函数定义都不一致。好的程序员很少会留下被注释掉的或用#if 0括起的垃圾代码，他们意志坚决，代码有用就要，没用就不要，差的程序员则不一样，他们经常不确信一段代码是否真的需要，他们缺乏保持代码整洁的习惯，因此他们让垃圾代码留着。
为什么说经常汇报工作很重要[转]
编辑:dnawo 日期:2010-01-05
奇妙的C#属性：属性 or 方法？
编辑:dnawo 日期:2010-01-05
time命令无法修改时间，提示：系统无法接受输入的时间
编辑:dnawo 日期:2010-01-05
在"控制面板→日期和时间"中修改系统时间失败后，尝试用time命令进行修改，却也失败，提示：系统无法接受输入的时间。后来知道是使用了"360时间保护器"的原因，必须先停止它对时间的保护，才能修改系统时间：
360时间保护器官方地址：http://www.360.cn/down/soft_down13.html
360时间保护器官方地址：http://www.360.cn/down/soft_down13.html
让C#类支持关联数组
编辑:dnawo 日期:2010-01-05
Effective C# 原则34：创建大容量的Web API
编辑:dnawo 日期:2010-01-04
Effective C# 原则33：限制类型的访问
编辑:dnawo 日期:2010-01-03
并不是所有的人都须要知道所有的事。也不是所有的类型须要是公共的。对于每个类型，在满足功能的情况下，应该尽可能的限制访问级别。而且这些访问级别往往比你想像的要少得多。在一个私有类型上，所有的用户都可以通过一个公共的接口来访问这个接口所定义的功能。
让我们回到最根本的情况上来：强大的工具和懒惰的开发人员。VS.net对于他们来说是一个伟大的高产工具。我用VS.net或者C# Builder轻松的开发我所有的项目，因为它让我更快的完成任务。其中一个加强的高产工具就是让你只用点两下按钮，一个类就创建了，当然如果这正是我想要的话。VS.net为我们创建的类就是这样的：
让我们回到最根本的情况上来：强大的工具和懒惰的开发人员。VS.net对于他们来说是一个伟大的高产工具。我用VS.net或者C# Builder轻松的开发我所有的项目，因为它让我更快的完成任务。其中一个加强的高产工具就是让你只用点两下按钮，一个类就创建了，当然如果这正是我想要的话。VS.net为我们创建的类就是这样的：
复制内容到剪贴板
程序代码
程序代码public class Class2
Effective C# 原则32：选择小而内聚的程序集
编辑:dnawo 日期:2010-01-02
这一原则实际应该取这个名字：“应该创建大小合理而且包含少量公共类型的程序集”。但这太沉长了，所以就以我认为最常见的错误来命名：开发人员总是把所有的东西，除了厨房里水沟以外(译注：夸张说法，kitchen sink可能是个口语词，没能查到是什么意思，所以就直译了。)，都放到一个程序集。这不利于重用其中的组件，也不利于系统中小部份的更新。很多以二进制组件形式存在的小程序集可以让这些都变得简单。
然而这个标题对于程序集的内聚来说也很醒目的。程序集的内聚性是指概念单元到单个组件的职责程度。聚合组件可以简单的用一句话概括，你可以从很多.Net的FCL程序集中看到这些。有两个简单的例子：System.Collections程序集就是负责为相关对象的有序集提供数据结构，而System.Windows.Forms程序集则提供Windows控件类的模型。Web form和Windows Form在不同的程序集中，因为它们不相关。你应该用同样的方式，用简单的一句话来描述你的程序集。不要玩花样：一个MyApplication程序集提供了你想要的一切内容。是的，这也是简单的一句，但这也太刁懒了吧，而且你很可能在My2ndApplication(我想你很可能会要重用到其中的一些内容。这里“其中的一些内容”应该放到一个独立的程序集中。)程序集并不须要使用所有的功能。
你不应该只用一个公共类来创建一个程序程序集。应该有一个折衷的方法，如果你太偏激，创建了太多的程序集，你就失去了使用封装的一些好处：首先就是你失去了使用内部类型的机会，内部类型是在一个程序集中与封装(打包)无关的公共类(参见原则33)(译注：简单的说，内部类型就是只能在一个公共的程序集中访问类，程序集以外限制访问)。JIT编译器可以在一个程序集内有很的内联效率，这比起在多程序集中穿梭效率要高得多。这就是说，在一个程序集中放置一些相关的类型对你是有好处的。我们的目标就是为我们的组件创建大小最合适的程序集。这一目标很容易实现，就是一个组件应该只有一个职责。
然而这个标题对于程序集的内聚来说也很醒目的。程序集的内聚性是指概念单元到单个组件的职责程度。聚合组件可以简单的用一句话概括，你可以从很多.Net的FCL程序集中看到这些。有两个简单的例子：System.Collections程序集就是负责为相关对象的有序集提供数据结构，而System.Windows.Forms程序集则提供Windows控件类的模型。Web form和Windows Form在不同的程序集中，因为它们不相关。你应该用同样的方式，用简单的一句话来描述你的程序集。不要玩花样：一个MyApplication程序集提供了你想要的一切内容。是的，这也是简单的一句，但这也太刁懒了吧，而且你很可能在My2ndApplication(我想你很可能会要重用到其中的一些内容。这里“其中的一些内容”应该放到一个独立的程序集中。)程序集并不须要使用所有的功能。
你不应该只用一个公共类来创建一个程序程序集。应该有一个折衷的方法，如果你太偏激，创建了太多的程序集，你就失去了使用封装的一些好处：首先就是你失去了使用内部类型的机会，内部类型是在一个程序集中与封装(打包)无关的公共类(参见原则33)(译注：简单的说，内部类型就是只能在一个公共的程序集中访问类，程序集以外限制访问)。JIT编译器可以在一个程序集内有很的内联效率，这比起在多程序集中穿梭效率要高得多。这就是说，在一个程序集中放置一些相关的类型对你是有好处的。我们的目标就是为我们的组件创建大小最合适的程序集。这一目标很容易实现，就是一个组件应该只有一个职责。
Effective C# 原则31：选择小而简单的函数
编辑:dnawo 日期:2010-01-02
做为一个有经验的程序员，不管你在使用C#以前是习惯用什么语言的，我们综合了几个可以让你开发出有效代码的实际方法。有些时候，我们在先前的环境中所做的努力在.Net环境中却成了相反的。特别是在你试图手动去优化一些代码时尤其突出。你的这些行为往往会阻止JIT编译器进行最有效的优化。你的以性能为由的额外工作，实际上产生了更慢的代码。你最好还是以你最清楚的方法写代码，其它的让JIT编译器来做。最常见的一个例子就是预先优化，你创建一个很长很复杂的函数，本想用它来避免太多的函数调用，结果会导致很多问题。实际操作时，提升这样一个函数的逻辑到循环体中对.Net程序是有害的。这与你的真实是相反的，让我们来看一些细节。
这一节介绍一个简单的内容，那就是JIT编译器是如何工作的 。.Net运行时调用JIT编译器，用来把由C#编译器生成的IL指令编译成机器代码。这一任务在应用程序的运行期间是分步进行的。JIT并不是在程序一开始就编译整个应用程序，取而代之的是，CLR是一个函数接一个函数的调用JIT编译器。这可以让启动开销最小化到合理的级别，然而不合理的是应用程序保留了大量的代码要在后期进行编译。那些从来不被调用的函数JIT是不会编译它的。你可以通过让JIT把代码分解成更多的小块，从而来最小化大量无关的代码，也就是说小而多的函数比大而少的函数要好。考虑这个人为的例子：
这一节介绍一个简单的内容，那就是JIT编译器是如何工作的 。.Net运行时调用JIT编译器，用来把由C#编译器生成的IL指令编译成机器代码。这一任务在应用程序的运行期间是分步进行的。JIT并不是在程序一开始就编译整个应用程序，取而代之的是，CLR是一个函数接一个函数的调用JIT编译器。这可以让启动开销最小化到合理的级别，然而不合理的是应用程序保留了大量的代码要在后期进行编译。那些从来不被调用的函数JIT是不会编译它的。你可以通过让JIT把代码分解成更多的小块，从而来最小化大量无关的代码，也就是说小而多的函数比大而少的函数要好。考虑这个人为的例子：
复制内容到剪贴板 程序代码
程序代码public string BuildMsg( bool takeFirstPath )
Effective C# 原则30：选择与CLS兼容的程序集
编辑:dnawo 日期:2010-01-02
.Net运行环境是语言无关的：开发者可以用不同的.Net语言编写组件。而且在实际开发中往往就是这样的。你创建的程序集必须是与公共语言系统(CLS)是兼容的，这样才能保证其它的开发人员可以用其它的语言来使用你的组件。
CLS的兼容至少在公共命名上要与互用性靠近。CLS规范是一个所有语言都必须支持的最小操作子集。创建一个CLS兼容的程序集，就是说你创建的程序集的公共接口必须受CLS规范的限制。这样其它任何满足CLS规范的语言都可以使用这个组件。然而，这并不是说你的整个程序都要与CLS的C#语言子集相兼容。
为了创建CLS兼容的程序集，你必须遵从两个规则：首先，所以参数以及从公共的和受保护的成员上反回的值都必须是与CLS兼容的。其次，其它不与CLS兼容的公共或者受保护成员必须存在CLS兼容的同意对象。
CLS的兼容至少在公共命名上要与互用性靠近。CLS规范是一个所有语言都必须支持的最小操作子集。创建一个CLS兼容的程序集，就是说你创建的程序集的公共接口必须受CLS规范的限制。这样其它任何满足CLS规范的语言都可以使用这个组件。然而，这并不是说你的整个程序都要与CLS的C#语言子集相兼容。
为了创建CLS兼容的程序集，你必须遵从两个规则：首先，所以参数以及从公共的和受保护的成员上反回的值都必须是与CLS兼容的。其次，其它不与CLS兼容的公共或者受保护成员必须存在CLS兼容的同意对象。
