我想剛開始學習任何事你都會找位老師，跟著學習，必且使用同樣的方法或工具。慢慢的才可以意會到方法與工具的精髓，接著會產生許多為什麼，然後就去找答案，這種迭代的行為，最後衍生出來的結果就會有自己的風格。
Coding style的磨練我想也是如此，初期聽從前輩的建言，開始看書看code，爬論壇，與人討論，思考為什麼這樣比較好？在一開始，你沒有深入其中過你根本無法體會，這些箴言為什麼如此重要？
利用這個週末，好好完整看完Juce coding standards這篇，最後更新時間是在2018年5月13號，維持一份document不容易，能夠不斷更新，這種一但有改變就要把介面一致化的態度，龜毛的非常值得學習，加上這一年只要能夠使用，我手上的專案都能夠看到JUCE的影子，就是因為這樣用，現在看這篇會特別有感覺及收穫。
廢話不多說，我會提出我個人的觀點加以筆記及註記未來可能可以參考使用的部分，如同Jules文中提到，這是個人品味。沒有特別筆記的，大概都是我也是這麼做的。
A lot of it is just personal taste! We’re not claiming this to be a definitive set of rules by which you should live, and we’re not particularly interested in arguing or defending any of the points here – it’s just a description of the way things ended up after many years of coding. YMMV!
在左括號前保留一個空格，e.g. foo (123);
但不要再沒有參數的情況下保留空格，e.g. foo();
這兩點很有意思，曾經有同事與我討論過這種風格，他的立場是：這樣做搜尋起來很方便。從IDE設置也可以看到，這種格式有被設計進去。
在comment後保留一個空格
// yes!
//no!
這屬於閱讀上的整潔，這種細節也制定，可以省去許多煩惱。
Multi-line comments 有幾種對齊方式
/* This is correct
*/
/** This is also correct
*/
/* This is wrong
*/
我覺得我就是欠限制，我看到這個風格上的制定非常喜歡，前兩者其實很常看到，後第三個，不畏言我還滿常因為對齊而這麼幹，但這沒什麼好堅持，我會follow大部分使用的方式。
16進制總是保持小寫
浮點數字元註記
0.0 // yes
0.0f // yes
0. // no!
0.f // no!
.1 // no!
.1f // no!
0可能是整數或浮點數，0.0或0.0f可以幫助閱讀，加上auto的使用，可以避免不必要問題產生。