l()有什麼不對

話說PHP因為不像JavaScript內建的log函式庫就挺不錯，不同的源碼中總是可以看到自己的log函式。最常見的不外乎是可以印出任意個引數值到error log / stdout / stderr，或是印出第一個引數後回傳之。

誒～但可能是大家都想盡量少打些字吧，我發現這類函式經常被命名為 l()。對，就一個一柱定海的l。

是很精簡啦，而且l這字看久也蠻美的 … 但個人認為這並不是一個好名字。為什麼？因為不夠明顯啊。這就有點像C++為什麼要引入static_cast reinterpret_cast啥的來取代C-style cast，要特別留意的東西應該要盡量設計成引人注目會比較好。

基於這項理由，我自己在用的是mango()、guava()和litchi()

……………….

……………….

真的啦，有code為證：

function mango( $val ) {
    if ( is_null( $val ) ) {
        return 'NULL';
    } elseif ( false === $val ) {
        return 'FALSE';
    } elseif ( true === $val ) {
        return 'TRUE';
    }

    return print_r( $val, true );
}

function guava() {
    $arg_strs = array_map( 'mango', func_get_args() );
    $log = join( ' ', $arg_strs );

    error_log( $log );
}

function litchi( $arg, $label = 'log value:' ) {
    guava( $label, $arg );
    return $arg;
}

說真的，自從我把這些log函式從WTF系列改成這台灣味的水果系列，整個人debug起來心平氣和，修為都提升了呢 🤪

而且另外的好處是很好搜尋啊。大家在提交源碼前相信公司都會要求把不必要的debugging log都拿掉吧？(啥？你們公司不用？塊陶啊～) 這樣只要ag guava就一定能找出所有的debugging log了呢。雖然也可以用ag '\bl\('找到所有的l()呼叫，但這打起來手就癢癢的，沒這麼順暢呢 … (個人因素

我在某次working tips分享中分享了這個小撇步，會後有人漲紅著臉拿了這個給我看：

function 👻( $val ) {
     if ( is_null( $val ) ) {
         return 'NULL';
     } elseif ( false === $val ) {
         return 'FALSE';
     } elseif ( true === $val ) {
         return 'TRUE';
     }
     return print_r( $val, true );
 }
 function 💩() {
     $arg_strs = array_map( '👻', func_get_args() );
     $log = join( ' ', $arg_strs );
     error_log( $log );
 }

嗯 … 真是超級明顯又好搜尋呢