请问傻孩子你写程序画流程图吗?
我现在写程序从没画过流程图,不知道这习惯好不好! 简单的就不用画了复杂的绝对要画,否则很容易把自己搞晕 复杂的就上OS
照样不用画 你画了.总比不画好..(我是没画过..) 我写的代码是流程图结构的……也就是说,我用了一种流程图风格
的语言,如果你读过我的状态机系统就能体会这种所谓“流程图风
格”的代码。检查起来非常容易。 用UML吧 【4楼】 Gorgon Meducer 傻孩子
你的状态机系统在哪? 偶写代码也没有任何流程图的
十万行级别,耗时1年的代码都写过 我也不画,改来改去麻烦 画了都没看过,做的时候直接写代码了。 都是牛人 图在心中,只有心中感觉太复杂才在纸上简单画 正规公司为了弱化个人在项目研发中的必不可少作用就会要求画程序流程图,代码注释要多要规范。 跟你写作文打不打草稿是一回事,如果没数,就打,如果有把握,文思泉涌,就可以不必了。不过刚学的时候还是不能偷懒吧。 一般不画流程图,但是一定要画状态转换图。 写完再画~公司要归档~ 呵呵,大家都以为画流程图比较傻,可是软件工程就是这样的,每个人的分工不同,很多人协同工作。
需求分析,软件构架,程序设计,程序编码。每一步,可能都是由不同的人完成的。养成好习惯,便于以后发展。
很多人,到我们公司都不习惯……,他们习惯单打独斗。 别把流程图和数据流图,系统模块结构图,状态图,UML弄混了。流程图可以没有,但是做工程,
以上的图(中的大部分)还是必须的。 谢谢各位大侠的指点! 流程图和数据流图,系统模块结构图,状态图,最近才体会到了他的好处,尤其你在接触别人的产品时,各人写程序风格不同,单看别人程序是个非常辛苦的事! 同问 Gorgon Meducer 傻孩子
你的“状态机系统”是一本书吗,哪里可以买的到? 回复【20楼】wukaka
-----------------------------------------------------------------------
是不是M128那本书啊? to 【21楼】 fshunj
我没有出过M128的书
to 【20楼】 wukaka
状态机的书很多,如果你英文功底好,推荐《Automata, Computability, and Complexity Theory And Application》
关于单片机状态机开发模式,最近我一直在更新,关注我的帖子就好了 谢谢 【22楼】 Gorgon Meducer 傻孩子
从你这里学到了很多东西。 16楼的老兄是那个公司的啊,有兴趣、、、、 回复【楼主位】lizihui
-----------------------------------------------------------------------
我做的程序老是机械硬件部分出问题,软件部分很简单 回复【4楼】Gorgon Meducer 傻孩子
-----------------------------------------------------------------------
请教傻孩子,如何能更好的把功能需求转化为流程图?我老觉得在知道功能需求的情况下,不知道怎样把它转化为流程图,谢谢你 画流程图除了容易检查错误外,是要给别人看滴,让别人看得懂,以后维护方便。这也是大公司强调注释和流程图的原因。
当你N年后再来看自己的程序,是否还看得懂???知道自己写程序的意图吗。
如果需要修改维护,恐怕只能另写一个了吧! 今天看到下面一段话,共享!
*********************************
在到Google工作之前,我一直认为编码规范没有什么用处。我坚信这些规范都是官僚制度下产生的浪费大家的编程时间、影响人们开发效率的东西。
我是大错特错了。
在谷歌,我可以查看任何的代码,进入所有谷歌的代码库,我有权查看它们。事实上,这种权限是很少人能拥有的。但是,让我感到惊讶的却是,如此多的编码规范—缩进,命名,文件结构,注释风格—这一切让我出乎意料的轻松的阅读任意一段代码,并轻易的看懂它们。这让我震惊—因为我以为这些规范是微不足道的东西。它们不可能有这么大的作用—但它们却起到了这么大的作用。当你发现只通过看程序的基本语法结构就能读懂一段代码,这种时间上的节省不能不让人震撼!
反对编码规范的人很多,下面是一些常见的理由,对于这些理由,我以前是深信不疑。
这是浪费时间!
我是一个优秀的程序员,我不愿意浪费时间干这些愚蠢的事。我的技术很好,我可以写出清晰的、易于理解的代码。为什么我要浪费时间遵守这些愚蠢的规 范?答案是:统一是有价值的。就像我前面说的—你看到的任何的一行代码—不论是由你写的,还是由你身边的同事,还是由一个跟你相差11个时区的距离人写的 —它们都有统一的结构,相同的命名规范—这带来的效果是巨大的。你只需要花这么少的功夫就能看懂一个你不熟悉(或完全未见过)的程序,因为你一见它们就会 觉得面熟。
我是个艺术家!
这种话很滑稽,但它反映了一种常见的抱怨。我们程序员对于自己的编码风格通常怀有很高的自负。我写出的的代码的确能反映出我的一些特质,它是我思考的一种体现。它是我的技能和创造力的 印证。如果你强迫我遵守什么愚蠢的规范,这是在打压我的创造力。可问题是,你的风格里的重要的部分,它对你的思想和创造力的体现,并不是藏身于这些微不足 道的句法形式里。(如果是的话,那么,你是一个相当糟糕的程序员。)规范事实上可以让人们可以更容易的看出你的创造力—因为他们看明白了你的作品,人们对 你的认识不会因不熟悉的编码形式而受到干扰。
所有人都能穿的鞋不会合任何人的脚!
如果你使用的编码规范并不是为你的项目专门设计的,它对你的项目也许并不是最佳方案。这没事。同样,这只是语法:非最优并不表示是不好。 对你的项目来说它不是最理想的,但并不能表明它不值得遵守。不错,对于你的项目,你并没有从中获得该有的好处,但对于一个大型公司来说,它带来的好处是巨 大的。除此之外,专门针对某个项目制定编码规范一般效果会更好。一个项目拥有自己的编码风格无可厚非。但是,根据我的经验,在一个大型公司里,你最好有一 个统一的编码规范,特定项目可以扩展自己特定的项目方言和结构。
我善长制定编码规范!
这应该是最常见的抱怨类型了。它是其它几种反对声音的混合体,但它却有自身态度的直接表现。有一部分反对者深信,他们是比制定编码规范的人更好的 程序员,俯身屈从这些小学生制定的规范,将会降低代码的质量。对于此,客气点说,就是胡扯。纯属傲慢自大,荒唐可笑。事实上他们的意思就是,没有人配得上给他们制定规范,对他们的代码的任何改动都是一种破坏。如果参照任何一种合理的编码规范,你都不能写出合格的代码,那只能说你是个烂程序员。
当你按照某种编码规范进行编程时,必然会有某些地方让你摇头不爽。肯定会在某些地方你的编码风格会优于这些规范。但是,这不重要。在某些地方,编码 规范也有优于你的编程风格的时候。但是,这也不重要。只要这规范不是完全的不可理喻,在程序的可理解性上得到的好处会大大的补偿你的损失。
但是,如果编码规范真的是完全不可理喻呢?
如果是这样,那就麻烦了:你被糟蹋了。但这并不是因为这荒谬的编码规范。这是因为你在跟一群蠢货一起工作。想通过把编码规范制定的足够荒谬来阻止一 个优秀的程序员写出优秀的代码,这需要努力。这需要一个执著的、冷静的、进了水的大脑。如果这群蠢货能强行颁布不可用的编码规范,那他们就能干出其它很多 傻事情。如果你为这群蠢货干活,你的确被糟蹋了—不论你干什么、有没有规范。(我并不是说罕有公司被一群蠢货管理;事实很不幸,我们这个世界从来就不缺蠢 货,而且很多蠢货都拥有自己的公司。) {:smile:}标注一下 一直都没有画过,但现在文件要求需要画 以前纸上画,现在环保,心里画 主体要画流程,至少模块和功能要分清。 画还是有好处的 有时候,写文档的时间比写代码的时间多。 我也是,没画过 写选择判断的时候划一下,会比较好。
Gorgon_Meducer写过一个很好的关于状态机的帖子。可以找一找。 额,楼上跑题了
不过内容还不错 http://www.amobbs.com/thread-5542774-1-1.html
关于流程图、状态图和数据流图,参考这个帖子
页:
[1]