那个大佬可以教教怎么做大型的c语言程序哎.现在只知道敲200行以内的代码...

[彩鸽咕咕咕]

应该看什么书..或者向什么学习吗... 大佬们 我没分哎..(｡•ˇ‸ˇ•｡)…

[linfengc]

大的就是由小的组合而成的。 你现在只学了小的功能，没有大的需求。 如果有了大的需求，你做的东西自然就是大型的了。

[赵4老师]

量变到一定数量级，一定会发生质变！

[彩鸽咕咕咕]

谢谢大佬们啦(｡･∀･)ﾉﾞヾ(･ω･。)

[Healer_S]

将系统api进行全部封装一次

[@风轻云淡_]

你可以找一些小项目，比如银行管理系统啊，什么图书管理系统，学生管理系统啊，基本上都是用链表实现的，你有兴趣可以去看看，资源应该有很多的。

[smwhotjay]

c++

[赵4老师]

随便搜索下载一个开源的C语言项目（比如Tiny C Compiler或gcc/g++）。
使用Source Insight软件。

[ooolinux]

个人觉得，行数不是绝对的，都是模块/函数组成的。只不过代码越多，函数之间调用关系变得复杂，调试难度也会增大。还是应该多实践。

[ooolinux]

自上而下：先写出框架，函数用占位桩，再充实各个函数。
自下而上：先写函数，再堆起来。

[ooolinux]

引用 4 楼 u010165006 的回复:

自上而下：先写出框架，函数用占位桩，再充实各个函数。
自下而上：先写函数，再堆起来。

可以结合起来。

[super_admi]

你这个问题，其实不是一个C或者C++的问题，而是一个关于问题规模的问题。

软件，或者程序的根本目标是什么？其实是为了解决我们遇到的各种问题或需求，所以，“解决方案”这个词，在软件中很常见。但是，解决问题，很多时候也不一定非要靠软件，甚至完全和软件完全不沾边，所以，“解决方案”这个词，在其它行业也很常见。

对于计算机来说，不论你问题是什么，不论你问题有多大规模，不论你需求多么无聊，它总是在那里0、1、1、0……这样做事。可是对于人来说，不同的问题规模，处理的方式就不一样了。

很小的问题，几行乃至几十几百行代码就搞定了；
稍微大一些的问题，可能必须要上千行代码了，OK，不行了，受不了了，我们必须要理一理这里面的思路，于是乎，各种清理思路的办法就出来了：早期的代码，很多都是写在一个文件里，洋洋洒洒一长串--这让现在的人很不理解，于是，首先代码用文件分开，以前一个文件里的代码，用多个文件拆分；其次，用函数拆分代码--这是一个极为重大的突破，把各个功能点梳理下，做成一个一个的小模块，并借用数学上的概念：函数，来定义它；最后，梳理一套设计思想，比如：自顶向下，逐步细化……
如此如此，这般这般，这就是早期的程序设计上的方法学，其实最根本的缘由，就是因为人受不了太大的问题规模，必须要进行问题拆分。

接下来，问题规模进一步扩大，面向过程的设计思路也不好使了，于是乎，我们把一个大的问题做拆分的时候，干脆在思想上就进行一个分层：微观的，还是延用以前的面向过程；宏观的，则衍生出了面向对象的方法。
为什么会出现面向对象？因为本质上说，人还是习惯于在自己的世界里思考自己的问题，而计算机的世界，和现实世界大不相同。所以，为了让计算机世界向现实世界靠近，于是就抽象抽象再抽象，搞出了一套类似现实世界的思考方法来描述计算机世界：面向对象。

面向对象的思想是有了，但我们又发现，很多时候，我们总是在做一些重复的编程工作。怎样把这个“重复”去掉呢？于是乎，各种框架、各种技术就因此而诞生。比如大名鼎鼎的COM组件，就是希望做到二进制重用；而后面Java中的各种框架，基本上也是基于“重用”的目标而出现的，当然，所谓提升开发效率什么的，只是“重用”的附带产出。“重用”进一步专业化，则你就看到了应用于各行各业的框架：比如制造业的ERP、PLM、MES等等。

接下来，我们又碰到问题了：我们希望计算机能非常非常快，存储能力非常非常强（其实，貌似这个问题一直都存在，只不过由个人扩散到了全球人类），非常非常聪明。只是，单计算机技术，目前远远不能达到我们的要求（假设有一台计算机能达到要求，那么其实云计算、云平台什么的，都可以歇菜了），所以，我们就考虑N多台计算机联合起来，一起解决我们的问题，所以，大数据、云计算等东西因此而产生。

至于真正的人工智能，则是计算机的终极目标，不说也罢。

[ckc]

看书解决不了你这个问题。 编程是工程工作，工程类的工作除了去做，没有第二条路可以学会。 你写了200行的代码，熟悉了之后去找400条的代码量的工程来练习， 没问题了再去找更大的

[走好每一步]

看书是提高不了太多了，如果你能控制的代码行数还停留在200行，那你必须找一份几千行的代码去啃，才能真正入门。
赵老师说的很多，量变引起质变

[彩鸽咕咕咕]

很有帮助...谢谢(｡･∀･)ﾉﾞヾ(･ω･。)

[super_admi]

老赵你觉得我说得对不对？

引用 7 楼 zhao4zhong1 的回复:

量变到一定数量级，一定会发生质变！

[super_admi]

从你的回答，我感觉到了强烈的敷衍气息迎面扑来。

引用 16 楼 zhao4zhong1 的回复:

引用 15 楼 super_admi 的回复:

老赵你觉得我说得对不对？

[quote=引用 7 楼 zhao4zhong1 的回复:]
量变到一定数量级，一定会发生质变！

对！太对了！！[/quote]

[赵4老师]

引用 17 楼 super_admi 的回复:

从你的回答，我感觉到了强烈的敷衍气息迎面扑来。

引用 16 楼 zhao4zhong1 的回复:

[quote=引用 15 楼 super_admi 的回复:]
老赵你觉得我说得对不对？

[quote=引用 7 楼 zhao4zhong1 的回复:]
量变到一定数量级，一定会发生质变！

对！太对了！！[/quote][/quote]
你的感觉无疑是对的。原因参考下面：
请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。

所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

[super_admi]

从你的回答，我感觉到了强烈的装逼气息迎面扑来。

引用 18 楼 zhao4zhong1 的回复:

引用 17 楼 super_admi 的回复:

从你的回答，我感觉到了强烈的敷衍气息迎面扑来。

[quote=引用 16 楼 zhao4zhong1 的回复:]
[quote=引用 15 楼 super_admi 的回复:]
老赵你觉得我说得对不对？

[quote=引用 7 楼 zhao4zhong1 的回复:]
量变到一定数量级，一定会发生质变！

对！太对了！！[/quote][/quote]
你的感觉无疑是对的。原因参考下面：
请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。

意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。

试对比
图书馆（对图书的分类够结构化了吧）
和
搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索）
哪个处理信息更方便、更高效。

所以
与其费劲去重构代码让其看上去更简洁、更合理
不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。

结构越复杂，越难修改，越难除错。
有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。

程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George

前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题：
◆“要保证这个问题不会再出现，我该怎么做？”
◆“要想少出些Bug，我该怎么做？”
◆“要保证Bug容易被修复，我该怎么做？”
◆“要保持对变化的快速响应，我该怎么做？”
◆“要保证我的软件的运行速度，我该怎么做？”
如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。
[/quote]

[赵4老师]

你看人还是很准的。

[赵4老师]

引用 15 楼 super_admi 的回复:

老赵你觉得我说得对不对？

引用 7 楼 zhao4zhong1 的回复:

量变到一定数量级，一定会发生质变！

对！太对了！！