Edison.X. Blog

這是我自己看 code 、present my code 的心得。

一些需要比較長流程的 code，對 beginner 而言，本身要 present 便需花些時間閱讀，

若此時還使用了一些 (較後半段的技巧) ，諸如 malloc、struct、typedef 等，

整篇文章、整份 code ，對 beginner 而言反而失去了重心。

舉個較簡單的小例

#define DATA_CNT  100
#define K                5
#define DIM            4

double data[DATA_CNT][DIM];
double center[K][DIM];
double div_mse[K];
char     map_table[DATA_CNT][K];

後面四個 array 在說明演算法過程中，我也認為較適合以 static array 說明，

同時 presnet 之資料量也不該太大 (至少要保證能放在 stack 裡面)。

試想一下若一份 code 裡面有四分之一都在搞 memory allocate、memory release，

即使用 C++ 之 container (如 vector)，對整份 code 之 present 、對初學者之理解，

未必有所幫助，反而模糊了此份 sample code 欲表達流程之焦點。

另，除非 struct 之封裝對整份 source code 、整個演算法之理解有所助益，

( 有些演算法確實封裝起來，對理解上較有助益沒錯，普遍性而言演化式演算法皆為如此；

但為 beginner present 帶來之 Slide Effect 可能是效率變低、徒增不必要的空間)

否則，認為也不必額外再做 typedef、struct 之動作，

如此只會徒增對程式語言特性不熟悉之 reader 困擾。

present 可以這麼示之，但 reader 吸收後，應根據自行需求進行變更，

而非再圍著「不會開讀檔、不會動態配置、不會用 STL 」打轉，

present 時已盡可能將所有技巧壓低，其中所使用之語法、觀念乃不會，

是否該再回去花些時間將程式語言架構起來？

因此認為在修習類似課程時，應將語言之格局配置、技巧性壓至較低，

畢竟相關課程目的 (除了真的叫 "演算法" 之課程)，

應是「以程式語言 present 演算法」為目的，

而非「以演算法折磨新手，強制修練程式語言之技巧」為樂趣。

除非需求者是有不得已原因，必須寫份通用性較高、參數可隨時更動之演算法，

即使如此，所牽涉之技巧實在也不會太多。

總之，任何演算法之 present，認為不該使用太複雜之技巧，

反而使得 beginner 無從下手。

當然，若打從一開始就沒 present 給 beginer 就沒必要有這層考量。