今度は海を越えてひどいソースがやってきた

現場も変わって心機一転、一見大丈夫そうに思えたけどそれは極一部で、
タイトルどおりやっぱりひどいソースだった。オフショアってやつ。
基本的にはこの前の現場と同じような内容で、ながーいメソッドのオンパレード。
人間やることは同じやね。

今回考えさせられたのはコメントについて。
ソースを修正とか削除した部分について、「誰が」「いつ」「どの部分」を修正したか分かるように、
コメントがいれてあるんだけど、これが著しくソースの可読性を下げる。
例えばこんな感じ
    if (hoge) {
// 2007.09.25 mod tma start
//        fuga();
        moge();
// 2007.09.25 mod tma end
    }
自分もこの業界に入って、一番最初の現場ではこのコメントをよく書いたけど、
それはソースをバージョン管理してなかった頃の話。
バージョン管理するようになってからは、見ることもなかったので懐かしい気分になった。
確かにヒストリーを辿ることなく、一見して誰が何をしたかが分かるというメリットがあるけど、
可読性をさげるデメリットの方がでかすぎると思う。
そもそも、バージョン管理の意味が薄れるし、コメントのおかけで、メソッドがながーく感じたりするし。

ただ、そういう感覚の人が少ないようで、
上のようなコメントが量産されていくんよね。。。。

2007-09-26 Wed 06:59


Comment

  1. しんどう
    2007-09-27 Thu 13:13

    私がみたことあるもの（あんまりないですが）ソースコードのど真ん中に書いてあることはないですねぇ。コードの先頭に履歴がだらーっと書いてあるはよくありますが。
    （それだと、今度はどこをどう直したのかよく分からないんですよね。）

  2. tma
    2007-09-30 Sun 11:19

    コードの先頭に履歴ってパターン、昔はよく見ましたね。
    その記述ならソースのど真ん中と違って、コードが見にくくならないし、
    いつごろの修正なのかわかり易いんでいいかもしれないですね。

    ど真ん中に履歴を書くよりよっぽどいいと思うけど、
    なぜか自分が経験した現場では履歴をヘッダに書くパターンは廃れたような気がします。

  3. Saxman
    2007-10-29 Mon 00:27

    初めてお邪魔します。
    未だにＶＢのソースなどではこういうソースをよく見ますね。ＶＢ経験者が他の言語に流れてきた結果のような気もします。
    ただ、コードの可読性を下げる原因の一番大きな要因は、エディタの１ページにメソッドが納まらないものだと思います。ＤＯＳ時代のころによく言われたことで、エディタ１ページ、つまり３０行以上のメソッドは作らないほうがよい。と言うのを聞いたことがあります。
    現在のエディタや解像度から考えると、最大でも５０行程度でしょうか・・。おおよそ４５行。
    コメント履歴をコード内に記述することで、これらの行数を逸脱する場合が多いため読みにくくしてると思います。
    でも、例えばこのコメント履歴をＸＭＬ書式で記述しておいて、後でＲｕｂｙとか使って抜き出すことで、変更履歴を管理したりできると面白そうですね。

  4. tma
    2007-10-30 Tue 06:09

    そういえば自分が昔みたのもVBでしたね。
    VB経験者ってのは人数多そうなので、そこから広がると影響でかいなぁ。

    メソッドが画面に一度におさまるようにしましょうって話は、
    自分も聞いたことあります。
    コメント履歴で　メソッドの行数が膨れ上がるってのは本末転倒ですよね。
    あと、インデントが無茶苦茶になる場合も散見されて、それも可読性を下げちゃってました。

    変更履歴をXML管理ってのは、バージョン管理システムにそういうインターフェースってないんですかねぇ。