我在工作中使用Resharper.我的一些同事没有.
当我打开一些已写入的代码而不是其他代码时,我的屏幕上的橙色数量就会立即显而易见.
我不确定的是,我应该在多大程度上自由地整理那些在不知不觉中留下的混乱.对于我所看到的大部分内容,它是草率但无害的,如果我从未使用过Resharper,就不会真的跳出来.
我想我大致看到了我的选择
1)源代码更改的历史记录对于维护至关重要.尽可能少地改变,或者下一个人不希望弄清楚改变了什么.谁关心无法访问的代码,无论如何都不必要地使用.ToString()等.
2)更改无意义的东西,如包括,修复方法文档注释和类似的东西.写它的人喜欢他的代码看起来像这样,所以把它留在他不会抱怨的状态,但摆脱一些不必要的橙色
3)橙色只是红色但更轻.F12然后Alt + Enter直到绿色.
4)忘记橙色,看看怪物700线功能.这是什么1997年？是时候忙碌......如果你有时间,请把你的同事介绍给我们的好朋友和导师福勒先生.
我倾向于在选项之间进行过滤,具体取决于我有多少时间,我现在负责代码的程度,以及代码看起来有多复杂(这通常可以让我选择1或4).
看起来四个选项中的一个应该是我正在努力的那个,但我不知道哪一个
使用WCF netMSMQbinding时是否可以保证有序交付？
我们在同一队列上放置一个insert命令后跟一些更新命令,偶尔会有一个更新击败插入.
添加了大量日志记录后,很明显它们以正确的顺序添加到队列中,并以不同的顺序进行处理.
我已经设法向Google发表了一些文章,声明这种行为是预期的,但似乎必须有可能将其配置为以某种方式进行排序.
我们的队列是事务性的,所以我不认为在目的地添加序列号和重新排序会起作用,因为这会丢失事务性
如果我添加属性,[DeliveryRequirements(RequireOrderedDelivery=true, QueuedDeliveryRequirements=QueuedDeliveryRequirementsMode.Require)]我会收到以下错误:
合同'IService'上的DeliveryRequirementsAttribute指定QueuedDeliveryRequirements值NotAllowed.但是,此协定的已配置绑定指定它确实支持排队传递.排队的绑定不得与此合同一起使用.
我不知道为什么我们会收到这个错误,因为所有"看起来"都是正确设置的.我没有设法找到任何确认允许MSMQ的设置,因为它似乎是一个WS-RM设置,而AFAIK netMSMQBinding不支持WS-RM.