程序员内功要注释吗

❶ C#学习回顾笔记二：注释是什么，为什么要使用注释

1）什么是注释？

注释是在编写代码时，用于对代码进行手动文字描述的一种方式。注释还有一个用处是把暂时不需要的代码进行处理，标记为注释的文字不会被编辑器识别报错，即便是语法错误的代码只要标记注释也没有任何问题。重要：谨记“不写注释是流氓，名字瞎起是扯淡”

2）为什么使用注释？

有时候编写的代码太多太复杂时，需要对一句或者一段代码进行文字描述，用于记录代码的功能以方便以后的观察。但严格地说，编写代码时并不是注释越多越好，而是在适当的时候，适当的地方使用注释，如果是很简单的代码则不需要增加注释。

在编写一个程序时，就会写很多代码。如果不小心多按了一下键盘，就会留下一个很致命的字符。我们编写代码的环境必须要求写的代码符合编写规则。如果随意使用中文下的字符或者不注意大小写，甚至认为不小心在某个位置多写了一个字符就觉得无所谓，那么就是大错特错。

红色箭头指示的就是给Main方法做的文档注释。强调一次：注释的东西不会影响到程序的正常执行，注释只是程序员对自己代码做功能描述或补充，方便以后看懂代码或修改代码。

4）补充

最后补充在VS中常用的三个快捷键：

1.快速对齐代码 ctrl+K接着ctrl+D。在VS里编写代码有个好处是代码有时候会自动补全和对齐，但如果有时候感觉代码变乱了，可以尝试使用这个。

2.注释所选代码 ctrl+K接着ctrl+C。先选中需要注释的代码，一行或者多行，然后使用这个快捷键。相当于在选中的每行代码前自动添加//。

3.取消注释代码 ctrl+K接着ctrl+U。如果有批量被注释的代码，用此快捷键相当于去掉选中的每行代码前的一对//。

❷ 现在的公司需要的程序员要具备什么能力啊

最佳答案
作一个真正合格的程序员，应该具有的素质。

1：团队精神和协作能力

团队精神和写作能力是作为一个程序员应具备的最基本的素质。软件工程已经提了将近三十年了，当今的软件开发已经不是编程了，而是工程。独行侠可以写一些程序也能赚钱发财，但是进入研发团队，从事商业化和产品化的开发任务，就必须具备这种素质。可以毫不夸张的说这种素质是一个程序员乃至一个团队的安身立命之本。

2：文档习惯

文档是一个软件系统的生命力。一个公司的产品再好、技术含量再高，如果没有缺乏文档，知识就没有继承，公司还是一个来料加工的软件作坊。作为代码程序员，必须将30％的工作时间写用于技术文档。没有文档的程序员势必会被淘汰。

3：规范化的代码编写习惯

知名软件公司的代码的变量命名、注释格式，甚至嵌套中行缩进的长度和函数间的空行数字都有明确规定，良好的编写习惯，不但有助于代码的移植和纠错，也有助于不同技术人员之间的协作。 一些所谓的高手甚至叫嚣高手写的代码一般人看不懂，我只能说他不是一名合格的程序员。

4：需求理解能力

程序员要能正确理解任务单中描述的需求。在这里要明确一点，程序员不仅仅要注意到软件的功能需求，还应注意软件的性能需求，要能正确评估自己的模块对整个项目中的影响及潜在的威胁，如果有着两到三年项目经验的熟练程序员对这一点没有体会的话，只能说明他或许是认真工作过，但是没有用心工作。

5：模块化思维能力

作为一个优秀的程序员，他的思想不能在局限当前的工作任务里面，要想想看自己写的模块是否可以脱离当前系统存在，通过简单的封装在其他系统中或其他模块中直接使用。这样做可以使代码能重复利用，减少重复的劳动，也能是系统结构越趋合理。模块化思维能力的提高是一个程序员的技术水平提高的一项重要指标。

6：测试习惯

测试是软件工程质量保证的重要环节，但是测试不仅仅是测试工程师的工作，而是每个程序员的一种基本职责。程序员要认识测试不仅是正常的程序调试，而要是要进行有目的有针对性的异常调用测试，这一点要结合需求理解能力。

7：学习和总结的能力

程序员是很容易被淘汰的职业，所以要善于学习总结。许多程序员喜欢盲目追求一些编码的小技巧，这样的技术人员无论学了多少语言，代码写起来多熟练，我们只能说他是一名熟练的代码民工，他永远都不会有质的提高。一个善于学习的程序员会经常总结自己的技术水平，对自己的技术层面要有良好的定位，这样才能有目的地提高自己。这样才能逐步提高，从程序员升级为软件设计师、系统分析员、项目经理。

作为高级程序员，乃至于设计师而言，除了应该具备上述全部素质之外，还需要具备以下素质：

1、 需求分析能力

2、 整体框架能力

3、 流程处理能力

4、 模块分解能力

5、 整体项目评估能力

6、 团队组织管理能力

❸ 程序员的编程内功和外功有哪些如何看待编程内功和外功的关系

内功:算法设计
外功:实现能力

外功是内功表现的基础,光有外功也能打人,但是内功强了才能打死人
内功练好了,不管碰到什么兵器(语言)都能驾驭自如

❹ 看特别长的代码,连个注释都没有,各个变量都不知道它要干嘛,怎么办

不是的
一般比较规范的公司都会要求程序员在编写代码的过程中 保证变量命名简洁、有意义且最好能够自解释，比如一般会把 用户名 变量 声明为 string strUserName;，这样后面的代码阅读者能够一眼就看出这个变量表示什么。
而且 也会要求程序员书写必要的注释。

❺ 一个程序员需要有怎样的自我修养

作为一名程序员，一个“程序员的自我修养”是什么？
尽管我们不一定要像尹天仇那么的认真对待自己的事业，但，一些基本的修养，作为一名新时代的码农，总应该是要具备的吧。不过真要说修养，方面还是挺多的，技术自我提示自不必说。但我并不打算从这个大家都觉得理所当然的技术方面入手，而是谈谈，可读性代码，这个容易被大家忽视的基本素养。
1、遵从所在团队的代码规范。
一个高效、成熟的团队，必定有一个属于自己的代码规范，这个规范是团队的宝贵的财富，它是整个团队从各种坑中爬起来后积累的经验教训。什么是规范，它是人们从无数经验中总结出来的规则，标准。而代码规范，指导团队成员如何以最短的时间写成最高效，可读性强的代码。试想，如果成员不遵从规范，你用驼峰命名，他用下划线，这对程序的可读，将造成多大的影响。我想，应该没有一个人愿意去阅读一段，各种变量命名形式都能见得到，private, public 方法随意排序，甚至常量类都散落在各个角落的代码吧。
代码，一个作用是让机器阅读，另一个重要的作用是让人阅读！！！

2、遵从行业内通用的规范
在团队的代码规范未涉及到的，那请按照行业内的规范来编写代码。规范的一个好处是，可以明显减少学习和交流成本。在java中，当我们看到全大写的变量名时，我们就知道这是常量，而不需要去看注释，不需要去看代码逻辑。为什么这么迅速，因为行业里大家都习惯把常量用大写命名。但假如你用其他命名方式命名常量，比如team_nums命名常量，不仅不能让人迅速知道这是个常量，而且可能让人误会这是个变量，增加了团队成员学习和沟通成本，甚至可能误导他们。就见过一位仁兄，明明用的是工厂模式，偏偏按模版模式的命名方式来命名，问他，他说他知道这是工厂模式，但他觉得，更应该叫模版模式。。。我的天，，你这么任性，以后还能做朋友么?
举个例子，我们需要根据支付类型，来生产多个支付产品，于是，我们写了个工厂类，命名为FactoryPay。当其他人看到一个类叫FactoryPay，他们会猜测，这应该是个工厂类，负责生产各种支付产品的工厂，然后按照这个猜测去阅读代码，就能比较快速的理解整个类的作用。但是，假如我取名PowerPay，别人还不知道是啥，看了半天，才明白，这是个工厂的作用。这就明显增加了他人的学习成本和维护代码的成本。

不管你是新手还是老鸟，务必了解施行行业规范，切勿为了标新立异而违反规范。这么低端的装逼，就没必要采用了，要装也写个高端的框架来提升逼格呗。

3、变量、方法命名要能表达变量作用
在程序员这个圈子很久了，就发现，程序员这货，都喜欢这套，“这个接口干嘛用的，有文档么”，“自己看代码去”。很多时候都是一脸黑。
尽管程序员阅读别人代码技术都是一流，不管你是有没有注释，不管你是怎么循环嵌套，也不管你是怎么命名，他们都能耐心的，把代码分析个所以然来。但，对于程序员这个视时间宝贵如生命，分分钟都能创造几百万价值的群体来说，您行行好，给我们省点时间吧，把变量是干啥用的，说清楚呗，没准节省的这几分钟，多赚个几万，还能请大家出去嗨呢。
每每看到部门的某大神，用一个神一般的变量名“flag”，我就有吐血的冲动，他还这个flag一直雪藏，不用，只是传递到第n个方法才使用，顿时心力交瘁，我的天，这个flag都是是干嘛用的啊，后来才明白，是isPay的意思，用来标识用户是否支付成功了。当时一口老血吐屏幕上，心里狂吐槽，老兄，你命名个isPay会死么，我的脑细胞这么不值钱么。到后来看到，去魔法数字，用int NUM_7 = 7,而不是MAX_MEMBERS来表示最大成员、用x y z来命名变量名，各种只有作者，或者作者后来都忘了的独特命名方式，都见怪不怪了。更有甚者，一个变量命名为passed，作用居然是“未通过”的意思，当时就石化了，作者还真是用心良苦，这都要考我细心不细心。
一个好的变量名，能帮助阅读者了解变量的作用，也辅助了对整段代码的理解。

4、不要show英语，乡下的孩子伤不起唉
LZ所在的团队，英语一直都是团队的硬伤，但总是能看到，某位仁兄，加上大把大把的英文注释，有些变量名也取些高大上的复杂的英语单词。敢问，你这么高的逼格，以后我们怎么和你玩啊。(那位仁兄其实就是LZ，年轻时唉，罪过罪过)
代码是用来沟通的，传递作者意图的，都看不懂，怎么沟通交流。建议英语好的童鞋，英语能力可以放到阅读英文书籍中展示，在代码中，如果团队英语能力很弱，避免使用英文，变量命名也尽量按照团队英语水平来命名

5、添加必要的注释
正如上面LZ说的，经常遭遇“你仔细看看代码，就知道干嘛用的”这样的神回复。尽管阅读代码是每个程序员的强项，但必要的注释，比如逻辑比较复杂的地方，添加必要的注释，对提升团队成员阅读熟悉代码的效率是有很大帮助的。试想，一个类，几百行，没有一行注释，对于阅读者来说，阅读它将是一个多么恐怖的事。

6、注释保持简洁，避免没有必要的注释
即看过一行注释都没有的代码，也看过注释比代码还要多的程序。一个是让人生不如死，一个是让人痛不欲生。(唉，有时不仅感叹，在程序员界混，真的是难)。
LZ就经常看过，一大段注释，啰嗦了半天，要不就是没表达清楚重点，要不就是只为说明它是个循环的作用！！！譬如i++这样的代码，有必要加个“每个计数增加1”这样的注释么，这完全是把读者定位为非程序员啊，或者就是严重鄙视读者的编程水平。
注释是帮助阅读的人更好的理解程序的逻辑，只是辅助，如果不重视通过命名等方式来传递代码的作用，而是依赖于注释，这就是本末倒置了。而且，冗长啰嗦的注释，这到底是帮助人理解，还是阻碍人理解啊，是读程序还是读小说啊。

7、拥有自己的编码规范
规范是为了让团队更快的理解、熟悉代码的，同理，拥有自己的一套规范，就能帮助其他人更快的理解我们所写的功能，减少学习和沟通成本。

8、代码清晰简洁的表达出作者的意思
在我们每次写完一段代码时，一定要问问自己，代码是否表达清楚了我的意思，是否需要添加些注释，名字取得是否恰当了，别人在阅读时是否吃力。。每每看到别人一团糟的费解的代码，就时刻提醒自己，一定要把代码写好咯，我也确实是这么做的，一遍又一编的检查，看变量名、方法名是否表明了它的用途，是否有些不必要的、只是为了提升逼格的代码，别人是否能在短时间内看懂。所有的这些，只是为了写出一段更优美的代码。

9、坚持并捍卫上面的准则
经常能听到，有些公司是代码行数来定义绩效的，但作为一个有操守，并秉承基本自我修养的程序员，我们绝不能为了各种诱惑或者胁迫，甚至是自己的惰性、个性，而放弃写出简洁清晰，可读的代码。

以上的几点，并不是严格的意见或者建议，只是提醒广大程序员同胞们，在痴心与高端的技术时，千万不要忘了，代码不仅机器要阅读，人也需要阅读。就算你写出再复杂的代码，但它让人完全无法阅读，这有什么用呢。这就如同，你很牛逼很牛逼，但别人听不懂你说的话，还不是没用。如果你真的写出了可读性强的代码，但你也不应该鸣鸣得意，我觉得，写出一段优美，健壮，可读性高的代码，是一个程序员最基本的自我修养。

❻ 程序员在写代码的时候，为什么要在代码旁边写汉字

写的字是代码注释

通常写代码的时候思如泉涌，一下逻辑通了就突突突的写，完全停不下来，但是激情释放过后呢，一开始跑代码有可能就会遇见问题，如果遇见问题了那么就只能回去重新梳理，但是如果没有注释的情况下许多东西能难一秒理解，并且很难懂一些关键节点，所以用我们熟悉的汉字标注一下就更容易理解了，理解了这些东西之后能更快处理问题，也方便日后升级改造时更快的处理，如果没有注释那可能几个月之后你就会忘记这里的含义，重新修改的时候就会困难重重。

❼ 我用C语言写程序，不加注释可以吗求解

当然可以了，注释是不影响c程序执行的，而且即使你加了注释，在生成Release版程序时，注释什么的也会被删掉。 当然，在Debug程序中不会被删掉。只是建议你还是要在关键位置加上注释，方便以后读写和理解嘛。

❽ “程序中的注释部分可有可无，通常可以省略”判断和原因

错。现在编程绝对不是一个人的事，要想其他程序员能看懂你的代码，就必须要求有注释，否则一个程序中大量的变量和函数将不知道代表是什么含义。所以不能省略。

❾ 程序员为什么不写注释

真正的程序员从来不写注释，难写的程序必定也难读。
真正的程序员不写应用程序，他们直接从最底层的裸机开始编程。
真正的程序员他们认为应用程序编程是那些不会系统编程的人干的活。
真正的程序员不画流程图，流程图是没文化的人的文档，居住在山洞里的人才在岩壁上画流程图。
真正的程序员不读手册，依赖手册是无知和懦弱的表现。
真正的程序员从不一次做对，他们可以连续30个小时坐在机器前面给程序打补丁。
真正的程序员从不按早9晚5的生活过日子，如果你在早上9点看见一个程序员，那一定是他一夜未眠。
真正的程序员比用户还清楚用户需要什么。
真正的程序员喜欢兼卖爆米花，他们利用中央处理器散发出的热量做爆米花，可以根据米花爆裂的速度听出正在运行什么程序。