パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

美しくなくても十分に機能するコードで良い?」記事へのコメント

  • パフォーマンスを重視すると、
    ある程度汚く読みにくくなるのは、
    仕方がないと思われますが。

    うちの仕事ものんびりした仕事は少ないので、
    とりあえず動くものということだと、
    金余分に貰ってそれをOSとDBにつぎ込んで
    VBできる人を集めて、ASPで作っちゃいます。

    Javaの「使える」エンジニアは常に不足気味ですから、
    なかなか現場の要求に迅
    • > パフォーマンスを重視すると、
      > ある程度汚く読みにくくなるのは、
      > 仕方がないと思われますが。

      これって昔から言われることですが, 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと. おそらくは

      • 直接アセンブラを使ってディレイスロット等を入れる場合
      • パイプラインの長さを生かすためにループアンローリング等の技法を使う場合

      程度か, その類似の場合だけで, 多くの場合はむしろコンパイラが最適化しやすいように明瞭なプログラムの流れにした方が良いでしょう. それに手による最適化が必要な局面っ

      • > 本当にこれが当てはまるケースって今ではごく稀になっているのではないかと.

        そうかな?コンパイラによる最適化が効くような、
        抽象度の低い層の話だけでもないだろう。

        外部には公開していない、
        オブジェクト内部でだけ保持しているような中間状態を利用して
        高速化を行うことって多いんでないかな。特に
        --
        # mishimaは本田透先生を熱烈に応援しています
        • そうそう、privateだとかはコメントレスも良くある話 :D
          (って言うか、ちょっとしたのならやっちゃうし。

          public:はキレイキレイに書くんだけどなぁ。

          愚痴
           コメントレスなソースとか時々見かけたりして
           ソース見ただけで判るからコメント要らないなんて言ってる人とは
           一緒に仕事したくありません(タダの愚痴だよ (/_;)
          • by Anonymous Coward
            むはー。MT-Safe だとかイロイロ考え始めると、private メンバたりともおろそかに扱って欲しくないけどなぁ!

            Java 文化の場合、

            ・クラス名、メソッド名、メンバ変数名は省略せずに書く
            ・1ファイル1クラス
            ・(特にシステムパッケージ以外の) import はクラス単位で書く
            • by Anonymous Coward
              > むはー。MT-Safe だとかイロイロ考え始めると、private メンバ
              > たりともおろそかに扱って欲しくないけどなぁ!

              本質的にはそこまで考えなくともよい、というのが private たる
              所以なんですけどね。 Java の限界でしょうか。

              え、私?
              Java は既に見限って C でOOPしてます。
              --
              iiojun

              • 本質的にはそこまで考えなくともよい、というのが private たる
                所以なんですけどね。 Java の限界でしょうか。

                private をおろそかにすると、MT-safe なものはとても書けないはずなんですが。逆に言えば、private をそうとしか考えてないということは、使い方を間違っているとしか言えないような。
              • by Anonymous Coward
                Java の言語実装がそこまで十分に練られていない
                (というか他とのトレードオフなのかもしれませんが)、
                という指摘です。

                "private" の意味をよく考えてみましょうね。
              • by Anonymous Coward
                少々、言葉足らずでした。

                本来、アクセススコープとMT安全性は直交する概念です。

                が、「"private"な実装は全て実装者だけ分かっていればよく、
                そのクラスの利用者は"public"なインタフェースだけ
                気にすればよいのであるから、インタフェースさえしっかり
              • by johndoe (3028) on 2002年09月19日 22時40分 (#168842) 日記
                外部から破壊できないのならprivateは充分にMTセーフだと思う。
                で、privateが外部から破壊できる状況ってのは、publicなインターフェースからのアクセスに限られません?
                親コメント
              • by Anonymous Coward
                もちろん、「全ての public なインターフェイスから独立な private メンバ」しか持たないであれば、MT-Safe であることは自明です。が、そのようなメンバに何か意味があるのでしょうか?(^^;

                実質全て final、ということになりますよね。コンストラクタで指定された属性を保持するだけのメンバ、という感じかな。なんとなく String 型のような「参照専用
              • by johndoe (3028) on 2002年09月20日 20時50分 (#169470) 日記
                いや、意味の有無じゃなくて私がいいたいのは、できあがったクラスを使う側がprivateに対してMTセーフかどうかを考慮する必要はないし、できないよね。privateがMTセーフかどうかっていうのを意識するのは内部実装を担当する人であって、できあがったクラスを使う人じゃないってこと。
                クラスがMTセーフをうたってないのに、privateはMTセーフであるべきってのは違う話じゃなかろうかと

                #単純に参照の出し入れをするだけのセッタとゲッタがあれば private であっても public とかわんねぇじゃんって話の延長ですね
                親コメント
              • by Anonymous Coward
                すみません、日本語として「できあがったクラスを使う側がprivateに対してMTセーフかどうかを考慮する必要はないし、できない」の意味がよく分かりません。

                あるインスタンスの利用者が、個々の private なメンバについて考慮することは不可能かもしれませんが、そのインスタンスが MT-Safe かどうか、というのは、(private なものも含め) 全ての内部状態への操作に異存する話で、private メンバだけ切り離して考えるわけにはいかないんじゃないでしょうか。

                「クラスが MT-Safe をうたっていない」というのは、全 public method が同期されていない
              • by johndoe (3028) on 2002年09月22日 13時54分 (#170238) 日記
                う~ん、私は説明へただからなぁ

                たとえば、あるクラスAがあるとして、そのクラスAのprivateなメンバについての情報をソースを参照せずに知る方法はあるでしょうか?(シリアライズの情報を見れば知れる場合も多いけど)通常はわかりませんよね。
                その状態でクラスAを利用する人はクラスAがMTセーフかどうかを意識することはあっても、privateなメンバがMTセーフかどうかを意識することはできませんよね。
                だから、privateなメンバがMTセーフかどうかを意識しないといけないのはクラスAのpublicなインターフェースの実装者であって、クラスAのユーザではありませんよね。
                だから、ユーザはprivateに対してはMTセーフかどうかを考慮はできないし、する必要もないと考えているのですが。

                あと、クラスがMTセーフをうたってないといのはドキュメントの話です。MTセーフだと明記されていないクラスはMTセーフでないか、MTセーフかどうかを考慮していないと考えてます。ドキュメントで明記されていなくてもMTセーフなクラスは複数あるかもしれませんが、そのクラスがMTセーフであることはドキュメントに明記されていない以上、約束されたことではなく、次のバージョンでは変わっているかもしれませんし。

                外部からMTセーフか否かを知るすべがないのは確かに私も言語の欠陥であると思っています。Javadocの要素でもいいから実装者が外部にMTセーフか否かを公開する方法が欲しいですね(コンパイラでチェックするところまでは求めないけど)。
                親コメント

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...