Codepad.org是一个很有意思的网站，它的主页很简单，左边是可以编译并执行的程序语言，右边则是让你输入程序的输入框，输入框的下面是一个“Run Code”的复选钮和一个“Submit”的提交按钮。
其操作起来也非常简单，先选中你要编译并运行的程序语言，然后在输入框中粘贴或输入程序的原代码，然后，点击提交，你就可以看么你程序编译出错的提示，或是执行的结果。
也许，你会觉得很无聊天，但我觉得这在某些时候会非常有用，尤其是你找不到编译器而又想验证一段代码的时候，这种时候还是比较多的。特别是我们很难有一台可以运行所有语言的电脑，如果有的话，那一定是你自己的个人电脑，当你不使用你自己的电脑时，你就会着急了。而且，我觉得这项服务非常地有意思，因为，这样一来，你甚至可以在你的手机上写任何语言的程序了。
(8 人打了分，平均分： 3.88 )
Loading...
Code Review中文应该译作“代码审查”或是“代码评审”，这是一个流程，当开发人员写好代码后，需要让别人来review一下他的代码，这是一种有效发现BUG的方法。由此，我们可以审查代码的风格、逻辑、思路……，找出问题，以及改进代码。因为这是代码刚刚出炉的时候，所以，这也是代码重构，代码调整，代码修改的最佳时候。所以，Code Review是编码实现中最最重要的一个环节。
长时间以来，Code Review需要有一些有效的工具来支持，这样我们就可以更容易，更有效率地来进行代码审查工作。下面是5个开源的代码审查工具，他们可以帮助你更容易地进行这项活动。
1. Review board:
Review board 是一个 基于web 的工具，是由 django 和python设计的。 Review board 可以帮助我们追踪待决代码的改动，并可以让Code-Review更为容易和简练。尽管Review board 最初被设计在VMware项目中使用，但现在其足够地通用。当前，其支持这些代码版本管理软件： SVN, CVS, Perforce, Git, Bazaar, 和Mercurial.
(7 人打了分，平均分： 3.29 )Loading...虽然这样的文章非常的多，并且，就算是对于编程新手来说，也是非常的简单和显而见，但是，在我们进行Code Review过程中，我们还是能够看到那些非常混乱的代码，所以，有些时候，你会在想，是不是这样的规则太多了，导致我们的程序员记不住。虽然我们在以前的文章中一遍又一遍的说过（比如：《优质代码的十诫》），千言万语总结一下，无论你用什么样的语言，最最基本的编程原则就是下面这四条。
(7 人打了分，平均分： 3.14 )Loading...前几天Neo写过《编程中的命名设计那点事》，这里也有另外一篇和程序命名的文章，可以从另一个角度看看。
1.- 变量应该是尽可能的望文知意。千万不要使用教材中的命名方式。
在我们的日常工作中，有很大数量的开发人员喜欢使用短的变量名，而不是有含义的变量名。这主要是因为我们大学教科书的那些示例所造成的，人都是先入为主，所以，教科书中的那些很抽象，带着演示的变量命名影响了我们一代又一代的程序员，并影响了他们很多年。虽然那些短的，教材式的变量名，可能会让你少打一些字，但其实，这是非常非常不好的。因为软件的维护成本远远大于了软件的开发成本，如果你不取一个好的一点的变量名，那么当进行代码评审时，当进行bug fixing时，当进行代码重构时，当进行代码维护时，你的某个变量名可能会让你一头雾水，不知道所措，还可以会让你走入陷阱，造成更大的时间成本。所以，一个可阅读的代码必然和那些不错的变量名分不开，而这也能让你的软件间接上有更好的质量。
(12 人打了分，平均分： 3.67 )Loading...
DRY 是一个最简单的法则，也是最容易被理解的。但它也可能是最难被应用的（因为要做到这样，我们需要在泛型设计上做相当的努力，这并不是一件容易的事）。它意味着，当我们在两个或多个地方的时候发现一些相似的代码的时候，我们需要把他们的共性抽象出来形一个唯一的新方法，并且改变现有的地方的代码让他们以一些合适的参数调用这个新的方法。
DRY 这一法则可能是编程届中最通用的法则了，目前为止，应该没有哪个程序员对这一法则存有异议。但是，我们却能发现，一些程序在编写单元测试（unit testing）时忘记了这一法则：让我们相像一下，当你改变一个类的若干接口，如果你没有使用DRY，那么，那些通过调用一系例类的接口的unit test的程序，都需要被手动的更改。比如：如果你的unit test的诸多test cases中没有使用一个标准共有的构造类的方法，而是每个test case自己去构造类的实例，那么，当类的构造函数被改变时，你需要修改多少个test cases啊。这就是不使用DRY法则所带来的恶果。
(20 人打了分，平均分： 4.30 )Loading...在我开始设计系统的时候，我会花去很多时间去设计命名，因为好的命名和好的设计是分不开的。
In the beginning was the Word, and the Word was with God, and the Word was God
太初有道。道与神同在，道就是神。 (约翰福音第一章，第一节)
在设计过程中给类，方法和函数好的命名会带来好的设计，虽然这不是一定成立，但是如果坏的命名那一定不会给你带来好的设计。在设计过程，如果你发现你很难命名某一个模块，某个方法时，可能你真正遇到的问题不是难命名的问题，而是这个设计是否真的合理，你或许应该花更多的时间来重新设计一下你的模块。
好的命名不仅会带来好的设计，好的命名还提高了程序的可读性，降低代码维护的成本。另一方面，如果糟糕的命名会给代码带来一堵无形的墙，让你必须深入代码去研究代码具有的行为，增加你理解代码的时间。
为此我总结了几条关于命名的指导原则，希望这几条原则能为你的命名设计带来帮助，我使用的是C++的语法，当然这些原则也很容易扩展到其他语言中去。
名字应该尽量采用名词
Bad: Happy
Good: Happiness
(28 人打了分，平均分： 4.11 )Loading...