分功能，对个别软件处理要做注释，这样不仅方便你下次看注释的时候知道自己当初为什么这么做，有时候自己写的代码也会因为耗时太长而忘记。注释也便于其他人阅读和理解代码。最后，对于程序员来说，修改他们现有的代码，或者对于团队来说，定期进行评审是有意义的，但是在大面积重写代码时，尤其是重写别人的代码时，一定要谨慎。
为什么有人说写代码前要多写注释来设计代码呢？
这就涉及到公司编码规范了，有的公司要求程序员写的代码小到每行要有注释，不过对于软件开发人员来说这也太浪费时间了。一般大多数公司要求软件开发人员在定义每个函数，每个功能模块要有注释，比如，定义实现一个函数，那你就要注释下这个函数的输入输出参数名称及含义，实现功能，划分到函数里面，对于个别软件处理要做注释，不仅方便自己下次一看注释就知道当初是为什么这么处理，有时候自己写的代码，由于时间太长，也会遗忘的，有注释也方便别人阅读理解代码。
说完函数，我们就说实现这个功能的文件注释，一般项目一个大的功能，比如组件或者子功能模块，一般放到一个文件，比如xxx.c,xxx.h等，在定义这个文件开头就应该注释这个xxx.c实现的功能，开发人员，时间等。总的来说，代码注释是软件开发人员良好的编码习惯，项目代码易于维护，这样项目更换开发人员，也不至于刚接手的人一看没有注释的代码而一头雾水，
为什么说读代码比写代码难？
读代码，是理解源程序风格，熟悉业务逻辑的一个艰难过程。读代码这一步成功了，意味着能适应新的开发工作；如果两、三年都整不明白，建议另做打算，之所以叫一些程序员为”菜鸟”，不是因为他们对编程语法不熟悉，更多的是因为他们对业务逻辑很陌生。凡有一定基础的公司，招聘的新程序员，第一件事，就是读懂程序，熟悉业务逻辑，从而改进及增加功能，
有的编程人员在一个新公司干几个月，要么自己辞职，要么被公司强制辞退。很大程度上与业务逻辑有关，搞不懂这个程序的服务对象，各功能之间的关系。把别人的源程序看的似懂非懂，到处瞎改一气，结果一测试，问题越来越多，越来越搞不懂，对新招聘的编程人员，在两年之内，只做辅助工作，阅读程序，不安排主流开发工作。我们公司在十几年前，招过一个单片机开发工程师，让他负责一小产品的单片机汇编语言的维护工作，目标代码40KB稍多，
大致看了两周时间，他认为很明白了，开始做用户反馈问题的维护工作。一个月后，他认为改好了，公司安排人把相关功能测试了一下，认为OK，软件下发，给新加坡的用户升级。一周后，用户反馈来了，问题写了二十多项，我们都很惊讶，原先用户只有一个问题，给这家伙一改，变成了二十多个。用户直喊退货，受命危难之秋，我直接上手检查。
用了两天时间，终于整清楚，本该按位进行ORL或有ANL的地方，他一概用MOV，这块写对了，把别的标志位全改了，这就导致了简单测试时一点问题没有；在用户处，经常使用很多功能选项，问题就出来了。从这以后，我们加长新同志打杂的时间，争取水到渠成，总结：不同公司，不同行业，要很好地工作，首先要对业务逻辑很熟悉。
女朋友因为我沉迷写代码离家出走，应该写完代码去追还是现在就去追？
代码诚可贵，爱情价更高，为了真自我，两者皆可抛，这兄弟一看就是个理工直男，首先你如果继续沉迷于写代码，女朋友肯定是没戏了。况且程序员的工作性质，决定了你将来除了累就只剩下加班了，这样紧张状态下埋头过一生，没有自己的时间，没有自己的生活你愿意吗？赶紧起来抄起凳子把电脑砸了吧，砸完后女朋友你也不用追，以你理工男直男的性格追回来也守不住，女朋友需要的是你的温柔、你的浪漫。
学习编程是不是要多敲代码？
所有优秀的狙击手都是靠子弹养活的。学编程不像武侠小说里那样——你转身，背对师傅，师傅甩你一手。一缕青烟飘过，你瞬间拥有了大师70年的内力(题外话，大师放心离开)。其实真正的武术也是夏天练，冬天练。俗话说，歌不离口，拳不离手。写代码也是如此。一个可以熟悉语法，一个可以通过多打代码锻炼语感。但是请记住，不要只是一个代码搬运工，
