检查项

• ✅ 我已在Issues中搜索，确认这个 bug 没有被提交过。

基本信息

• 程序版本：v0.13.1
• 操作系统名称与版本：Windows 11 Build 26120.961

• 如果您使用的是例如 Arch Linux 等滚动发行版，请在此填写发行版名称，无需填写版本。非滚动发行版用户则需要填写版本。例如“Debian 12.6” / “Windows 11 Build 26120.961”等

• Python 版本：3.12.3

详细描述

当系统时间为国庆节之后时，使用 fcnearly 命令会导致报错崩溃，如下：

Holiday Predictor / 假期预测器 - 基于 Python 的调休预测工具
键入 help 以查看帮助。
> fcnearly
Traceback (most recent call last):
  File "C:\Users\a233d\Documents\git\holiday-predictor\__main__.py", line 88, in <module>
    print(calculation_forecast_nearly())
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\a233d\Documents\git\holiday-predictor\main.py", line 227, in calculation_forecast_nearly
    '--' + str(CalculationUtil.NearlyNext.today()[1].replace('_', '-'))]))
               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
TypeError: 'NoneType' object is not subscriptable

进程已结束，退出代码为 1

🐛 使用 fcls 命令时，若输入意料之外的输入，将会直接报错

例如：

Holiday Predictor / 假期预测器 - 基于 Python 的调休预测工具
键入 help 以查看帮助。
> fcls abc def sdge
Traceback (most recent call last):
  File "C:\Users\a233d\Documents\git\holiday-predictor\__main__.py", line 49, in <module>
    print(calculation_forecast_list(input_list))
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\a233d\Documents\git\holiday-predictor\main.py", line 104, in calculation_forecast_list
    start_year: int = int(given_list[1])
                      ^^^^^^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: 'abc'

进程已结束，退出代码为 1

应当加入 try 以解决这个问题

预测中秋节假期时，代码逻辑如下：

• 先预测国庆节假期，判断中秋是否包含在国庆里。如果是，则直接返回预测国庆假期的结果；如果不是，则预测中秋假期。

但是，在预测国庆假期时，如果预测的年份＜1949，则会直接抛出“指定年份 {year} 不存在国庆假期”。

这意味着，在预测中秋假期时，如果年份＜1949，则无法继续。

所以，我们应该在预测中秋假期时先判断年份是否＞1949. 如果是，先预测国庆假期；如果不是，则直接计算中秋假期。

我在Python 3.8中安装您的模块时报UnicodeDecodeError错误：

建议把setup.py中“with open("README.md", "r") as fh:”改为：
with open("README.md", "r", encoding='utf-8') as fh:

望采纳。

首先感谢仓库已有的贡献者对这个小工具的维护—— (❁´◡`❁)

这个小工具的确有它的实践价值，在许多情况下都是很有用的工具。不过程序仍然存在一些亟待优化的点，也有一些肉眼可见的不完美之处。如果这些地方都能够完善，那么这个工具就更能在用户手上发光发热。(/ω＼)

然而，问题在于，这个小工具的源代码有点过于混乱，这无疑会给其他贡献者的维护造成很大的困扰。比如，我今天想要给小工具新增功能，但是光理解源代码就耗费了几个小时的时间。代码过于冗余且混乱是开源社区中非常致命的一点——因为对于他人来说，理解就是一件耗费时间的事，而再在其上做出一些修改，则更给人无从下手的感觉。

就拿函数 forecast_chl 举例吧。原代码中，传入的参数 holiday_name 似乎并没有起到很大的作用——因为函数主要逻辑中，它是通过全局变量 user_input_list 来工作的。那么这样的传参就是完全没用的，它和把函数主体写在代码主体里面是等效的。既然我们要重构出一个函数，那就应该让它真正具备一点函数的特性。除此之外，还有一些不太符合 Python 主流代码风格的地方，在这里就不一一说明了。

总而言之，我个人认为，重写该项目是必要的，这样可以增进这个小工具代码的可读性和可维护性。对于此，我尝试重写了一份小工具的代码 NebuDr1ft/holiday-predictor，但因才疏学浅，难免有疏漏之处。如果您认为我的代码有借鉴价值，那我很高兴能够通过 Pull Request 贡献仓库，为小工具的建设增砖添瓦。

以上。祝好。

Nebu Dr1ft
2024/2/17