团队对个人的期望 （1）交流：能有效的和其他队员交流，从大的技术方向，到看似微小的问题。 （2）说到做到：“按时交付” （3）接受团队赋予的角色并按角色要求工作:团队要完成任务，有很多事请要做，是否能接受不同的任务并高质量完成。 （4）全力投入团队的活动：就像一些评审会议，代码复审，都要全力以赴地参 ...
分类：
其他好文 时间：
2017-12-14 21:02:57
阅读次数：
100
核心知识点： （1）一般的if/else是前面不执行，后面才执行，循环下面的else是前面执行完后面才会执行，如果是break打断也不会执行。循环为空或False也不执行。 （2）try/expect是前面不执行后面才会执行，try/expect/else是try执行成功才会执行else，也就是ex ...
分类：
其他好文 时间：
2017-12-12 00:20:49
阅读次数：
265
建议152：最少，甚至是不要注释 以往，我们在代码中不写上几行注释，就会被认为是钟不负责任的态度。现在，这种观点正在改变。试想，如果我们所有的命名全部采用有意义的单词或词组，注释还有多少存在的价值。 即便再详细的注释也不能优化糟糕的代码。并且注释往往不会随着代码的重构自动更新，有时候我们可能会在修改 ...
建议148：不重复代码 如果发现重复的代码，则意味着我们需要整顿一下，在继续前进。 重复的代码让我们的软件行为不一致。举例来说，如果存在两处相同的加密代码。结果在某一天，我们发现加密代码有个小Bug，然后修改了它，却又忘记了角落里的某处存在着一份相同的代码，那么这个Bug就会隐藏起来。 让我们重现这 ...
建议143：方法抽象级别应在同一层次 看下面代码： Init方法本意要完成初始化动作，而初始化包括本地初始化和远程初始化。这段代码中，Init方法内部代码的组织结构是本地初始化直接运行在方法内部，而远程初始化代码却被封装为一个方法在这里被调用。这显然是不妥当的，应为本地初始化和远程初始化的地位是相当 ...
建议137：委托和事件类型应添加上级后缀 委托类型本身是一个类，考虑让派生类的名字以基类名字作为后缀。事件类型是一类特殊的委托，所以事件类型也遵循本建议。 委托和事件的正确的命名方式有： 若果用传统方式，我们可能看不出来这些类型是有基类的，但是委托和事件的关键字delegate和event已经指明了 ...
建议135： 考虑使用肯定性的短语命名布尔属性 布尔值无非就是True和False，所以应该用肯定性的短语来表示它，例如，以Is、Can、Has作为前缀。 布尔属性正确命名的一个示例如下： 反面教材： 肯定性形容词或者短语虽然表达了一个肯定的含义，但是这些单词或者短语现在都被用于命名事件或者委托，所 ...
建议138：事件和委托变量使用动词或形容词短语命名 事件和委托使用场景是调用某个方法，只不过这个方法由调用者赋值。这决定了对应的变量应该以动词或形容词短语命名。 关于事件和委托变量妥当的命名示例如下： 这两个例子是WPF中Button类型，它们实际不是作为类型的字段出现的，而是作为事件访问器出现的： ...
建议151：使用事件访问器替换公开的事件成员变量 事件访问器包含两部分内容：添加访问器和删除访问器。如果涉及公开的事件字段，应该始终使用事件访问器。代码如下所示： 使用事件访问器的好处是，提供对赋值更多细粒度的控制。这就好比应该使用属性而不使用字段一样。所以下面的代码没有事件访问器灵活： 转自：《编 ...
建议140：使用默认的访问修饰符（我不太赞成作者的这个观点，这样减少的代码基本可以忽略不计，但是，如果把访问修饰符补充完整，反而会使代码更加易读。我认为自己写代码时应该尽量加上访问修饰符，看别人写的代码时能看懂就可以了。以下是作者的观点） 代码整洁的要求之一，就是尽量减少代码，我们从使用默认的访问修 ...
