这么题目看起来就比较有争议：运行起来专业的代码才专业嘛。但是从另外一个角度来说"让代码看上去比较专业"是一个积极的做法，无论对谁都没有坏处，对工程师，管理者和用户都有益无弊。
首先这个题目说的是"看上去",所以我不会说明如何使代码真正专业。世界上有很多的书籍和文章告诉软件工程师如何写出专业的代码。如果要说"什么样的代码看上去比较专业？"那就要定义什么是专业的代码。嗯，关于这点我不能下一个准确的定义。那么可以这样，大家可以参考一些大家共认的专业代码。对于Java JDK代码来说几乎没人会否认它是专业的代码。或者一些很有影响力的open source代码，像Spring 和Apache 的代码。当然很多商业软件的代码也是很专业，但是我们看不到，或者说这不是共认的专业代码。进一步说，所有的编程语言都可以看起来比较专业，我这里就以Java为例来做说明。
•最显而易见的做法是充足的代码注释 和标准缩进 的格式。但是大家一致认为这是最明显的因素。
•然后是命名规范 。有人曾经在网上展示自己的一个framework的代码,framework自然是很牛的东西。但是接下来马上有人回帖"我一看到大写开头的方法名，我就没兴趣了"。这是个很典型的例子。
命名规范里面用拼音 做包名，类名，方法和变量名字也会使代码看上去感觉比较差。我说的是代码，不是注释。
•还有就是要用最新的语言特性 。对于Java,譬如要用Annotation, Generic。虽然这些特性已经出现很多年了。至少要用@Override 一下吧。我知道大家知道用Annotation, Generic的真正的益处。
•尽量不要用Magic number 。如果一看到到处都是"id".equals(...); if(i==356). ..大家就会感觉不好。
•还有就是最好包含单元测试 的代码，JUnit 已经成为Java的公认单元测试工具。很多开发人员认为对于一个严肃的程序，单元测试是必需的。
•避免冗长的方法和类。我知道大家深受其害。
其实我认为"看上去"专业能促进代码质量。充足的代码注释和标准缩进的格式能增强可读性，另外在撰写注释的时候也是在"拷问"自己的代码，如果你觉得某个方法的注释很难写，那就要问问自己的这个方法的代码逻辑写得够不够清晰。有时候在注释方法的@throws XXXException 的时候，你才会仔细考虑哪些Exception会在什么情况下被抛出。@Override 能够避免低级打字错误。Generic容器比较安全等等。
从代码演变的角度来说，有个明显的"破窗理论"在起作用。就是越是难看的代码，在它的演化过程中会越来越差。因为当你看到你要bugfix的代码很乱，那么在bugfix的时候一般也会草草了事。一个方法有400行，在修改这个方法的时候大家不会在意再加上几十行代码。因为它看起来很差，它就是很差，我没必要美化它。反过来说，如果待改的代码很整洁很规范，那么修改者也会比较小心。这不是绝对，只是一般情况。一定有很帅的工程师把很难看的代码改得很整洁，也一定有很无畏的工程师在很好的代码上面乱改，这就是生活:)