这是让我思考这个问题的确切情况。
我有自动功能 生成下一个逻辑项 数。该项目编号的一部分 包括项目编号的年份 创建了。我们现在在这一年 2010年是最重要的部分 约会的日期（为了我的目的） 项号）是“10”并且是2 长字符。如果我的计划会发生 按照它的方式在2009年执行 当前编码，我会得到一个坏项目 数字，因为我的系统是期待的 两位数的日期（10）不是一个 数字（9）。
我的问题根本不是关于我的具体情况，是否做一个字符串操作是一个好主意:)但更多的是基于我的标题中所述的原则。编写在历史记录中无法正常运行的软件是不是一个坏主意？您是否遇到过类似情况，您采取了什么路线？为什么？
答案 0 :(得分：5)
完全有效的说，“我的程序不适用于历史数据。”在您的具体情况下，“历史数据”是2010年1月1日之前的内容。我强烈反对那些认为对您的代码施加此类限制通常是个坏主意的人。
我们每天都受到这些限制。例如，标准UNIX time_t的范围为正负68年左右。使用time_t存储日期和时间的应用程序不能代表1901-12-13之前或2030-01-19之后的日期。然而，使用该时间格式编写了数百万个应用程序。但我们没有听到有人认为那些节目有点不好。
构建应用程序完全是为了权衡。如果在最佳判断中没有必要涵盖过去或甚至将来某个任意点以外的日期，那就没关系了。这与设计一个只能容纳X个记录或使用1TB驱动器部署的系统没有什么不同，因为您知道最终在数据增长时必须进行升级。事实是，我们无法针对每一种可能性进行设计。
那些认为“Y2K错误”显示为什么你不应该对你的代码施加任意限制的人不会考虑事情。毕竟，4位数年份也是一个任意限制。如果我想在过去或将来代表一万年的日期怎么办？那个错误的Y10K bug！在某些时候，我们对我们支持的事物范围进行限制。
每一件软件都有局限性。您可以选择适合您的应用程序的限制以及您将来如何看待它。
答案 1 :(得分：3)
我猜你听说过bug y2k？所以，是的，这是一个不好的做法。
答案 2 :(得分：1)
取决于您的部署要求，但作为一般原则，这是绝对不良做法。
计算机时钟经常被设置错误或不同，无论是出于正当理由*还是仅仅因为电池故障或其他原因。你的计划应该在这种情况下失败吗？
而且，可笑的是，任何人都会在90年后使用你的代码，但程序可能会超过预期 - 多年来，他们最终会回到个位数。假设这一年永远不会再次成为'01，这是短视的。
基本上，将自己锁定在当下的任意偶然事件中并不是一个好主意。
*例如，要解决其他软件的问题，这些软件会做出无根据的日历假设。
答案 3 :(得分：1)
灰色区域。我认为编写当前日期早于1970年（Unix epoc）时无法运行的代码是可以的。在今年之前可能有点冒险。即使除了意外之外，还有很好的理由可以解释为什么人们会设置时钟错误的测试用例 - 可重复性和/或与日期相关的回归测试。
如果你想要一个基于日期并且不会很快换行的短代码，那么一年大概是2 ^ 25秒，所以你可以将秒 - 自 - epoc日期除以，并取两个十六进制数字。它有点人性化，因为你可以判断一个值是否是“最近的”，但它不是那么人类可读，以至于人们会依赖它作为一个2位数的年份。
它持续超过2226年。我个人想要在代码中加入一些来检测那个条件，或者最好是允许它换行（即不要假设那些数字实际告诉你日期的任何地方，只是把它们视为哈希桶。）
即使是十进制数字，你也意识到你可以把2009写成“09”，对吗？没有必要导致短字符串; - ）
答案 4 :(得分：1)
这个问题的答案取决于您希望代码的灵活性。如果您不打算更新或使用此代码用于其他任何目的，并且它现在用于其目的，那么以这种方式编程是完全合理的并且不一定是不好的做法。但是，如果您希望您的软件能够在其他场景中实现，而不仅仅是明确地执行其原始功能，那么这不是一个好主意。重点是从乐观的企业角度出发，不要;从现实的编程方面来看，继续。