新手弱问下大家的程序大概都有多大啊、、、

发表于 2009-9-19 00:22

不要说写，我看一个程序都很困难。。。

前些天看一个300来行的程序就花了7、8个小时

( ⊙o⊙ )。。

发表于 2009-9-19 00:30

那手也太新了，跟大小无关，只跟能否满足应用有关！！！

发表于 2009-9-19 00:56

多看多练习~
先别去考虑几行多大

发表于 2009-9-19 01:11

你没用好的编辑软件？

发表于 2009-9-19 14:21

在很多情况下，看别人的程序比自己写程序还难得多。

发表于 2009-9-19 14:31

刚开始依葫芦画瓢还是很有效果的，但前提是那葫芦的形状还算周正

发表于 2009-9-20 11:02

程序不在长，在于算法经典程度。300行的NOP就不怕，哈哈！

发表于 2009-9-21 10:32

本帖最后由冷漠于 2009-9-21 17:12 编辑

看过一篇编程心理的**。无论是汇编还是C/C++ ，就一般人来说，60行以上就开始让人难读了。我理解就是60行以上就是开始读效率开始低下，单个模块的程序越长，他人的读程序效率越低下。即使对编程员本身也是如此。

所以，才有那些顶级聪明的人，开发出宏汇编语言（分段编程）、C/C++（模块化）语言。所以，一个应用目标程序如果需要300行的话，若是编程高手至少要把它分为几个模块，让LZ一看就懂。绝对不要花7、8个小时。
程序的易读性表明了一个程序员的水平。

从心理学的角度，是应该60行左右就开始划分模块的。
如果去考微软，对同一道试题，要想做出让考官欣赏的程序答案，我想最好就是用模块像搭积木那样搭起来的。如果考生写了一个几百行的解决程序，那么如何让考官“欣赏”？尽管你编程能力很强。就像盖房子，那些令人赞叹、令人惊艳的设计，和那些平庸的设计，都是用相同的模块搭起来的。差别就在于会不会使用模块，知不知道有哪些模块，最后会不会搭了。

发表于 2009-9-21 11:15

个人喜欢把一个函数控制在两屏以内:$

发表于 2009-9-21 11:44

要看具体要求，如果要我写一个通信协议解析函数，传一帧数据进来，有上百种可能性……除了搞一串switch-case，我实在想不到还有什么实用的“划分模块”方法。

发表于 2009-9-21 13:17

程序的思想是首要的，可读性却是重要的~~

发表于 2009-9-21 16:50

写程序容易，看程序难，我有时看不懂我以前写的程序。呵呵

发表于 2009-9-21 19:48

本帖最后由冷漠于 2009-9-21 19:58 编辑

10楼是编程高手，都做到通信协议解析函数了。不过像处理一堆上百种可能这样的情况，应该想一下“前人是如何解决这类问题的？”提示：用函数指针数组。
假定一般方法：
switch（oper ){
case FUNC1:
      result = func1( );
      break;
case FUNC2:
      result = func2( );
      break;
......
case FUNC100:
      result = func100( );
      break;
......
}
这个switch-case语句可能有几百个选择，非常之长。

下面写一下解决方法的简单示意性结论，中间过程10楼一看就懂了。
......
void (*oper_func[ ])(void)={FUNC1,FUNC2,...FUNC100,...};

用下面这条语句替换前面整条switch 语句！
result = oper_func[oper ] (  ); // 结果，几百行语句化为一行语句了

发表于 2009-9-21 20:24

:L 顶楼上的
前人的没学习到.现在明白了
以前做过一个接收数据包命令用了2字节大约300多个
全是case break;

发表于 2009-9-22 13:37

13楼的方法不是不懂，与建立上百个函数直接操作全局变量相比（不然传入指针去操作更麻烦），我更喜欢一个很长的switch-case……尽管代码很长，只要理解了模型，你就会认为它其实很简单。
两种方法的区别类似状态机的横式与竖式写法的却别。
//addr,cmd,len,data,checksum
switch(cmd)
{
case _Cmd_Read://
{
……
break;
}
case _Cmd_Write://
{
……
break;
}
……
default:
{
……
break;
}
}
以上写法我觉得简单明了，再长也不会令人觉得难以理解（只要保持良好习惯，case列表和命令宏定义列表一致）。结合代码折叠功能浏览起来更方便。
类似如果象MFC那样，一个简单的函数封装十几遍，不停的点右键“goto xxxxxx define”，烦透了还没看到目标，看完目标了又要为回到最开始的地方而烦恼了。

发表于 2009-9-22 14:24

看程序，首先要看他要实现的什么功能，然后想想自己实现这个功能会用什么思路，然后根据他的思路来看程序，在比较自己的思路，看看自己的思路有什么缺点，这样进步才快

发表于 2009-9-22 16:07

读程序看你怎么读了，如果是模块化的程序那自然好一些，如果作者本身水平不好，程序功能实现了，却不规范，像一锅粥，那读者看起来自然就头大！！

新手弱问下 大家的程序大概都有多大啊、、、

相关帖子

浏览过的版块

社区建设奖章

欢快之小溪

以坛为家

技术奇才奖章

精英会员奖章

沉静之湖泊

七世轮回

终身成就奖章

坚毅之洋流

十世金身

技术领袖奖章

突出贡献奖章

荣誉元老奖章

技术新星奖章

精华达人奖章

湍急之河流

缘定三生

晶莹之水滴

新手弱问下大家的程序大概都有多大啊、、、