此文章僅做為基本入門參考 :)
這次是第二次專案開發的課程
不過可以確信的是我的工程數學應該完蛋了Orz
因為這篇網誌是考完之後才寫的，所以是真的確定完蛋了…
專案報告 某學長還臨陣脫逃艸 最後我們這組就他沒來 被酸爆了XD
為什麼要有編輯風格的標準? 主要是為了能讓Programmer的程式架構盡量保持一致
方便閱讀，也能提升對Code的維護 尤其是在多人合作的時候
我們這組報告的是Python風格編寫標準，每組都針對不同的語言做報告
而這也是此次課程的重點，藉以分析不同語言的特性及是否認同他的寫作風格
不過再開始了解這些的Standard之前，專案、公司共同的編寫風格是 > Standard
主要是為了一致性的問題，為了追求這些Standard反而破壞與大家編寫code的一致性
這反而不太妥當，這也是我們在場聽到很多業界人士參與討論的聲音
當然你也可以完全不理會這些標準 開開心心的寫程式碼~不過有些標準不是沒有道理
有空當然還是希望可以參考一下囉!
PEP 8 – Style Guide for Python Code (本篇以官方為主)
https://legacy.python.org/dev/peps/pep-0008/
Google Python Style Guide
https://google-styleguide.googlecode.com/svn/trunk/pyguide.html
我大約整理了一些常見的類型&專案開發課程的討論&心得
想看完整點的可以看看上面這兩篇
#Python 特性
try:
for port in range(1,1025):
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
result = sock.connect_ex((remoteServerIP, port))
if result == 0:
print "Port {}: \t Open".format(port)
sock.close()
except KeyboardInterrupt:
print "You pressed Ctrl+C"
sys.exit()
從上面我們可以看到Python並沒有以{}做區塊的分別
而是嚴格採用空白來做區分(註: 空白和TAB不可混用 建議全空白) 這類的特性(Ruby也是如此)
可以稱他是竹竿曬衣!XD 長長一隻竹竿，下面整齊掛一排衣服
讓整體Code具高可讀性，也大大減少了新手容易搞不清區塊的問題
這也是為什麼Python對新手非常有善的地方之一 區塊都是以 “視覺化” 為主
像是因為{}之中 所以{x=1;for(int i=1;i<10;i++)x++;System.out.print(x);}
不小心都擠在一行也是ok的…It’s work!等等 (當然Python真有心這樣做也可以啦Orz)
##Code lay-out
foo = {
long_dictionary_key:
long_dictionary_value,
...
}
foo = long_function_name(var_one, var_two,
var_three, var_four)
my_list = [
1, 2, 3,
4, 5, 6,
]
不論在PEP8 或 Google 都會希望以四格空白來做區塊的分辦
參數的話如果太長則是能夠以上一行的開頭為對照
如此一來比較能夠一眼就曉得這些區塊的位置在，但並非所有的語言都建議以四格
例: JavaScript 會比較希望是以二格來做排版
不過像我碰到要接手的案子，有的人就是習慣用二格，為了確保一致性…還是照對方所做的吧
##Maximum Line Length
with open('/path/to/some/file/you/want/to/read') as file_1, \
open('/path/to/some/file/being/written', 'w') as file_2:
file_2.write(file_1.read())
超過80字元長就以 \ 換行吧~
傳統的終端機terminal，最大一行的顯示字元約80字，所以一般會規定一行不要超過80字
不過現在的編輯器很方便當然可以超過這個範圍，但還是建議以這個值為主
一來是比較容易閱讀 此外如果今天換成是開發前端的網頁呢…?
不像Python、C、Ruby…等等，執行的環境不是在這些編譯器中，而是在各種不同的瀏覽器
以直譯的方式來執行，更不用說有的還有非主流的瀏覽器存在，對於超過該行而跳到下一行
的原始碼會不會如其執行? 所以能避開不必要的問題就儘量吧!
url="https://www.example.com/developer/documentation/csv_file_name_extension_full_specification.html"
在Google的標準中有提到網址就最好不要這樣做了 這點我超同意!XD 尤其是要複製的時候!! 會多 “\”
##Blank Lines
區塊是不是該用單、雙行空行做區塊 好比method(function)之間、class之間 等等
不同關連性的以兩行來分，有相關的則是一行做區隔
在Google的標準中甚至有嚴格規定class開頭與第一個method需要空兩行 其餘則空一行
而巢狀class(class裡頭包含class) 有此類別也是以雙行來做區隔
這點我想就見人見智了吧~現在得知的都是公司沒有這類規定 大多都以一行空行(也許是懶XD)
##Source File Encoding
在Python2中預設編碼是ASCII 建議都改成UTF-8
可以在程式的第一行打上
#-*- coding: utf8 -*-
這也幾乎是我開始寫的第一個動作，原因無他…你只要一打個非英文的特殊字元或中文
程式馬上就噴個無法辨識ASCII的Error給你看
在Python3已經將預設編碼改成UTF-8 就比較沒有這類的問題
……問題是大多數用Python的人都是停在2 XD 太多好用library都在2還沒跟上Orz
##Imports
import os
import sys
建議在載入packages時能夠分開，不同的package在不同行
比較清楚可以知道用上了哪些package，最好不要一次就一行全數載入
此外在python中不見得要載入整個package，你可以只載入你需要的module即可
from subprocess import Popen
在Google範例中你也能把不同的module 分別放在不同行
from foo.bar import baz
from foo.bar import Quux
這我倒是比較不喜歡 通常我會這樣做
from subprocess import Popen, PIPE
不過看每個人的做法~沒有對或錯
##Whitespace in Expressions and Statements
Yes: spam(ham[1], {eggs: 2})
No: spam( ham[ 1 ], { eggs: 2 } )
Yes: if x == 4: print x, y; x, y = y, x
No: if x == 4 : print x , y ; x , y = y , x
Yes: spam(1)
No: spam (1)
Yes: dict['key'] = list[index]
No: dict ['key'] = list [index]
這邊對照就會清楚很多，雖然空格很好，可是有時候太多也不好
一般在做參數的時候通常只有參數與參數之間或參數與值之間才有必要
有沒有發現這些空白的地方有點眼熟? 沒錯，如果觀察夠敏銳就會發現到這些規則
和英文寫作的規則非常的相識，逗號、冒號、句號都是要再後頭空格
所以可能有些人有因為英文文章沒有在標點符號空兩格而被老師念吧?
另外像上述的if如果只有一行 Google標準會建議就連同要做的動作寫成一行
但是在JavaScript中就會建議你這麼做
if (a>b){
print a;
}
同樣的沒有對或錯，出發點在於如果需要再加上其它的行為在if下會方便很多~
此外有一點超級無敵重要!! 千萬不要這麼做!!
x = 1
y = 2
long_variable = 3
龍哥(高見龍大大) 稱其為 “程式碼潔癖” XD
雖然我在python沒遇過 … 不過目前在接的CASE…CSS天殺的有!! 我貼過來
#title
{
border: 2px solid #7EB2DB;
color: #FFFFFF;
background-color: #7EB2DB;
height: 20px;
padding-left: 10px;
-webkit-border-top-left-radius: 10px;
-webkit-border-top-right-radius: 10px;
-moz-border-radius-topleft: 10px;
-moz-border-radius-topright: 10px;
}
而且還是長達一百多行都這樣搞，自己要新加的style和其它元素
要跟他保持漂亮的版面 可是空白按到死也不是…
不跟他學，最後一個CSS檔有兩種編寫風格也不是…
最後我是屈服於自己的懶惰 要排你自己以後在慢慢排XD (逃)
##Comments
在編寫註解的時候最好可以緊黏你要註解的區塊
#Comments Here~A function
def function:
pass
中間如果空行 容易讓接手的人產生這註解應該是上一塊的
而就順手直接在空行處加入新的程式碼
導致Comments和程式碼對不起來，這便會產生一個非常大的問題
又一個新人來接手，在讀程式碼發現這一塊和Comments對不上
通常第一個反應都是 「是不是我理解有錯?」 而花非常多時間再重讀、理解
最後才發現是Comments標錯地方 不管何種標準都稱其為 “最糟糕的後果”
此外如果是單行最好不要附在code的後面
x = x + 1 # Increment x
為什麼? 課本、教科書明明都這樣做!
課本和教科書會這麼做是因為印刷的問題，如果都單行註解，一段程式碼可能就會多出好幾頁
最主要是因為容易造成閱讀者會分心，當我們眼睛在左邊專心讀code了解邏輯時
容易因為右邊有字而造成分心 (通常你會強迫你自己要去讀他XD)
##Programming Recommendations
try:
value = collection[key]
except KeyError:
return key_not_found(key)
else:
return handle_value(value)
在我沒特別注意前也會忘了加
try、except(catch)完之後 就直接將程式往下寫了 少了else(finally)
記得加上去減少bug產生，也讓你的例外處理多了邏輯
Yes: if foo.startswith('bar'):
No: if foo[:3] == 'bar':
如果有字串的function可以使用就千萬不要客氣
不要自己去硬幹，除了非常不好讀之外，萬一像bar改成chen 這樣四個字就錯了
此外硬幹有時還會比較沒有效率喔~ Taipei.py社群有實驗過XD
Yes: if greeting:
No: if greeting == True:
Worse: if greeting is True:
如果greeting回傳已經是True或False了 就不需要在多此一舉了
1 == '1' True!!
1 == True True!!
1 === '1' False!!
1 === 1 True!!
附帶一提在JavaScript中 有 == 和 === 之分
with open("hello.txt") as hello_file:
for line in hello_file:
print line
之前在社群也有討論到 在Python中最好的讀檔方式是什麼?
就是不要用read()!!
這當然是用上了for loop的特性才能這樣做~XD
程式碼會變的很好讀，一看就知道要做什麼而且也很方便
不需要在特別呼叫一個function來讀取
當然還有很多Python漂亮的寫法 除了可以參考上述兩份文件PEP8、Google之外
有人整理了一些不錯的寫法 我也老早把它加到我的最愛之中 :) 在此分享
30 Python Language Features and Tricks You May Not Know About
https://sahandsaba.com/thirty-python-language-features-and-tricks-you-may-not-know.html
##Naming
PEP8 (Python官方的標準) 還尚未有對名字的定義標準
不過Google倒是有給一些規則，這些在其它的程式語言之中也常常見到
一些像是全部大小表示常數、Class的開頭單字都要是大寫
不過有些變數或者function則看是全部小寫或是getMoving()
受Java影響像講師-依瑪貓會習慣在有行為的function前面加個get
這也許也是個不錯的建議! 總之不管風格是什麼，
在遵循一些標準時，不要妨礙到自己寫程式的心情最重要XD