我对这个我喜欢能够使用的东西有这个想法:
假设我必须修复一个错误,我决定编写一个丑陋的代码行来解决当前的问题 - 但这只是因为我保证自己会很快找到时间进行适当的重构。
我希望能够以某种方式将该代码行标记为“Expired in”并添加日期 - 这样如果代码在该日期之后的某个时间编译,则会出现编译错误/警告并带有正确的消息。< / p>
有什么建议吗?必须可以执行 - 可能在Visual Studio中使用一些复杂的#IF或某些选项? 我正在使用VS 2005 - 主要用于C#。
谢谢!
[编辑]:哇 - 从没想到这个问题会引起如此多的兴趣:) 谢谢大家的答案,并将其变成一场有趣的辩论。 我知道很难证明使用这样的东西是合理的 - 而且我可能不会使用它 - 但有时候,当你必须发布一个版本的YESTERDAY并且你发现自己在一个不完整的修补程序上妥协 - 你想强迫自己修复它在不久的将来。
我选择了MartinStettner的建议作为答案,因为它满足了我的需求 - 运行时没有错误 - 仅在编译期间,不需要为此目标定义新类型 - 并且它不限于整个方法的范围。干杯!
答案 0 :(得分:32)
使用System.ObsoleteAttribute
属性标记代码,您将收到编译器警告,这将唠叨您修复代码
[Obsolete("You've an ugly hack here")]
public void MyUglyHack()
{
...
}
或者。 。
编写自己的属性,在构造函数上传递一个到期日期,在构造函数中抛出异常,如果DateTime.Now >= expirationDate
。
在您修复代码之前编译将失败(或者更有可能增加到期日期,或者更可能您只是删除属性。
答案 1 :(得分:27)
[AttributeUsage(AttributeTargets.All)]
public class BugExpiryAttribute : System.Attribute
{
// don't tell 'anyone' about this hack attribute!!
public BugExpiryAttribute(string bugAuthor, string expiryDate)
{
DateTime convertedDate = DateTime.Parse(expiryDate);
Debug.Assert(DateTime.Now <= convertedDate,
string.Format("{0} promised to remove this by {1}",
bugAuthor, convertedDate.ToString("dd-MMM-yyyy")));
}
}
然后,装饰你的方法/类等:
[BugExpiryAttribute("Jack Skit", "2011-01-01")]
public static void Main(string[] args)
{
...
}
......讨厌: - )
[免责声明] - 以学术兴趣的名义创建,而不是生产代码finese !!
[edit] - 只是为了澄清,编译和生产的代码将继续在'bugExpriryDate'之后运行。只有在编译器中运行代码(日期之后/之后),才会引发警告消息(debug.assert)。只是觉得值得做出这样的区分 - 为MartinStettner欢呼。
[警告] - 如果在类/方法等中使用,则需要通过反射来读取。然而(这很有趣)如果在sub Main()
上使用,将直接在编译器中工作。多么奇怪!! (感谢点头汉斯......)
答案 2 :(得分:17)
我认为这就是Visual Studio具有任务列表的原因。添加评论:
\\ TODO: Fix this spaghetti by 01APR11
它会像这样出现
可以从选项中配置关键字
答案 3 :(得分:16)
您可以在表单中写下评论行
// Expires on 2011/07/01
并添加一个预建步骤,通过类似
的方式对这些行进行解决方案范围的替换#error Code expired on 2011/07/01
表示包含当天之前的日期的所有行。对于这个预建步骤,您需要编写一个简短的程序(可能使用正则表达式和一些日期比较逻辑)
此步骤也可以由VS宏执行,这样可以更轻松地访问解决方案的所有文件,但缺点是必须在编译项目的所有VS安装上安装和运行它。
答案 4 :(得分:7)
它确实没有完全符合您的要求,但您可以使用Debug.Assert()方法调用,它会提醒您(仅在Debug中)代码已过期。一个好处是它不会无意中影响您的生产代码(编译或执行),但在Debug中会让您想要纠正它。
// Alert the developer after 01/07/2011
Debug.Assert(Date.Now < new DateTime(2011, 7, 1))
答案 5 :(得分:5)
如果您对代码进行了单元测试,还有一个选项,您可以定时检查验证修复的测试。这样,您就不会在生产代码中引入奇怪的检查。
此外,我认为最好的选择,如果你必须进行黑客攻击(你可能已经花了足够的时间来正确地修复它......但仍然需要一个黑客攻击)而不是打开bug /创建任务/工作项目(无论你用什么来跟踪未来的工作),并决定是否要在以后修复它。
答案 6 :(得分:2)
如果不控制编译器(可能在5.0时间范围内使用编译器作为服务?),您将不会让代码过期。您可以将代码标记为已弃用,或使用Obsolete属性或类似代码来触发警告,但人们可以忽略警告(我遇到的许多开发人员都没有学过警告错误的规则)。
我认为尝试保护人们免受伤害是很多工作。如果你将来保护他们自己,那就更难了。将代码标记为kludge并将其留在那里。
答案 7 :(得分:1)
可能考虑应用BUGBUG: comment?
,而不是嵌入定时炸弹而不是强迫你或其他人修改可能有点难看的代码但是按照预期的方式工作,你可以只做一个解决方案范围的搜索,并在你决定下来的时候找到丑陋的部分重构真正丑陋的东西。
答案 8 :(得分:0)
在bug中跟踪它。然后可以通过其他重构工作对其进行适当的安排和优先级排序。
代码中的 TODO
评论可能会丢失和遗忘。在特定日期之后抛出编译器错误可能会导致该日期被推送,或者注释/属性被删除。
答案 9 :(得分:0)
我希望我能帮上忙。在工具箱上取2 datetimepicker。只需转换1 datetimepicker。
private void expired()
{
DateTime expired = DateTime.Parse(Convert.ToDateTime(datetimepicker1.Text).ToString());
DateTime compare = DateTime.Parse(Convert.ToDateTime(datetimepicker2.Text).ToString());
if(expired < compare)
{
MessageBox.Show("This product is expired!");
}
else
}
MessageBox.Show("This product is not expired");
{
}
答案 10 :(得分:-1)
TIME 和 DATE 都会发出字符串,据我所知,无法在预处理阶段解析它们。
您可以在代码中轻松完成一些方法,以确保代码至少在运行时向您发出警告。包含断言是一种方式,放入代码注释也可以工作,但我处理它的方式是通过包含doxygen注释和注释来解释该函数包含需要解决的hack,bug或性能问题。这最终会被许多程序员过滤掉,并且很容易在网站上查看,供我自己或其他人修复。