一个偶然机会自己参加一个面试，问到什么是优秀代码？针对这个问题我的回答给出两条：可读性和可继承性。不知道当时面试官是怎么考虑我的回答的，可能对我的回答嗤之以鼻，工作十年之久连什么是优秀代码都不知道。自己回来之后反复琢磨和查找网上资料。我琢磨后给出的答案还是1. 可读性；2可继承性；3高内聚低耦合。但是通过我反复查找资料可以总结如下，优秀代码需要具备如下特征：
1. 满足基本需求。再优秀的代码也是为项目服务的，首先就是满足需求，针对需求编写符合需求的代码，满足功能、性能、时间等客户需求，这样才能称得上是合格代码。
2. 易读性。遵循命名规范，针对变量、函数、类等友好易懂的命名规则。
代码命名规范：
1)、 package包名全部由小写的ASCII字母组成，用“.”分隔。在此项目中，所有的包均以“com.abc.ticket”开头。
2)、 class 类名应当是名词，每个内部单词的头一个字母大写。应当使你的类名简单和具有说明性。用完整的英语单词或约定俗成的简写命名类名。
【示例】public class UserManager
3)、 interface接口名应当是名词，每个内部单词的头一个字母大写。应当使你的接口名简单和具有说明性。用完整的英语单词或约定俗成的简写命名接口名。
【示例】interface TicketManagement
4)、 Class 成员属性及变量的命名 (*) 变量名全部由字母组成，头一个字母小写，以后每个内部单词的头一个字母大写。变量名应该短而有意义。变量名的选择应该易于记忆。一个字符的变量名应避免，除非用于临时变量。通常临时变量名的命名规则为：i，j，k，m，n用于整数；c，d，e用于字符。
5)、常量的命名，Java 里的常量，是用static final 修饰的，应该用全大写加下划线命名，并且尽量指出完整含义。
【示例】static final String SMTH_BBS="bbs.tsinghua.edu.cn";
6)、数组的命名，数组应该总是用下面的形式来命名：byte[] buffer;
7)、方法的参数和变量的命名规范一致，且应使用有意义的参数命名，如果可能的话，使用和要赋值的字段一样的名字。
【示例】setCounter(int size){ this.size = size; }
8)、 方法命名(*)方法的命名应当使用动词，头一个字母小写，以后每个内部单词的头一个字母大写。在方法名的选择上应意义明确便于记忆。对于属性的存取方法，应使用getXXX()和setXXX()名称，以isXXX()，hasXXX()来命名返回值为boolean 类型的方法。
以上几条如果符合就算是好代码了吗？当然不是，这只是代码中最基本的命名规范而已，就算不符合最多就是代码不好看，没什么其他影响。
代码逻辑规范
1)、需求、设计中的重点功能（结合需求/设计的评审产出）
2)、代码格式校验
action/façade等系统入口是否有数据格式校验
需要存入数据库的数据字段是否有长度校验
3)、分支/循环
if-else/switch是否处理了所有分支
分支的条件语句是否有“副作用”；即，条件语句是否会改变系统状态/数据等
循环边界是否覆盖了所有元素
是否有死循环等
4）、异常处理
是否有“吃掉异常”的情况
是否记录了异常日志
如果二次抛出，是否有合理的异常层次/结构
如果内部处理，对异常的处理是否能保证后续代码正常运行
5）、单元测试
是否有单元测试
单元测试是否自动化
单元测试是否能完整覆盖需求
6）、 事务处理
事务范围是否合理；或者说，是否把不必要的操作放到了同一个事务中
事务传播方式是否合理（required，never，new等配置）
7）、sql语句
sql语句是否正确
使用mybatis的动态语句时，是否有潜在的sql语法问题
8）、第三方组件
使用Redis，RabbitMQ等组件，是否真的对组件完全了解，在使用的过程中是否正确执行了开启与关闭操作。
3. 可继承性。代码重用性，根据新的功能不用修改目前代码或是很少修改吧所需要的功能添加上去。
，
5. 可测性、可配置性和已修复bug。把所设计的代码根据功能进行，尽量少的bug。项目模块化，根据模块的配置进行项目的组装，成为新的项目。
关于其他方面的说明定义：
'Good code' is code that works, is bug free, and is readable and maintainable. Some organizations have coding 'standards' that all developers are supposed to adhere to, but everyone has different ideas about what's best, or what is too many or too few rules. There are also various theories and metrics, such as McCabe Complexity metrics. It should be kept in mind that excessive use of standards and rules can stifle productivity and creativity. 'Peer reviews', 'buddy checks' code analysis tools, etc. can be used to check for problems and enforce standards.
另外，来自 MSDN END BRACKET 栏目的作者 Paul DiLascia ，也列出了优秀代码应有的物质：不管你用什么语言进行开发，所有的优秀代码都会展示出共有的经典品质：简练，易于理解，模块化，层次性，设计良好，高效，优雅，并且清晰。