識別字名稱的長度

寫程式的人多半都講究命名慣例（naming convention），不論是微軟統治領土下的匈牙利式命名法（Hungarian Naming Convention）或Java社群廣為使用的駱駝式命名法（Camel Naming Convention），討論的都是名稱的形式，不過卻都沒有討論到名稱的長短問題。

多年前，當我開始留意命名慣例時，我會刻意的把每個名字都取的工工整整的，而且名稱都充份的表達出這個名稱的用途。例如：

        sdToStockInfoTCPBroadcastingServer

前頭的sd是代表它是個socket，後頭則表示它是連到股票資訊伺服器的TCP廣播伺服器。這麼一來，變數的名稱的確叫人一目了然，但這樣寫程式，那速度可就大受影響了。許多開始接觸命名慣例的人，的確會矯正變數名稱不具意義或過短的問題，但往往也矯枉過正，演化成喜歡取長名的習慣。

不禁令人想到，我們會需要為每個名稱（不論是類別、函式、或變數），都取個端端正正，望文生義（可能也十分冗長）的名稱嗎？我覺得不盡然。

名稱最重要的目的，是讓讀者理解。讀者在閱讀程式碼時，其實伴隨著一個context（語境）存在，也就是說，有了這個語境的輔助，其實有些資訊可以被省去，但讀者依然能夠理解。就好比，今早你的同事問了你一句：「昨天還好吧？」因為你昨天和他一塊喝到半夜三更，所以你會知道他在問的，多半是你昨天喝多了酒人有沒有怎樣，或者是回家有沒有被老婆罰跪主機板之類的。你的同事不需要說：「昨天喝了那麼多酒，身體有沒有不舒服或回家有沒有被老婆責備？」之類的話。這就是因為有個情境在輔助著的關係。

每一行程式碼，在程式中也都位在某個context之中。而每個名稱所存活的程式碼範圍，也在位於某個context之中。當我們可以用這個名稱所在的context來做為閱讀的輔助時，那麼名稱本身所需要包含的資訊就可以降低。當某個名稱需要包含的資訊可以降低時，它的長度通常就可以縮短。例如我們在parse一段XML的程式裡有可能是這麼寫：

在這裡我們在一個method裡取了xPathFactory、xPath、docBuilderFactory、以及docBuilder這四個長名。但這麼長的名稱，的確有助於我們多了解一些東西嗎？其實不然。倘若我們這麼寫：

讀者在閱讀到這個method時，會無法理解這幾個變數是在做什麼嗎？其實不會，因為有一個很重要的關鍵在於這個method的長度很短，這幾個變數名稱存活的範圍（scope）都很小，而且這個context是確定的，目的就是把fileName所指定的XML檔案建構成一個Document物件。在這個範圍內，我們每種型別的物件，都只用了一個，所以在命名物件時，使用該物件之型別名稱的大寫部份來構成變數的名稱即足以包含足夠的資訊，例如DocumentBuilderFactory物件命名為dbf。

在上例中，由於method短小，所以變數名稱也可以簡短化。倘若你的method長度很長的話（但長method是不好的習慣），那麼變數名稱就不見得能夠縮短了，因為變數存在的scope變大，變數名稱所需要包含的資訊量也必須提高。

摘要的來說，我認為一個名稱需要包含的資訊量和它所可被指涉的範圍成正相關。類別名稱需要很足夠的資訊量，某個類別下的method或field名稱次之，而method中所動用的變數名稱又再次之。method中可能還有一些名稱的生存範圍，例如method中用到的迴圈中所定義的變數，它們存在的範圍更小，用a、b、c之類的名稱來指涉，我個人認為也不會有太大的問題。

我的結語是，重視命名慣例是好的習慣，命名慣例是程式撰寫者與閱讀者的metaphor，可以加強溝通的效率及效果。但在命名上也不可矯枉過正，把名稱取得冗長異常，可以視名稱所存在的範圍大小，來決定它應包含的資訊量，藉以縮短名稱的長度。

我發現，寫程式速度往往受限於打字速度啊。XD

Posted at 08:26下午 二月 06, 2007 by Chien-Hsing Wang in programming  |  迴響[2]