写了这么多年程序，越写越懵了。。。。

会会

我同感
我非常讨厌这种东西！
所以 我会把我能封装的模块 都封装起来
MFC一边歇着
反正些代码用了自己的读写api 方便以后修改
还有 DX的枚举最讨厌 我全把他们封起来 用不到枚举 永远也不要出现在我眼前
：D

draculamx

C++的文件读写函数从来不用。。。
不是吧。。为了体会一下，我昨天还用 C++ 的 iostream 和 stl 做了一个可以在 WINXP.LINUX,WINCE上运行，并且速度很快的 INI 文件读写类。。。。

C++的“流”很差吗？？

ada_2008

API那个用的熟练就用那个。至于代码质量嘛，有诸如<Code Quality>这样的书可以参阅。关于程序设计的书多了去，大伙没事的时候慢慢看呗。

Lucker

draculamx: Re:写了这么多年程序，越写越懵了。。。。

C++的文件读写函数从来不用。。。
不是吧。。为了体会一下，我昨天还用 C++ 的 iostream 和 stl 做了一个可...

楼主如果真的是想能编好程序，就应多编程序而少写代码。少写一些功能性的类，多编一些有直接目的的应用。
比如编个股票行情显示系统（网上随便找一个），在给定了网络协议及数据格式后，光只是界面操作及图表绘制应在三四天内，用于计算指标的脚本语言的语法分析及解释执行应在一周内（各脚本数学函数的实现另算），一些额外的画线工具之类的功能应在两三天内。这个时候还要再意识到服务器端不用负责统计数据以减轻它的负担进而客户端用于计算排名及各种股票分类应在两三天内完成。
以上就是在看见一个股票行情软件时，且客户告诉你要你实现和它一样功能时应给出的信息，接着要做的是制定各模块间的访问接口，再接着就是叫手下实现这些接口，最后就是完成这个程序。而给出的天数代表预估的工作量，仅开发工作而不包含测试和调试。

我之所以说这些是看见楼主说自己编程序很快且bug少，这已经达到了基本要求，很好。所以提醒楼主应多注意语义这个概念以从程序员转型到设计师。前者是编功能，后者是编接口。
如果对于那些文件访问函数（不管哪种形式）的经验还只是停留在“体会”级别，我之前真的是看高你了（至少也应用过不下百遍才是）。

最后，我已经在之前指出了stl的文件流的坏处，在此不再复述（若没看懂那就算了），建议不要使用（就和很多人喜欢使用XML解析器来辅助记录数据一样，根本不懂什么叫数据记录而更不懂XML是拿来干什么用的）。如果楼主有兴致，编一个小型数据库引擎试试先，不用实现关系型数据库，只需要简单的一个表，可自定义多个字段且对指定字段索引，表的结构信息和数据信息存储在同一个文件中，索引再另存一个文件，这样楼主就可以明白数据记录不是文件流，编程序也绝对不是写代码。

神秘的猫

c程序就要c函数,MFC程序就用MFC函数撒..有啥好想的..
createfile用来异步读写和读写管道信息
c++流和stl偶尔用来写点小工具很方便

各有各的用处，完全不明白为什么会懵

draculamx

哎，我一直认为，我的水平，就是比“菜鸟”高那么一点点而已。。。

看来，一直以来，我只顾着完成任务，代码写出来了，却没有去想为什么要这么写，也从来没有总结过，写完的东西，除非要修改，否则基本上是从来不看的。。

恩。。“多写程序，少写代码”，这话有点意思。是说要多写一些具有完整功能的软件，而不是老盯着某些个软件的局部功能部分？？

恩。。。。如果要这样的话，业余时间必须利用起来了，公司的项目少啊。。。

qrli

恩。。“多写程序，少写代码”，这话有点意思。是说要多写一些具有完整功能的软件，而不是老盯着某些个软件的局部功能部分？？

理解错误，代码就是代码，代码要尽量少，这个少是靠好的算法和充分的代码重用来实现的。反之，如果你不停地在写多余的代码，或者不停地重复地写某些代码，因为写的次数太多了，所以必然很熟悉写得很快，但其实这些本来是不需要写的。也就是你“多写了代码，但没有写出新的程序”。如果是需要长期维护和开发的程序，这种重复代码会大大加大维护的难度。

qrli

draculamx: Re:写了这么多年程序，越写越懵了。。。。

C++的文件读写函数从来不用。。。
不是吧。。为了体会一下，我昨天还用 C++ 的 iostream 和 stl 做了一个可...

说明你写的功能太简单了。你试试用C++流写个能读取ansi、utf-8、utf-16等不同编码的INI文件，并且能在windows和linux上运行的类。 [em21]

rockomtv

介绍一小说 ，有时间的看看啊 《疯狂的程序员》

didibabawu

顶楼上，的确是本好小说，以前一直追着更新看的，作者是个牛人，膜拜之