如何编写过期date的代码？
我只是有这样一个想法，我希望能够使用：
比方说，我必须修复一个bug，然后决定编写一个丑陋的代码行来解决眼前的问题 – 但这只是因为我向自己保证，我很快就会find时间来执行正确的重构。
我希望能够以某种方式将该代码行标记为“Expired in”并添加一个date – 以便如果代码在该date后编译一段时间，则会出现编译错误/警告并显示正确的消息。
有什么build议么？ 它必须能够执行 – 也许使用一些复杂的#IF或在Visual Studio中的一些选项？ 我正在使用VS 2005 – 主要用于C＃。
谢谢！
[编辑]：哇 – 从来没有预料到这个问题，以提高这么多的兴趣:)谢谢大家的答案，并把它变成一个有趣的辩论。 我知道使用这样的东西是很困难的 – 我可能不会使用它 – 但是有时候，当你必须发布一个版本的YESTERDAY，而你发现自己在一个修补程序上妥协 – 而你想强迫自己修复它在不远的将来。
我select了MartinStettner的build议作为答案，因为它满足了我的需求 – 在运行时没有错误 – 只在编译期间，不需要为此目标定义新types – 并且不限于整个方法的范围。 干杯!
你可以在表单中写评论行
// Expires on 2011/07/01 并添加一个prebuild步骤，通过类似的方法在整个解决scheme中replace这些行
#error Code expired on 2011/07/01
对于包含当前date之前的date的所有行。 对于这个预build立的步骤，你需要编写一个简短的程序（可能使用正则expression式和一些date比较逻辑）
这个步骤也可以通过一个VSmacros来执行，它允许更容易地访问解决scheme的所有文件，但是有一个缺点，就是必须在编译项目的所有VS安装中安装和运行。
用System.ObsoleteAttribute属性标记代码，你会得到一个编译器的警告，这将唠叨你修复代码
[Obsolete("You've an ugly hack here")] public void MyUglyHack() { ... }
或者， 。 。
编写自己的属性，在构造函数中传递一个到期date，如果DateTime.Now >= expirationDate ，则在构造函数中抛出exception。
编译将会失败，直到你修复代码（或者更可能增加过期date，或者更有可能的是你删除属性。
oooohhh – 这是'可怕的。 试试这个傻笑：
[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) { ... }
… 讨厌 ：-）
[免责声明] – 以学术兴趣的名义创build，而不是生产代码中文！
[编辑] – 只是为了澄清，编译和生产的代码将继续在“bugExpriryDate”之后运行。 只有代码在编译器中运行（在date之后），才会引发警告消息（debug.assert）。 只是认为值得做这个区别 – 欢呼马丁·斯泰特纳。
[警告] – 如果用在类/方法等将需要通过reflection读取。 然而（这是有趣的）将直接在编译器中使用，如果使用sub Main() 。 多么奇怪！！ （感谢点头汉斯…）
我认为这是Visual Studio有一个任务列表的原因。 添加评论：
\\ TODO: Fix this spaghetti by 01APR11
它会像这样出现
。
关键字可以从选项中configuration
那么它不完全是你要求的，但你可以使用一个Debug.Assert（）方法调用，它会提醒你（只在Debug中）代码已经过期。 一个好处是它不会无意中影响你的生产代码（编译或执行），但是在Debug中会让你感到烦恼，因为你想纠正它。
// Alert the developer after 01/07/2011 Debug.Assert(Date.Now < new DateTime(2011, 7, 1))
如果你有代码的unit testing，你可以定时炸弹validation你的修复的testing。 这样你就不会在生产代码中引入奇怪的检查。
另外我认为最好的select，如果你必须投入黑客（你可能已经花了足够的时间来看待它，以适当修复…但仍然需要黑客）比开放的错误/创build任务/工作项目（无论你用于跟踪未来的工作），并决定是否要稍后修复它。
如果不控制编译器（可能在编译器即服务的5.0时间范围内），则不会让代码过期。 您可以将代码标记为不推荐使用，或者使用Obsolete属性或类似方法来发出警告，但是人们可以忽略警告（我遇到的许多开发人员并没有学会警告是错误的规则）。
我认为尝试保护自己的人是很多工作。 当你将来要保护自己的时候更加困难。 将代码标记为一个杂项，并留在那个。
不要embedded定时炸弹，可能考虑应用BUGBUG：注释 ？
与其强迫你或其他人修复那些可能有点不美观的代码，不如按照预期的方式工作，你可以在整个解决scheme范围内进行search，并在你决定是时候重新构build真正的代码时寻找丑陋的代码丑陋的东西。
用错误追踪它。 然后，可以适当地调度并优先进行其他重构工作。
代码中的TODO注释可能会有丢失和遗忘的倾向。 在特定date之后抛出编译器错误可能会导致该date被推进，或者注释/属性被删除。
TIME和DATE都发出string，就我所知，在预处理阶段没有办法parsing它们。
有几种方法可以在代码中轻松完成，以确保代码至less在运行时警告您。 包括一个断言是一种方式，放入一个代码注释也可以，但是我处理它的方式是通过包含一个doxygen注释和一个注释来解释该函数包含一个需要解决的黑客，错误或性能问题。 这最终被许多程序员过滤，很容易在网站上查看自己或其他人修复。
