Redmi Pad評測：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍牙耳機到筆記本電腦，紅米不知不覺之間也已經形成了自己頗有競爭力的產品體系，在中端和次旗艦市場上甚至要比小米新機的表現來得更好，正所謂“大丈夫生居
使用Go和使用其他編程語言中一樣，需要了解常見錯誤和不良實踐，才能編寫既干凈又高效的代碼。
本文討論的一些實踐并不一定都是不好的，在特定情況下很有用。 然而，我們需要知道可能會有什么問題，為什么應該回避某些習慣，以及如何避開常見的陷阱。
Go中的init()函數是一個特殊函數，在main函數之前執行。
"如果初始化對于任何包都很重要，為什么init()在Go中被認為是一個不好的做法?"
是的，雖然init()函數確實有助于在運行核心邏輯之前進行初始化，但其執行順序可能很難理解，可能導致對初始化順序的混淆。
// package Afunc init() {}// package B func init() {}// which run first?想象一下，有兩個模塊在安裝時相互依賴，但位于不同的包中。結果我們最終需要編寫更復雜的代碼來管理時序，更糟的是，甚至可能陷入死鎖情況。
使用init()的另一個缺點是測試會變得復雜。因為這些函數是自動運行的，無法選擇何時執行。
缺乏控制使得設置測試用例成為一項挑戰。
我曾經遇到過一個問題，我的服務在部署后花了很長時間才準備好。我在main()函數的開始處設置了一個斷點，但從未觸發。
經過冗長的調試后，我們發現一個成員使用了某個包中的init()函數從一個大文件加載一個大數據集，這讓我們花費大量時間去解決這么一個小問題。
Go中的全局變量可能會帶來類似單例的問題，特別是當這些全局變量很復雜時(比如映射、切片或指針)。
"那么，全局變量有什么大不了的?"
因此，這里的建議是保持對包的封裝。
從而使得代碼更容易移動，并且不太可能破壞其他東西。通過避免使用全局變量，可以使代碼不那么受約束，并且更容易更新或復用。
用Go編程時，錯誤是不可避免的，知道如何處理錯誤可以讓我們避免各種各樣的問題。
"忽略錯誤真的那么糟糕嗎?"
是的，完全正確。
一些Go新手可能會用"_"符號將錯誤撇在一邊，但忽略函數返回的錯誤值，可能會帶來麻煩。
如果不對錯誤進行管理，也許程序會出現panic和crash。
// sample 1func main() { var x interface{} = "hello" s := x.(int) // panic: interface conversion: interface {} is string, not int fmt.Println(s)}// sample 2func main() { var x interface{} = "hello" s, _ := x.(int) // safe but DON'T fmt.Println(s)}跳過錯誤可能會適得其反，尤其是對于線上生產環境，調試會成為一場噩夢。總是--我的意思是總是--檢查錯誤并采取正確的措施以保持代碼順利運行。
無論用Go還是其他語言，避免使用"goto"是大家的共識。
使用goto會破壞代碼的自然流程。
會破壞我們理解不同代碼段之間關系的方式，讓我們很難在不弄得亂七八糟的情況下修改代碼。
此外，調試也變得更加令人困惑，測試也更加棘手。
從本質上講，依賴goto往往會產生更多錯誤，并難以深入了解問題。因此，作為最佳實踐，明智的做法是避開它。
如果你忽略"defer"和"recover"，就失去了對panic的堅實保護。
為什么?
因為當出現panic時，"defer"仍然會起作用，而"recover"會抓住panic，讓我們有機會處理不可預見的問題[2]。
看看這個例子，其中'file.Close()'只是放在末尾，這不是一個Go風格的解決方案：
func readFile(filename string) { file, err := os.Open(filename) if err != nil { panic(err) } // Do something with the file file.Close() // <--- DONT}相反，像這樣使用"defer"：
func readFile(filename string) { file, err := os.Open(filename) if err != nil { panic(err) } defer file.Close() // Do something with the file ...}在打開文件后立即調用defer file.Close()可以確保即使readFile()遇到panic，文件也會被關閉。此外，還可以方便的提醒我們在打開資源后立即進行清理。
Go的context功能非常有用，當代碼與數據庫或網站對話時，有助于管理時間限制等事情。
如果沒有設定截止時間，應用可能會陷入阻塞，被數以百萬計的請求淹沒。
通過一個特殊功能，可以很容易的設置時間限制。
該函數有三種時間選擇: Fast(0.5秒)、Medium(3秒)和Slow(10秒)。這樣就不用一直使用context.Background()，而且可以為每個任務選擇合適的時間限制。
以下是Fast的一些示例代碼：
const FastTimeout = 500 * time.Millisecondfunc WrapCustomContext(ctx context.Context, dur time.Duration) (context.Context, context.CancelFunc) { return context.WithTimeout(ctx, dur)}func GenFastContext() (context.Context, context.CancelFunc) { return WrapCustomContext(context.Background(), FastTimeout)}func WrapFastContext(ctx context.Context) (context.Context, context.CancelFunc) { return WrapCustomContext(ctx, FastTimeout)}有了這些函數，就可以選擇正確的時間限制，應用也因此運行得更好。
好還是不好，只是一些概念，我們可以決定其真正含義。
所以，明智的使用"不好"的特性，它就能變成"最好"的方案。
參考資料：
本文鏈接：http://www.www897cc.com/showinfo-26-57886-0.html從錯誤中學習：了解 Go 編程的六個壞習慣
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： C++控制臺彩色時鐘的實現
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號