程序内部的各种选项一般如何存储和处理

[superyangtze]

大家好！业余人士，请教专业程序员们一个眼下面临的问题：稍微大一点的专业软件内部都会有很多设置，这些存在.ini文件里，很好理解。但同时有些功能要求用户先进行选项操作，然后执行，不同的选项则会产生不同的结果。如果选项很多很复杂，那它们在内部是如何存储的？后续又怎么组织程序的流程，使得源代码变得清晰好管理？谢谢！

[superyangtze]

引用 1 楼 zgl7903 的回复:

选项很多 可以组织成一个结构体， WriteProfileBinary 和 GetProfileBinary 读写 程序内部 大量 判断 (if else switc) 加大量注释

谢谢老大！ 选项真的很多，有的是单选框，有的还是复选框，组合起来有二三十种。 还是都装在结构体里好。

[superyangtze]

引用 2 楼 pcradio 的回复:

MVC全局对象作为存储，所有的UI操作都关联到这个全局对象，打开UI界面从全局对象读数据更新UI

谢谢关注。 不是UI操作，是具体的功能实现，有很多选项供用户先行点选。

[superyangtze]

引用 3 楼 jason_wentzel 的回复:

.ini只不过是一种存储方式，以文本方式呈现，人能看懂而已，能看懂的东西就能理解。但要明白一点，程序中所有的配置信息不是给人理解的，而是给计算机理解的，只要计算机理解了才能解析执行，因此对用户来说，用户不必关心如何存储。 对于复杂的功能选项，都会有自己的存储结构，也就是说数据结构，只要把数据结构理清了，存成什么文件都行，只要计算机能解析出来就OK

谢谢指导！

[zgl7903]

选项很多 可以组织成一个结构体， WriteProfileBinary 和 GetProfileBinary 读写 程序内部 大量 判断 (if else switc) 加大量注释

[阿源是少年]

MVC全局对象作为存储，所有的UI操作都关联到这个全局对象，打开UI界面从全局对象读数据更新UI

[孤客天涯]

.ini只不过是一种存储方式，以文本方式呈现，人能看懂而已，能看懂的东西就能理解。但要明白一点，程序中所有的配置信息不是给人理解的，而是给计算机理解的，只要计算机理解了才能解析执行，因此对用户来说，用户不必关心如何存储。 对于复杂的功能选项，都会有自己的存储结构，也就是说数据结构，只要把数据结构理清了，存成什么文件都行，只要计算机能解析出来就OK

[赵4老师]

请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。 意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。 试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。 所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。 结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。 程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George 前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。