python初學者不要過度沉迷於技巧

如果過度使用一句話代碼，會造成團隊協作困難，代碼是讓人讀的，讓機器執行。

google 有一名工程師寫道：write Python code like it was C。要注意代碼採用的演算法的時間複雜度，要寫可讀性好的代碼。

零基礎編程者，重要要訓練自己的解決問題的方法，切記不要過早或過度沉迷於一句話代碼。

以下文章來自Tech Notes: Complexity is the enemy

Complexity is the enemy

Im almost through my seventh year working at Google(!). I have learned many things there, more than I could ever write down. I thought I would at least share with you something thats only come to me with more experience.

Complexity is the death of software. Its hard to quantify the cost of, and it tends to creep in slowly, so its a slow boil of getting worse thats hard to see until its too late. On the other side, frequently its easy to see a benefit of increasing complexity: a new layer of indirection allows new feature X, or splitting a process that ran on one machine into two allows you to surmount your current scaling hurdle. But now you must keep another layer of indirection in your head, or implement an RPC layer and manage two machines.

The above is hopefully just as obvious to a new programmer as it is to a veteran. What I think Ive learned through my few years in the industry is a better understanding of how the balance works out; when complexity is warranted and when it should be rejected. I frequently think back to a friends comment on the Go compiler written by Ken Thompson: its fast because it just doesnt do much, the code is very straightforward.

It turns out that, much like its easier to write a long blog post than it is to make the same point succinctly, its difficult to write software that is straightforward. This is easiest to see in programming langauge design; new languages by novices tend to have lots of features, while few have the crisp clarity of C. In todays programs its frequently related to how many objects are involved; in distributed systems its about how many moving parts there are.

Another word for this problem is cleverness: to quote another one of the C hackers, "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

What helps? I wonder if it maybe just comes down to experience — getting bitten by one too many projects where someone thought metaprogramming was cool. But Ive found having specific design goals to evaluate new code by can help. Its easier to reject new code if you can say "this does not help solve the initial goals of the project". Within Google the template document for describing the design of a new project has a section right at the top to list non-goals: reasonable extensions of the project that you intend to reject.

Ironically, Ive found that using weaker tools can help with complexity. Its hard to write a complicated C program because it cant do very much. C programs tend to use lots of arrays because thats all you get, but it turns out that arrays are great — compact memory representation, O(1) access, good data locality. Id never advocate intentionally using a weak tool, though. Instead, my lesson has been: write Python code like it was C.

推薦閱讀：