主题：【推荐】大师谈程序！ -- Highway
Paul DiLascia 是一位资深程序员，近十多年来为MSDN杂志C/C++专栏写了很多好的文章。他在Web开发，程序设计功力不浅，让我们姑且称他为“大师”！
[SIZE=3]What Makes Good Code Good? [/SIZE]
[QUOTE]When MSDN Magazine asked me to write a page on something I care about, I said, "You mean, like abolishing taxes, car phones, and SUVs?" Alas, they meant something to do with programming. Well! After pondering, I realized that something I care about is writing good code. Books and magazines spare no space explaining how to program the latest API or marshal objects from Redmond to Zwaziland, but how to write good code? What is good code, anyway?
A good program works flawlessly and has no bugs. But what internal qualities produce such perfection? It's no mystery, we just need some occasional reminding. Whether you code in C/C++, C#, Java, Basic, Perl, COBOL, or ASM, all good programming exhibits the same time-honored qualities: simplicity, readability, modularity, layering, design, efficiency, elegance, and clarity.
Simplicity means you don't do in ten lines what you can do in five. It means you make extra effort to be concise, but not to the point of obfuscation. It means you abhor open coding and functions that span pages. Simplicity―of organization, implementation, design―makes your code more reliable and bug free. There's less to go wrong.
Readability means what it says: that others can read your code. Readability means you bother to write comments, to follow conventions, and pause to name your variables wisely. Like choosing "taxrate" instead of "tr".
Modularity means your program is built like the universe. The world is made of molecules, which are made of atoms, electrons, nucleons, quarks, and (if you believe in them) strings. Likewise, good programs erect large systems from smaller ones, which are built from even smaller building blocks. You can write a text editor with three primitives: move, insert, and delete. And just as atoms combine in novel ways, software components should be reusable.
Layering means that internally, your program resembles a layer cake. The app sits on the framework sits on the OS sits on the hardware. Even within your app, you need layers, like file-document-view-frame. Higher layers call ones below, which raise events back up. (Calls go down; events go up.) Lower layers should never know what higher ones are up to. The essence of an event/callback is to provide blind upward notification. If your doc calls the frame directly, something stinks. Modules and layers are defined by APIs, which delineate their boundaries. Thus, design is critical.
Design means you take time to plan your program before you build it. Thoughts are cheaper than debugging. A good rule of thumb is to spend half your time on design. You need a functional spec (what the programs does) and an internal blueprint. APIs should be codified in writing.
Efficiency means your program is fast and economical. It doesn't hog files, data connections, or anything else. It does what it should, but no more. It loads and departs without fuss. At the function level, you can always optimize later, during testing. But at high levels, you must plan for performance. If the design requires a million trips to the server, expect a dog.
Elegance is like beauty: hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion―which is almost always elegant:
int fact(int n)
{
return n==0 ? 1 : n * fact(n-1);
}Clarity is the granddaddy of good programming, the platinum quality all the others serve. Computers make it possible to create systems that are vastly more complex than physical machines. The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all time-honored ways to achieve clarity, which is the antidote to complexity.
Clarity of code. Clarity of design. Clarity of purpose. You must understand―really understand―what you're doing at every level. Otherwise you're lost. Bad programs are less often a failure of coding skill than of having a clear goal. That's why design is key. It keeps you honest. If you can't write it down, if you can't explain it to others, you don't really know what you're doing.
There's so much I've left out, but there's one more thing I hesitate to add. Use it sparingly and only in desperation: the clever hack. The clever hack is when you sacrifice your principles to expedience. When you hardcode some condition or make a call up the layer cake―or commit some other embarrassment―because it works and there's no time to do it right. But remember: it must be clever! It's the cleverness that redeems the hack and gives it a kind of perverse elegance. And if the hack doesn't work, don't blame me! Happy programming![/QUOTE]
highway 不要码人噢
这些大道理自然是对的，不过问题在于同时满足这些大道理实在是难，以至于很多程序运行性能不佳，就像用非常彻底的面向目标方法设计出来的程序往往性能都很成问题一样。
现实中的软件开发和教科书经常是不一样的，对这些大道理所作的修改其实很简单，就四个字：“保持平衡”，可是要真地做到这四个字，却需要多年的功力。
1）适当的Bug。如果你delieve了Perfect code。那你很快就会被忘记。应为everything runs great, people will forget about you very soon。所以写一些小的bug,这样人们会不时地找你来，你才会显得重要。如果你的bug太多了，那也不行，人家火了，会让你走人的。
2）没有Comments.不要有consistent naming convention。你的程序不能让别人读懂。否则你就可有可无了。最好是只有你能看懂自己的程序。如果过一段时间连你自己也看不懂了，那你就过头了。
。。。。。。。( 3,4,5,6 恕我不能奉告）
For the sake of job security，you must do it!!!!
其实这要看是什么样的位置了：
如果是维护性为主的位置，必须按照你说的方法去做，否则那十八字真言必将兑现。
如果是算法实现类的位置，Bug不能够太多，否则QA会很关心你的，但是程序一定要难读，注释一定要齐全，但是一定要和程序的关系不是太密切，反正没有人会认真读注释的。
如果是设计类工作，代码一级可以尽可能地准确，文档可以详细，但是设计部分的文档则应该适当模糊，以防止那十八字真言的兑现。
深得厚黑二字真诀。
猪八戒就是这样练成滴。
不开玩笑了。
其实也没有什么，职场就是战场，从业人员也就是战士，不仅需要尽可能地消灭敌人，而且还需要尽可能地保护自己，特别是要注意来自背后的黑手。
......
2、限量发贴的措施暂时不实施。但是保留在任何时候紧急限量【青史微言】和【观点时事】版面。最终也会全面实施这个规则。
......
引自:
http://www.cchere.com/article/194503
开开老兵玩笑, 别见怪~
术语叫obfuscation
就是把好好的程序无缘无故搞乱，功能一切正常，但谁也读不懂。
这样，就可以自己维持一个干净的版本，方便自己编程和维护；交给上级的却是乱码版。只要程序还有维护的需要，相信谁也不敢把你解雇。hiahia
什么是好程序和我们怎么写是两回事。其实我们心里都清楚什么是neat code.
说实在的，现在你写的很好的code又怎么样呢？
像样的公司，通常会有Code Review，在你Check In之前，先把代码给同事检查，同意后，才交上去。
想做手脚? 老板才精呢!
据说，还是美国的IT最好混日子。不知道是不是这样?
就写写自己的几份工作吧。
没去过美国，不知美国的IT那边如何。