浏览下？直接编译？如果不行调试，再编译再调试？还是....?

一般第1次完成后，我会大概看下思路，然后编译，这时多会有错误，根据提示修改一般就OK了。

大点的程序，我会一部分一部分的测试，完成某个功能或者函数，觉得不塌实就测试下，OK了再continue。

不错的习惯，楼下继续

随便深入点问 ‘大概看下思路’指的是逻辑关系方面么？ 希望大家一起来讨论下，讨论下开发一个软件应该形成的一些良好习惯。最近写了几个破东西，因为一些不良的习惯，吃亏挺大的。

大概看下思路 就是顺着我脑壳里的logic反映到代码上的是否一致，清晰。函数的调用是否明确等等。这个过程几乎一眼就扫过，毕竟是自己写的嘛。

其实所谓的大点的程序，不过是多几行代码。要真的是在开发软件，就有一套完整的软件开发流程了，包扩设计，编写，测试，调试……agian。说起来就复杂了。

一般个人写的代码，就要遵循一个原则，编码-编译-调试 再重复这个过程。

我现在还没写过什么比较大的程序
一般是敲完代码就直接编译，错了再改。

我也一样，打完代码直接编译，错了再改。一般来说都可以改好，必竞是小程序。

最开始我也是敲完代码，迫不及待的编译，等着编译器告诉我那里它不接受，然后改，一直改到编译通过，编译通过后往往想“呼~~~终于好了”，然后小心的运行程序，执行原来设计好的测试用例，幸运的时候它是有效，只是有效，不一定是正确的，更加不是最好的，毕竟代码是“拼凑起来的”，自己真的理解程序的每一句么？该考虑的都考虑了么？结构是否合理清晰？内聚性，耦合度，重用性，错误处理？后来感觉在点编译前做的事情越多，准确率会越高，对程序的理解也会加深，感觉在编译前起码让自己觉得程序没有问题，在心里先运行一次，虽然它肯定还有问题。以上只是个人对编码过程的一些拙见，还望有人提供更多的信息，以确保在调试前对程序有更深的理解。

直接编译  看有没语法错误..

都是牛人，小弟该向你们多多学习