关于C# C#是达成微软公共语言运行库（CLR）的少数语言中的一种。达成CLR的语言可以受益于其带来的特性，如跨语言集成、异常处理、安全性增强、部件组合的简易模型以及调试和分析服务。作为现代的CLR语言，C#是应用最为广泛的，其应用场景针对Windows桌面、移动手机以及服务器环境等复杂、专业的开发项目。 C#是种面向对象的强类型语言。C#在编译和运行时都有的强类型检查，使在大多数典型的编程错误能够被尽早地发现，而且位置定位相当精准。相比于那些不拘泥类型，在违规操作很久后才报出可追踪到莫名其妙错误的语言，这可以为程序员节省很多时间。然而，许多程序员有意或无意地抛弃了这个检测的有点，这导致本文中讨论的一些问题。 关于本文 本文描述了10个 C# 程序员常犯的错误，或应该避免的陷阱。 尽管本文讨论的大多数错误是针对 C# 的，有些错误与其他以 CLR 为目标的语言，或者用到了 Framework Class Library (FCL) 的语言也相关。 常见错误 #1: 把引用当做值来用，或者反过来 C++ 和其他很多语言的程序员，习惯了给变量赋值的时候，要么赋单纯的值，要么是现有对象的引用。然而，在C# 中，是值还是引用，是由写这个对象的程序员决定的，而不是实例化对象并赋值的程序员决定的。这往往会坑到 C# 的新手程序员。 如果你不知道你正在使用的对象是否是值类型或引用类型，你可能会遇到一些惊喜。例如：
|
1 2 3 4 5 6 7 8 9 10 11 |
Point point1 = new Point(20, 30); Point point2 = point1; point2.X = 50; Console.WriteLine(point1.X); // 20 (does this surprise you?) Console.WriteLine(point2.X); // 50 Pen pen1 = new Pen(Color.Black); Pen pen2 = pen1; pen2.Color = Color.Blue; Console.WriteLine(pen1.Color); // Blue (or does this surprise you?) Console.WriteLine(pen2.Color); // Blue |
如你所见,尽管Point和Pen对象的创建方式相同,但是当一个新的X的坐标值被分配到point2时, point1的值保持不变 。而当一个新的color值被分配到pen2,pen1也随之改变。因此,我们可以推断point1和point2每个都包含自己的Point对象的副本,而pen1和pen2引用了同一个Pen对象 。如果没有这个测试,我们怎么能够知道这个原理? 一种办法是去看一下对象是如何定义的（在Visual Studio中，你可以把光标放在对象的名字上，并按下F12键）
|
1 2 |
public struct Point { … } // defines a “value” type public class Pen { … } // defines a “reference” type |
如上所示，在C#中，struct关键字是用来定义一个值类型，而class关键字是用来定义引用类型的。 对于那些有C++编程背景人来说，如果被C++和C#之间某些类似的关键字搞混，可能会对以上这种行为感到很吃惊。 如果你想要依赖的行为会因值类型和引用类型而异，举例来说，如果你想把一个对象作为参数传给一个方法，并在这个方法中修改这个对象的状态。你一定要确保你在处理正确的类型对象。 常见的错误#2：误会未初始化变量的默认值 在C#中，值得类型不能为空。根据定义，值的类型值，甚至初始化变量的值类型必须有一个值。这就是所谓的该类型的默认值。这通常会导致以下，意想不到的结果时，检查一个变量是否未初始化：
|
1 2 3 4 5 6 |
class Program { static Point point1; static Pen pen1; static void Main(string[] args) { Console.WriteLine(pen1 == null); // True Console.WriteLine(point1 == null); // False (huh?) } } |
为什么不是【point 1】空？答案是，点是一个值类型，和默认值点（0,0）一样，没有空值。未能认识到这是一个非常简单和常见的错误，在C#中 很多（但是不是全部）值类型有一个【IsEmpty】属性，你可以看看它等于默认值：
|
1 |
Console.WriteLine(point1.IsEmpty); // True |
当你检查一个变量是否已经初始化，确保你知道值未初始化是变量的类型，将会在默认情况下，不为空值。 常见错误 #3: 使用不恰当或未指定的方法比较字符串 在C#中有很多方法来比较字符串。 虽然有不少程序员使用==操作符来比较字符串，但是这种方法实际上是最不推荐使用的。主要原因是由于这种方法没有在代码中显示的指定使用哪种类型去比较字符串。 相反，在C#中判断字符串是否相等最好使用Equals方法：
|
1 |
public bool Equals(string value); public bool Equals(string value, StringComparison comparisonType); |
第一个Equals方法（没有comparisonType这参数）和使用==操作符的结果是一样的，但好处是，它显式的指明了比较类型。它会按顺序逐字节的去比较字符串。在很多情况下，这正是你所期望的比较类型，尤其是当比较一些通过编程设置的字符串，像文件名，环境变量，属性等。在这些情况下，只要按顺序逐字节的比较就可以了。使用不带comparisonType参数的Equals方法进行比较的唯一一点不好的地方在于那些读你程序代码的人可能不知道你的比较类型是什么。 使用带comparisonType的Equals方法去比较字符串，不仅会使你的代码更清晰，还会使你去考虑清楚要用哪种类型去比较字符串。这种方法非常值得你去使用，因为尽管在英语中，按顺序进行的比较和按语言区域进行的比较之间并没有太多的区别，但是在其他的一些语种可能会有很大的不同。如果你忽略了这种可能性，无疑是为你自己在未来的道路上挖了很多“坑”。举例来说：
|
1 2 3 4 5 6 7 8 9 10 11 12 |
string s = "strasse"; // outputs False: Console.WriteLine(s == "straße"); Console.WriteLine(s.Equals("straße")); Console.WriteLine(s.Equals("straße", StringComparison.Ordinal)); Console.WriteLine(s.Equals("Straße", StringComparison.CurrentCulture)); Console.WriteLine(s.Equals("straße", StringComparison.OrdinalIgnoreCase)); // outputs True: Console.WriteLine(s.Equals("straße", StringComparison.CurrentCulture)); Console.WriteLine(s.Equals("Straße", StringComparison.CurrentCultureIgnoreCase)); |
最安全的实践是总是为Equals方法提供一个comparisonType的参数。 下面是一些基本的指导原则： 当比较用户输入的字符串或者将字符串比较结果展示给用户时，使用本地化的比较(CurrentCulture 或者CurrentCultureIgnoreCase)。 当用于程序设计的比较字符串时，使用原始的比较(Ordinal 或者 OrdinalIgnoreCase) InvariantCulture和InvariantCultureIgnoreCase一般并不使用，除非在受限的情境之下，因为原始的比较通常效率更高。如果与本地文化相关的比较是必不可少的，它应该被执行成基于当前的文化或者另一种特殊文化的比较。 此外，对Equals 方法来说，字符串也通常提供了Compare方法，可以提供字符串的相对顺序信息而不仅仅中测试是否相等。这个方法可以很好适用于<, <=, >和>= 运算符，对上述讨论同样适用。 常见误区 #4: 使用迭代式 (而不是声明式)的语句去操作集合 在C# 3.0中，LINQ的引入改变了我们以往对集合对象的查询和修改操作。从这以后，你应该用LINQ去操作集合，而不是通过迭代的方式。 一些C#的程序员甚至都不知道LINQ的存在，好在不知道的人正在逐步减少。但是还有些人误以为LINQ只用在数据库查询中，因为LINQ的关键字和SQL语句实在是太像了。 虽然数据库的查询操作是LINQ的一个非常典型的应用，但是它同样可以应用于各种可枚举的集合对象。（如：任何实现了IEnumerable接口的对象）。举例来说，如果你有一个Account类型的数组，不要写成下面这样：
|
1 2 3 4 |
decimal total = 0; foreach (Account account in myAccounts) { if (account.Status == "active") { total += account.Balance; } } |
你只要这样写：
|
1 2 3 |
decimal total = (from account in myAccounts where account.Status == "active" select account.Balance).Sum(); |
虽然这是一个很简单的例子，在有些情况下，一个单一的LINQ语句可以轻易地替换掉你代码中一个迭代循环（或嵌套循环）里的几十条语句。更少的代码通常意味着产生Bug的机会也会更少地被引入。然而，记住，在性能方面可能要权衡一下。在性能很关键的场景，尤其是你的迭代代码能够对你的集合进行假设时，LINQ做不到，所以一定要在这两种方法之间比较一下性能。 #5常见错误：在LINQ语句之中没有考虑底层对象 对于处理抽象操纵集合任务，LINQ无疑是庞大的。无论他们是在内存的对象，数据库表，或者XML文档。在如此一个完美世界之中，你不需要知道底层对象。然而在这儿的错误是假设我们生活在一个完美世界之中。事实上，相同的LINQ语句能返回不同的结果，当在精确的相同数据上执行时，如果该数据碰巧在一个不同的格式之中。 例如，请考虑下面的语句： 1 decimal total=(from accout in myaccouts 2 where accout.status==‘active" 3 select accout .Balance).sum(); 想象一下，该对象之一的账号会发生什么。状态等于“有效的”（注意大写A)? 好吧，如果myaccout是Dbset的对象。（默认设置了不同区分大小写的配置），where表达式仍会匹配该元素。然而，如果myaccout是在内存阵列之中，那么它将不匹配，因此将产生不同的总的结果。 等一会，在我们之前讨论过的字符串比较中, 我们看见 == 操作符扮演的角色就是简单的比较. 所以，为什么在这个条件下， == 表现出的是另外的一个形式呢 ? 答案是，当在LINQ语句中的基础对象都引用到SQL表中的数据（如与在这个例子中，在实体框架为DbSet的对象的情况下），该语句被转换成一个T-SQL语句。然后遵循的T-SQL的规则，而不是C＃的规则，所以在上述情况下的比较结束是不区分大小写的。 […]
View Details商业内幕最近发表了一篇文章说做程序员压力山大，很多人都快疯了。 文中陈述了几个典型的罪状：骗子综合症，加班加点，精疲力竭等。作者指出，程序员的工作压力的根源通常是源自混乱的管理，但越来越多的压力开始来自程序员 社群自身，社群中开始形成一种文化，将加班加点当成判断一个程序员是否具有奉献精神的石蕊试剂，强加到程序员身上。换句话说，如果你不在下班时间继续写代 码，你就不可能成为一名合格的程序员。跟这些压力相呼应的是急速革新的各种新技术、新框架、新语言、新平台、新程序包、新SDK等的不断出现，就如火上浇 油。 可事实上问题不在于此。编程，就跟写作、绘画、作曲一样，首先是一种创造性的活动，而不是一个种技术工作。当然，对一种技术或编程语言的不断练习和保持熟悉很重要，这其实就是在学习使用工具和技法，但它并不会让你本质上变成一名更优秀的程序员。它只是让你能更熟练的使用工具。而能让你成为更优秀的程序员的是学会如何思考问题，因为最终你是把脑子里思考出的逻辑转换成了一系列操作计算机的指令，让计算机遵照指令解决问题。而学习如何正确的思考——如何抽象归纳，如何组合，如何分析信息，如何自我反省——可以通过各种方式，远非只有编程一种。Paul Graham在他的精彩著作《黑客与画家》一书中说： 我发现那些最有价值的灵感的源泉都不是那些跟“计算机”这个词相关的领域，而是那些跟动手创造相关的领域。绘画就是一个比计算机理论能提供更丰富灵感的思想源泉。 拓展其它领域的技术，培养除编程之外的其它爱好，这会给你的日常工作带来巨大的帮助。程序员根本不需要没日没夜的写代码。你应该把这些时间用于和他 人交流，和大家一起边喝咖啡(或你喜爱的东西)边编码、阅读、讨论。你应该把这些时间用于跑步或举重。身体锻炼给大脑补充氧气，滋养这个最神奇的器官，这 才是你需要的。我三年前开始跑步。呼吸新鲜的空气、沐浴清新的阳光让我变得更加快乐，跑出几公里远离繁杂的琐事，我的脑子有了更多的时间来激发灵感。 关键是，关注心灵，关注自己，这能让你成为一个更好的程序员。你可以无止境的学习新语法，新工具，或新什么东西，但是，如果所有你做的只是编程，你 实际上在跟自己背道而驰。有时候你需要全力以赴，但那是当程序中有问题需要救火时，是特殊情况，而不是日常。如果你的驻地总是有火灾，那你应该换个地方。 有时候你需要埋头苦干，干上几周甚至几个月，为了让你的理想变成现实。然后是休息。相反，一味的玩命苦干只能换来越来越少的回报，是完全与成为一名更好的 程序员的愿望背道而驰。去年11月，我参加了NaNoWriMo (National Novel Writers Month)，这是一个非正式的比赛，参赛者要求在30天里写出一本5万字左右的书。我每天早起，花几个小时写作，然后上8个多小时的班，然而晚上继续写 作。每天如此。坚持了30天。月末的时候我的身体开始透支，我病了。但这对我是有必要的，我一直有个愿望要写一本小说。之后我几个月没有写任何东西。我需 要休息，要恢复平常态，要以此进步。软件开发与此无二。 商业内幕的这篇文章同时还饶有兴趣的发现“女性程序员经常坦白说在遭受骗子综合征的折磨…但越来越多的男性程序员也开始表示深有同感。”20世纪和21世纪工作中的性别问题峰回路转，最 终男性也遇到类似的问题。女性第一次看到了竞争的问题侵扰男性，尤其是在那些传统的以男性为中心的行业。我相信这是生存竞争必然导致的现象，但不应出现在 一个富足而且灵活的社会中。男人们看到女性对工作上非人性的现状的反应，也加入了她们的行列一起表达对现状的不满情绪。随着更多的女性进入到编程行业，她 们给这些男性程序员带来了一种新的旁观者的视角。女性需要去理解她们发现的这些不幸的行业现状是男性程序员以前必须每天面对的、接受的。但事实上程序员们 完全不必如此，这是一种具有强大力量的认识。 不要再让自己精疲力竭，这样不会让你成为更好的程序员。做你爱做的事，爱上更多的兴趣。你将会变的更优秀。 from:http://www.oschina.net/news/51699/sane-programmer [英文原文：How to be a sane programmer ]
View Details随着 Web 开发者和设计者收藏 JavaScript 库的数量越来越多，JavaScript 也有大量流行的库：jQuery，MooTools 等等，很多时候大家都会使用 JavaScript 模板引擎来开发 JavaScript 应用。以下列表介绍的就是 JavaScript 模板引擎。 这里我们收集了一些非常有用的 JavaScript 模板引擎，希望能给 Web 开发者和设计者提供一定的帮助，在评论与大家交流一下 JavaScript 模板引擎的相关心得吧：） 1) Jade jade 是超高性能的 node JavaScript 模板引擎，有着非常强大的 API 和大量杰出的特性。它主要针对 node 的服务端。 2) Mustache Mustache 是 logic-less 模板语法，可以使用在 HTML，配置文件，源代码等等地方。它是使用哈希表或者对象提供的值来扩展模板标签。 3) Transparency Transparency 是一个强大的客户端网站模板引擎，可直接绑定数据到 DOM，包括一些很棒的特性如 HTML 模板、JS 视图逻辑。支持 IE9+, Chrome, Firefox, iOS, Android, Etc. 4) Underscorejs Underscore 是 JavaScript 库，提供大量有用的函数式程序设计助手，不需要扩展任意的内置对象。 5) Embeddedjs EJS 会使用客户端模板从 JavaScript 中清理 HTML 代码，整理好这些代码之后，JavaScript 代码就会变得更加整洁和有条理。 6) DoTjs doT.js 是最快和简洁的 JavaScript 模板函数搜索，这些函数致力于 V8 和 Node.js 下高性能的表现。doT.js 在浏览器和 Node.js 下都表现出超高的性能。 7) Handlebarsjs Handlebars 给构建语义模板提供强大的基础支持。 8) T.js T.js 是使用简单 JavaScript 数据结构来展示 html/xml 数据的模板引擎。 9) Dustjs Dust 是浏览器和 Node.js […]
View Details