我正在对一个接受命令行选项的程序进行维护。有单字母选项，也有长字母选项。目前，长选项前面只有一个连字符。
许多工具的长选项都有双连字符。为了与现有的一致，我查看了一些GNU工具，发现对于长格式，有单连字符和双连字符的混合。例如，GCC编译器具有--help、--version，而不是-std、-funroll-loops。
所以我搜索了一些关于这个问题的文档，找到了这个GNU文档。在这里，GNU对长选项的风格建议是以两个连字符开头。
现在，我想知道为什么GNU工具不遵循这些GNU建议？我认为这是一个向后兼容性的问题，，但还有更多的问题吗
在我编写的程序中，当更改选项语法时，我通常会保留旧形式的功能，但没有记录，或者至少给出一个弃用警告。GCC(和其他)程序不可能这样做吗？
有很多理由不改变：
- 使用现有命令行选项的配置脚本和构建文件实际上有数百万(可能更多？)。既有最近的，也有非常古老的
- 人们已经习惯了当前的格式，所以多年来大多数程序员都会习惯性地使用他们已经知道的内容
- 参数解析代码通常很复杂，更改它只是引入错误的另一个机会
- 旧的向后兼容性单连字符长选项将与新的多个短选项相冲突，因此向后兼容性很困难
- 在此处插入更多内容
更改原因：
- 遵循许多应用程序尚未遵循的惯例
简而言之，惯例是很好的，理想情况下应该遵循新的东西，但通常不值得仅仅为了一致性而改变东西。
Makefile和其他构建脚本通常(至少部分)是与编译器无关的，因此GNU C编译器(以及GNU编译器集合gcc)必须在调用方式上与其他编译器保持兼容。某些C编译器肯定早于GNU程序参数语法约定。其他与开发相关的命令(如ld、ar等)也是如此，尤其是UNIX标准中的那些部分。
某些命令中的"Legacy"语法甚至可能需要符合某些标准。(C和C++标准似乎只指定了编程语言，但我可以想象UNIX标准也涵盖了某些开发工具的命令行参数。)