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

将来しなくても良くなるコーディングテクニック」記事へのコメント

  • while((c=getchar())!=EOF)とか、 条件の中に代入演算子を混ぜると、将来コードを保守するスタッフが理解できなくて困るので、こういう書き方はしない。
    なんていう配慮をしなくてよくなる未来。
    • Javaだとできないけど、
      while (c = getchar(), c != EOF)
      が好き。

      # よけいわかりにくい?
      親コメント
      • うろ覚えですが..カンマ演算子の左右の評価順序はAnsi Cでは定義されてないんじゃなかったっけ?
        だからこの場合 c != EOFが先に評価されることもありえるんじゃない?
        gccは左から評価してるみたいだけど

        親コメント
        • by Anonymous Coward
          > うろ覚えですが..カンマ演算子の左右の評価順序はAnsi Cでは定義されてないんじゃなかったっけ?

          まさか、そんな畑中葉子みたいなことはありません。
        • by Anonymous Coward

          いいえ、カンマ演算子が左から評価されることは保証されていますし、副作用完了点もあります。
          関数の引数を区切るカンマと混同していませんか?

      • by Anonymous Coward
        あなたのコメントがチンカス程の値打ちもないのは、あなたがなぜそのスタイルを好ましく思うのか何も説明していないところです。
    • by Anonymous Coward
      int _getchar(int* p) {
          return *p = getchar();
      }

      while(_getchar(&c) != EOF)
      ってやりなよ。
      • while (TRUE) {
                c = getchar();
                if (EOF == c) {
                        break;
                }
                ....
        }

        // いやまあ、美しくないのはわかっているけど、将来の自分の可読性のためにもこう書く。
        //// そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。

        親コメント
        • > そういえば、比較のときに定数を左辺に持ってくるテクニックは、さすがに死んだか。

          未だによく見ますよ。
          古のコードのメンテナンスだけではなく、新規分にも。

          コーディング規約に明記しようとしたヒトを必死で止めたこともありました。
          「比較演算子の左辺に定数」「ハンガリアン記法」「カッコ前後の改行、空白」
          は、コーディング規約の体裁を整える(項目数を水増しする)ためによく使われますね。

          親コメント
        • by Anonymous Coward

          すみません。どこまでが冗談かわからないので無粋なのを承知で。当方が担当している
          プログラミングの講義では、
            while ((c = getchar()) != EOF) { ... }
          みたいな書き方はCや類似言語のイディオムとして定着しているので、代入と条件判定を
          わざわざバラして書くとむしろ意図がつかみにくくなるかも知れないと教えています。
          まあ、スタイルの問題はさほど重要ではないので、こう書かないと×にする等のダメ指導
          はしませんが。

          # 個人的には、こんなイディオムみたいなものができるプログラミング言語は設計が
          # 良くないのではと考えていますが。

        • by Anonymous Coward

          私はアリだと思いますよ。
          実際に解らない人間が多くなる表記ってのはメンテ上の問題増えるってのは確かですから。

          今じゃどうせ最適化はコンパイラがやってくれますし。

          綺麗で動かん物よりも、少々汚くても動く方がマシ。
          プロジェクト途上で来た新人が解らんからって、そこでいきなり教育手順を入れられる訳でも無いし。

          • by Anonymous Coward

            >少々汚くても動く方がマシ。

            ところがぎっちょん、「汚い」ってのは
            動かなくなってもどこが悪いのか切り分けにくいんだな。
            つまり今はいいが将来に負債を残してる状態ね。(MartinFowlerふうにいえば技術的負債)
            そしてその(時限)爆弾がいつ炸裂するかは俺らには読めない。

            >そこでいきなり教育手順を入れられる訳でも無い

            ペアプロでもやったら?

            コレじたいは、「具体的な知識こそないが技術的下地は有る」人間なら数分で説明が終わるだろうし、
            そうでなくても、
            そこにあるパズルを「パズルだからスルーしとけ」と頭ごなしに言うよりは、
            「このパズルはこう解くのさ」と最初に

      • by Anonymous Coward

        先頭がアンダーバーの識別子は処理系や標準ライブラリのために予約されているので使えない、なんて初歩的なことをわざわざ#1561133みたいなアホな保守スタッフに説明しなくてもよくなる未来。

        • by Anonymous Coward

          中途半端な理解しかしていなのに、初歩的なことだと思い込んで仕様を確認しない人も困る。

          • 私も疑問に感じて調べていたのですが、

            ISO/IEC 9899

            7.1.3 Reserved identifiers

              All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use.
              All identifiers that begin with an underscore are always reserved for use as identifiers with file scope in both the ordinary and tag name spaces.

            アンダースコア+大文字、アンダースコア二つで始まる識別子は常に予約されている。
            アンダースコアで始まる、ファイルスコープの識別子は、通常の名前空間とタグ名前空間で予約されている。

            ファイルスコープの識別子の扱いが別になるのが、ちょっと不思議ですね。

            親コメント
          • by Anonymous Coward

            C言語では関数のネストはできないんだから関数定義はファイルスコープに決まってるでしょうが。
            仕様の文字列を一字一句そのまんま暗記するしか能がないくせに他人の揚げ足を取ったつもりになってる奴は手に負えない。

            • by Anonymous Coward

              >C言語では関数のネストはできないんだから関数定義はファイルスコープに決まってるでしょうが。

              決まってない。staticの有無で、ファイルスコープになるか、それより広いスコープ(グローバルだったか?用語忘れた)になるか、が変わるのでは。

              C知識としてもそうだし、知識はさておき論理的に考えて「関数ネストが無い」ことと「ファイルスコープ」とのあいだには微妙な隙間があることに気づいてくれ。

              #「論理的に」いえば、関数の途中でファイルをぶった切ることが出来るという選択肢も有るが、Cでは採用してないので無視。

              ##要するに「ファイルスコープ」と「(グローバルのみの)関数スコープ」とがそれぞれ独立にY/Nがあると考えるわけ。それぞれY/Nがある4象限グラフね。

    • by Anonymous Coward

      そのような未来は何によってもたらされると想定していますか?

      ・アホでも読めるコードに自動変換する技術が進化する未来
      ・保守スタッフの技術が進化して結果的に貴方が弾き出される未来

      • 結果僕がはじき出されたらそれは僕にこの世界で仕事をする能力がないからですから、文句はありません。

        有る人が唱えてました。どんな世界でもプロフェッショナルの中でトップレベルの者の半分未満の能力しかない者はプロ失格で退場を強いられる。 ITの世界もトップレベルプロの半分に届かないの能力の者を追い出さなければ、良くならない。と。

        つーか、OOやLLの世界についていけなくて退場を宣告されるかも > 俺

        親コメント

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

処理中...