Question

C程序设计语言 K&R 第二版 课后习题算难的吗?今天在做第一章最后几道题目的时候,想象起来都觉得不难

但是实际写代码的过程中会发现自己的想法有各种各样的问题,需要解决,然后在解决细节问题的过程中,思路就乱了(更甚者和之前的思路反了)。
想问问各位初学者，你们有面临这种问题吗？
想问问C老手，你们在用C解决一个问题的思路？是先全部想好还是什么？还是说边做便想，然后不停的用函数实现小的细节？

先谢谢各位了，复制粘贴的不用浪费时间了

Answer 1

你问的第一个问题，算是所有初学者都会有的问题。
譬如给你一堆工人，一张设计图（或没有），让你去设计一栋大楼。
不妨可以设身处地的设想下，你会感觉，你对于楼房什么样子的，概念都是有的，华丽的、庄严的、威武的，基本上已经美滋滋的出现在你脑子里了。
现在开始做，用不了两天，各式各样的问题出现了，譬如，有的你能想到的，它实现不了；譬如有的能实现，你不是按照你预先设想的那个样。
然后，或许中途而非，或许出来一个你完全没有想到的丑陋的房子。
为什么这样？很容易想通，因为建造大楼的基本知识，你没有，或者有而基础不牢固。
写C是不是也这种感觉呢？
变量类型，不少；方法定义方式，不少；同一个问题，实现的方式，不少；各种精妙的部署方式也不少。
可唯独少的，就是你对他们的了解，因为一无所知，所以，不知道该在什么时候用什么东西，来较为完美的完成自己的设想。
所以，对于这个初学者的问题，你只是缺扎实的基础。
第二个问题，我还算不上什么老手，不过，我能明显的感觉到自己很明显的成长。
我的解决思路是这样的。
一开始学C: 想实现一个工程，先在脑子里大概把它分解为比较小的单元，然后挨个实现。实现完 毕后，发现很多东西，可以改善（比如有时候switch的使用，而后发现，有些地方，for + if 更能高校解决问题<这里的高效，仅仅指的是代码精简>），这样，积累了最初的经验，也算是对所有的C设计的比较基础的问题，齐齐的摸索了一便，走了不少弯路，也积累了很多经验。
后来熟悉后用C: 想实现一个工程，先思维工程主体思路是什么，用流程图勾勒出来完整的流程，大概流程出炉后，在考虑各个流程中如何实现；思考一圈，就会发现有些地方，思路实现的问题性很重，就这样不停的改，等得出一个较为合理的思路后，编写代码，测试运行。常常在运行的时候，就会发现自己很多问题没考虑到，相对一开始写C效率上来了很多，经验积累也快了许多。
现在用C：方式和上边的相差不大，不过，简单了不少，很多要实现的东西，一知道后，立刻脑子里就有相对应的几种方式。然后，考虑运行速率，占用内存情况，内存溢出等常常不小心就会出现的问题是否都考虑周全，如果有同事，讨论下，参考是否有更好的解决办法，然后动手。
总之，不论学什么语言，一开始，扎实的基础，永远是最重要的。这个，等你有一年代码经验，你就会很深刻的体会到。当然，写代码的时候，最好一开始就注意代码规范，推荐一个 华为的C代码规范，你可以百度下。养成一个良好的习惯，伴随一个扎实的基础，没什么你会感觉到解决不了的。

追问

您说的最详细,就给你吧,其实大家说的都没错,先有想法,画成流程图,然后按照流程图的总体思路进行修改(有流程图貌似还是会有一些没想到的小细节,后面修改只要你设想的流程(或者说算法)没变,多修改几次就能出来了。这是今天晚上看了大家的建议后 实践总结出来的。

追答

嗯，思不错，就差基础了。巧妇难为无米之炊，也是这个道理。
如果还写不出满意的代码，那只怕就是那个究极的原因：懒

Answer 2

A。初学者的话先话流程图，理清楚思路，上机写代码之前写在纸上打个草稿。准确率会上去
B. 程序=数据结构+算法，假定你修过这两门课
C。多写代码，任何一个高手长时间不碰编程也会生疏的。
D。写程序出错难免，最能体现艺术性的就是Debug。Debug的技巧要靠长期实践积累。先猜测哪里出错的概率最大，用一些手段检测那个地方。
E。模块化编程，就是分成几个功能模块，分成几个小函数来写。这也是一种技巧。

Answer 3

最开始的时候，大家都有这种困惑，特别是对计算机语言这种和我们的自然语言有着很大的区别的“语言”。我建议你先照着书上的例子敲程序，多看，多敲。另外，绝对不要仅限与这一本书，多找一些自己能大概看懂的例子，进行练习。等到你敲得多了，你就会找到自己解决问题的方式了，别人的方法对你来说只能借鉴，这就像你最初学习语文一样，你和大家说话，说着说着你自己就会了。

Answer 4

先考虑大概用到的算法和数据结构，然后写主函数，然后再实现子函数。