rescue
    # silently, we fail
    # many validations fade
    # like tear drops in rain
  end

这只是众多案例中的一个……

[vrk:Cloud ID="cTags" runat="server" DataTextField="Tag" DataWeightField="Total"
    Width="100%" DataHrefField="Tag" DataHrefFormatString="~/tags.aspx?tag={0}"]
[/vrk:Cloud]

[!--if anybody would like to change the control's color contact with FLORJON--]

我经常看到这种情况:

// TODO make this work

这不是严格意义上的评论，但是…

那是20世纪90年代中期，我正在进行一次大的迁移:小软件供应商，大客户，压力很大。我们有很多转移门柱的东西;这个项目很难控制。我是关键的开发人员，但对系统还不熟悉，而另一个开发人员是供应商的所有者/创始人。

在几个月没有按时完成任务，也没有让客户满意之后，公司的所有者/创始人找来了另一名远程工作的开发人员。(我可以大胆地说，新开发人员的技能和经验都不如我。)

好吧，这个新人对我已经做过的代码做了一些更改，然后一两个月后我又回到了代码的同一区域，其中有一些我以前没有见过的变量。他的名字叫StupidMark。

伙计，这是不对的。我的意思是，有团队合作方面的考虑，但是:在这个环境中，变量名可能会出现在运行时错误消息中。我只是说说而已。

在我看来，那个新人的代码并没有让我们更接近可交付的产品，这让侮辱变得更伤人了。

我参与的一个大型项目在自动构建中使用了StyleCop和FXCop，并使用规则来防止人们检入带有未注释字段、方法、属性等的代码。

有些人对必须添加“获取或设置全名”之类的注释到自记录属性(如FullName)感到非常恼火，以至于他们不得不努力编写一个宏来绕过这些规则。

宏为方法、属性等插入了XML摘要标记，其中一个单一的不显示Unicode字符作为标记内容，这将欺骗构建规则，同时对为了注释而盲目坚持的东西进行轻微打击……

.．.至少直到他们引入了另一条规则来检查注释中的Unicode字符。

using namespace std;            // So sue me