都过了好久才看到,好**啊

<br />6、流程图的人性化<br /><br />程序是写给机器看的，因此必须严格遵循编程语言的规范，否则机器就无法解析执行。而流程图则是写给人看的，因此应当尽可能地人性化。<br /><br />让我们对比一下这两个流程图（参见图&nbsp;1.11：“没人性”的流程图和图&nbsp;1.12：人性化的流程图）。它们描述的程序功能是一样的。<br /><br />前者更简洁，但是却给阅读者带来了思维障碍，“Key_Flag”是什么标志？“P1.0”又是什么功能的IO口？阅读者为了了解这些问题，不得不放下流程图去查阅相关的文档。阅读思路的连贯性被打断了。<br /><br />很显然，我们更喜欢第二个流程图。这才是无障碍的阅读。<br />不要吝啬那点打字的功夫，磨刀不误砍柴工。<br /><br /><img src="http://blog.21ic.com/UploadFiles/2008-9/192142383155.gif"><br />图&nbsp;1.11：“没人性”的流程图<br /><br /><img src="http://blog.21ic.com/UploadFiles/2008-9/192143450144.gif"><br />图&nbsp;1.12：人性化的流程图<br /><br />

<br />说到循环结构，还要额外说说for循环语句。因为今天在论坛里有<b>fzu_csc</b>网友问怎么只介绍了while循环和do-&nbsp;while循环，却没有介绍for循环。让我们先举个例子，先看看下面这个for循环程序：<br />&nbsp;<br />for(i=1;&nbsp;i&ltN;&nbsp;i++)<br />语句1;<br />&nbsp;<br />上例中：先给i赋初值1，然后判断i是否&ltN，若是则执行语句1（循环体），之后i值加1。再重新判断，直到条件为假（即i&gt=N）时，结束循环。可以看出，for循环其实就是一个当型循环结构（参见图&nbsp;1.11：for循环例子）。<br /><br /><img src="http://blog.21ic.com/UploadFiles/2008-9/192218761689.gif"><br />图&nbsp;1.11：for循环例子<br /><br />&nbsp;

  

等着学习

谢谢楼主。

高人高贴，留脚印～

用软件工程中提到有一种比流程图更规范的框图表达法，能从根本上整治乱用goto或不按结构化方法搭建软件框架的行为．不过话又说回来，大家还是习惯用流程图来交流．

我虽然是个菜鸟！<br />但我个人认为&nbsp;&nbsp;&nbsp;程序&nbsp;&nbsp;是要经常去熟悉的！&nbsp;&nbsp;&nbsp;很久不写&nbsp;&nbsp;&nbsp;容易丢失灵感！

建议多讲讲任务划分，调度，协作等等统筹规划方面的知识。<br />怎么样把复杂的任务安排得象交响乐团一样井然有序并行不悖。<br /><br /><br />至于框框是画成四角菱形六角菱形，个人觉得无所谓，公司怎么规范就怎么画。<br />

好，值得看看。

路过，小点教科，多点具体应用，面向实际问题展开，诱题深入，更有启发性

？

程序结构如果采用流程图，那才叫掉得大。

软件设计的关键步骤在于：要求分析，功能抽象和分类，模块划分和细化，最后才是结构化编程。<br /><br />建议在整个过程中采用面向对象的设计思路，前期可以考虑用UML描述，而关于“处理”部分应尽量考虑使用具有“结构化”约束的描述流程描述方法，只有这样才能确保最终形成“良好”的代码实现。<br />

  

hao

<H4>7、流程图的简化</H4><br />一个繁琐的流程图，是画流程图的人的噩梦，同时也是阅读者所不愿意见到的。因此，我们在画流程图时，不必拘泥于规则和形式，一板一眼。在适当的地方进行简化，不但可以节省精力和幅面，而且可以让流程图更易于阅读。<br />&nbsp;<br />让我们对比下面这两个图（参见图&nbsp;1.14：繁琐的流程图和图&nbsp;1.15：简洁的流程图）。这是同一个程序的两种流程图表达方法。程序的功能，是用查询法对脉冲输入口上输入的脉冲计数，当计数满100次后进行一些处理并退出。<br />&nbsp;<br /><img src="http://blog.21ic.com/UploadFiles/2008-9/221548836149.gif"><br />图&nbsp;1.14：繁琐的流程图<br />&nbsp;<br /><img src="http://blog.21ic.com/UploadFiles/2008-9/221548760014.gif"><br />图&nbsp;1.15：简洁的流程图<br />&nbsp;<br />很显然，第一个图占用了更多的幅面，却并不易于理解。而第二个图在经过简化处理后，节省了空间，程序思路反而表达得更加清晰。<br />&nbsp;<br />我们甚至可以进一步抛弃那些细微末节（参见图&nbsp;1.16：更简洁的流程图）。反正这个流程图是给人看的，只要看得懂程序思路，能简化何乐而不为呢？<br />&nbsp;<br /><img src="http://blog.21ic.com/UploadFiles/2008-9/221549665092.gif"><br />图&nbsp;1.16：更简洁的流程图<br />&nbsp;<br />简单的才是有效的。适当的简化，是人性化的体现。<br />&nbsp;

<br />总结一下简化的方法：<H5>（1）合并那些相互关联的条件判断。比如：当“条件1”满足，且“条件2”满足执行某个动作。我们可以把这两个条件判断合并后，放入同一个条件判断框中（参见图&nbsp;1.17：分支结构）。</H5><br /><br />&nbsp;<H5>（2）省去一些不必要的流程线。对于不会产生歧义的顺序结构流程，可以把那些箭头省略。节省空间，甚至可以把一些语句合并在一个执行语句框里面。（参见图&nbsp;1.18：顺序结构的简化）</H5><br />&nbsp;<br /><img src="http://blog.21ic.com/UploadFiles/2008-9/221555840942.gif"><br />&nbsp;<br />(未完、待续……)&nbsp;

古道热肠&nbsp;发表于&nbsp;2008-9-21&nbsp;09:38&nbsp;匠人手记&nbsp;←返回版面&nbsp;&nbsp;&nbsp;&nbsp;<br /><br />47楼：&nbsp;写得好，顶&nbsp;<br /><br />用软件工程中提到有一种比流程图更规范的框图表达法，能从根本上整治乱用goto或不按结构化方法搭建软件框架的行为．不过话又说回来，大家还是习惯用流程图来交流．<br />&nbsp;<br />&nbsp;<br />——回：你说的大概就是指“三、N-S图（盒图）”吧？稍后也会介绍到。

53楼：&nbsp;流程图只能表达局部，程序结构和流程图没关系&nbsp;<br /><br />程序结构如果采用流程图，那才叫掉得大。<br /><br /><br />我觉得程序结构架设就是流程图主循环部分（功能模块），这样理解和构建合理吗&nbsp;<br />&nbsp;<br />