工作中，你是否遇到过不守“码徳”的程序员，他们的代码从来不讲究规范性。比如不规范命名，直接用a、b、c等字母来命名，回溯代码总会一头雾水；比如调用API时，不讲究入参结构一致，出参结构一致，在编写调用API的SDK时，麻烦重重。本期就来讨论下，程序员有哪些约定俗称的“码徳”。
本期话题：
1、程序员有哪些约定俗成的“码徳”？
2、你觉得哪些不规范的编程行为最让人头疼？
本期奖励：
截止9月20日24时，参与话题讨论的有效回答（6名），将有机会获得吨吨桶*1。
获奖规则：参与话题的首位回答，以及中奖楼层百分比为3%，13%，33%，63%，83%的有效留言用户可获得互动幸运奖。 如：活动结束后，回复为100层，则获奖楼层为100 3%=3，依此类推，即第3、13、33、63、83位回答用户获奖。如遇非整数，则向后取整。如：回复楼层为80层，则80 13%=10.4，则第11楼获奖。
注：楼层需为有效回答（符合互动主题），灌水/复制回答将自动顺延至下一层。话题讨论要求原创，如有参考，一律注明出处，否则视为抄袭不予发奖。获奖名单将于5个工作日内公布，礼品7个工作日内发放，节假日顺延。
本期有效活动时间内共收到99个回答，根据抽奖计算，获奖名单是：张志凌、Benz、huc_逆天、游客fwdadgun2o33i、1941623231718325
首答获奖名单：lovelydong
程序员有一些约定俗成的“码徳”（编码道德），这些主要是关于代码的可读性、可维护性和效率的。以下是一些常见的约定：
可读性：保持代码清晰易读。使用有意义的变量名、函数名和类名。避免使用只有一两个字母的抽象名称。代码注释应准确、简洁，描述代码的功能和意图。
可维护性：代码应易于维护。避免过度的复杂性，将代码分解为小模块和函数。遵循设计模式，以便将代码逻辑清晰地映射到现实世界的问题。
效率：在保持可读性和可维护性的同时，尽可能提高代码的执行效率。这可能涉及选择正确的数据结构、算法和编程语言，以及优化关键代码段。
兼容性和错误处理：编写的代码应尽可能兼容不同的平台、框架和版本。同时，应考虑错误处理，以防止程序在遇到错误时崩溃。
安全性：保护用户数据，避免潜在的安全漏洞，如SQL注入、跨站脚本（XSS）等。
持续学习和改进：由于编程技术和工具不断变化，程序员应持续学习新的技术和最佳实践，以提高他们的编码技能。
以下是一些不规范的编程行为，这些行为可能会让人感到头疼：
不恰当的命名规则和风格：这可能导致代码可读性变差，增加后期维护的难度。例如，使用非描述性的变量名或函数名。
过度的抽象和复杂性：过度使用复杂的编程模式或者过度将代码拆分为小的函数或类，使得代码难以理解和维护。
不恰当的错误处理：不处理可能会引发错误的操作，或者在程序崩溃时没有提供恢复机制。
不充分的测试：没有全面的单元测试和集成测试，导致问题在代码部署后才发现。
冗余和重复的代码：复制和粘贴代码而不是重用和抽象，使得代码难以维护，且可能引入错误。
没有注释或者文档：缺乏注释和文档使得其他开发者难以理解代码的功能和意图。
不考虑性能和资源管理：写出的代码不考虑执行效率和资源管理，可能导致程序运行缓慢或者消耗过多的系统资源。
作为程序员，遵守以下的 “码德” 是常见且被普遍遵守的：
代码规范：程序员应该编写具有可读性、可维护性和可扩展性的代码。这包括遵循适当的缩进、命名规范（如驼峰命名法）、注释规范、代码结构等。
不复制粘贴：程序员应该避免复制粘贴代码，而是尽量重用代码块或创建可复用的函数或类。
测试与调试：程序员应该编写适当的单元测试来验证代码的正确性，并在出现问题时进行调试。他们应该在提交代码前进行测试和调试，以确保代码的质量。
版本控制：程序员应该使用版本控制系统（如Git）来管理代码，并定期进行代码提交和拉取最新的代码更改。
开放沟通：程序员应该与团队成员、项目经理和其他相关人员进行开放和及时的沟通，分享他们的进展、问题和需求。
尊重他人代码：程序员应该尊重他人的代码，不擅自修改或删除其他人的代码。如果需要更改他人的代码，应该先与他们进行沟通并获得许可。
安全和隐私：程序员应该遵守安全和隐私规则，确保代码和数据的安全性，并尽量最小化对用户敏感信息的收集和使用。
持续学习：程序员应该积极主动地学习和掌握新的技术和工具，以提高自身的技能和知识水平。
总的来说，“码德”强调的是程序员应该遵守职业道德和良好的行为规范，以建立高质量的代码和积极的工作环境。
您提到的这些问题在实际工作中确实较为常见,我觉得程序员应该遵守的一些“码德”包括:
我觉得最让人头疼的行为主要有三点:
如果团队达成命名、规范、文档等编码约定,并形成良好编程习惯,可以大大提升协作效率和代码质量。希望大家共同提高,使编程成为一种享受。
一：
尊重代码，
保持可维护性，避免冗余，保持可测试性，避免全局状态，尊重数据
二：
不良的代码风格，没有注释和文档，不使用版本控制，没有单元测试，不考虑可扩展性
高内聚 低耦合 分层设计 写好注释
程序员的“码德”是指程序员在工作中应该遵守的一些基本准则和道德规范。这些准则和规范包括但不限于：
1. 诚实和诚信：程序员应该诚实地报告工作进展和问题，不夸大或隐瞒信息，以保持透明和可信赖。 2. 隐私保护：程序员应该尊重用户的隐私，不泄露用户的个人信息。 3. 代码质量：程序员应该写出高质量的代码，遵循编码规范和最佳实践。 4. 合作精神：程序员应该与同事合作，共同解决问题。
1、程序员有哪些约定俗成的“码徳”？
变量名通俗易懂，代码写注释
2、你觉得哪些不规范的编程行为最让人头疼？
各种嵌套，穿插引入重复代码
1.驼峰式命名或者下划线命名，别用拼音！
2.注释！注释！注释！
3.符号（=、;、+等）前后加空格
4.对齐！
用拼音命名变量
这些人自以为很多人用便是对的，学习洋文是可耻的，使用的方法是有序的
殊不知拼音的重码率和英文单词完全不是一个级别
当然如果都用首字母简写的话，那不管用拼音还是英文，没注释清楚的都是答辩
不能写只有自己能看懂的代码，完毕。
程序员的约定俗成的”码德”包括：
不规范的编程行为包括：
这些不规范的编程行为可能导致代码难以理解、维护困难，影响团队合作和代码质量。
程序员约定俗成的“码德”如下：
我觉得让人头疼的不规范的编程行为有：
一名合格的高级码农应该有以下的码德①一定要认真写好注释，②命名一定要规范，③千万别冗余的代码写一大堆④代码能跑就行，千万别乱改。
首先就是得写注释，这不用说了。
其次就是代码里要调用公共写好的API，而不是像部分工程师说你搭建的框架不好用我用我自己的而导致代码一个人写的一个样。
还有就是最好写好一个功能提交一次代码，我记得我部署的时候最怕的那个工程师了，临近发版前一次性提交所有代码，大多数时候都是因为他出的事故。
在还有一点就是不要用a，b，c做变量名，这真的很重要。
一定要写注释！！！
不写注释最让人头疼！！！
你觉得哪些不规范的编程行为最让人头疼？
1缺乏注释和文档：编写缺乏注释和文档的代码会给其他人阅读和理解代码带来困难。良好的注释和清晰的文档可以帮助团队成员更好地理解代码的意图和功能。
2长而复杂的函数和方法：长而复杂的函数或方法难以理解和维护。拆分功能，并使用适当的命名和代码结构，可以提高代码的可读性和可维护性。
以下是一些常见的编程“码德”：
不规范的编程行为会导致代码难以理解、维护和扩展，给其他程序员带来很大的麻烦：
1.认真写好注释
2.命名一定要规范
3.千万别冗余的代码写一大堆
4.代码审核或者技术交流时要谨慎发言,不要一副高高在上的样子,别人给你看代码相当于脱了裤子了,吸取长处不要贬低他人
程序员的码德个人总结以下几点：
1、不抄袭别的的代码作为自己的原创作品
2、写代码不留后门
3、不做删除跑路的事情
4、遵纪守法，不利用程序员技能做不道德的事情
5、不对别人的代码评头论足
6、乐于助人、乐于分享
7、等等
实际上所谓的“码德”，无非就是一些基本道德常识的延生罢了。所有的基本道德，大多数人在幼儿园都已经学到过，只需要在工作上表达出来就行。我观察有以下几个(non-inclusive)1. 追求协同协同是代码库的本质。如果没有协同的话，直接用带磁的小刀在硬盘上刻出天书就行了。在协同的原则下，有可读变量名，良好的注释等等代码层面的东西，也包括送出代码审查前充分沟通等等一些基本的礼仪。为了协同，不要追求花哨的技巧，因为花哨技巧需要更多的时间去理解和沟通。这方最好的书是 “The Elements of Programming Style”，可惜已经绝版。2. 诚实我以前遇到的一些程序员技术不错，但总不愿意承认有些代码设计上的缺陷，或者拒绝其他人在自己代码上得改进。在我看来这是不诚实的。还有一些程序员喜欢说“或许”，而不想诚实的承认自己不知道。要知道“或许”可能会把决策者带到沟里面。诚实这一点许多人从幼儿园开始就做不到，当了程序员也做不到。3. 接受现实(或者说接受代码无常这个现实)世界总是在变的，代码也是。为了对付这种变化，文档不求详细但要和代码同步，测试不求覆盖多么高但关键的测试要有。Bug 来了第一反应不是否认或者说这个问题肯定和我无关等等。做到了以上三点的，一定是德艺双馨的。我常常看到有些程序员职业生涯遇到瓶颈，不是智商不高不能在技术上更上一层，而是道德不能支撑更高技术岗位的要求。