パスワードを忘れた? アカウント作成

プログラミングでのこだわり

投票結果を表示しています。
見た目のコーディングの美しさ
  980 票 / 44%
変数名
  222 票 / 10%
派手なUI
  72 票 / 3%
使用言語
  152 票 / 6%
使用メモリ量
  84 票 / 3%
実行速度
  298 票 / 13%
イースターエッグ
  257 票 / 11%
sinkopeとの互換性
  122 票 / 5%
合計 2187 票
投票所 | 他の国民投票
  • 選択肢が少なくても文句禁止。だって、そもそもがジョークだし、場所は有限だし、選択肢を決めるのに事前投票なんてできないから。
  • なんか良い投票ネタがあったら是非タレコんでくれ(国民投票用と明記)。毎回かなり悩みまくりなんだな、これが。ぶつぶつ言わずに助けてくれよぅ。
  • この投票はとってもテキトーだ。四捨五入の誤差、投票マニア、ダイナミックなIP、 システムのバグ、プロキシーやファイヤウォールなんて考慮しちゃいない。統計だと思って このデータを大事な事に流用しようと思うなら小学校からやり直しましょう。

最新の国民投票

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by znc (2768) on 2004年11月30日 18時55分 (#659724)
    美しいかどうかではない。
    メンテしやすい事。

    ♪それが~一番大事~

    # いや、本当にメンテしやすいソースコードはそれなりに
    # 美しいとは思います
    --
    『今日の屈辱に耐え明日の為に生きるのが男だ』
    宇宙戦艦 ヤマト 艦長 沖田十三氏談
    2006/06/23 JPN 1 - 4 BRA
    • by raccoon (16317) on 2004年11月30日 19時13分 (#659734)
      まったく同感。

      いかにデザインパターンをうまく適用して美しく見えても、
      クラス数が膨大になったりして可読性が下がってしまっては
      ヒトリヨガリでしかないと思う。

      でも「メンテしやすい」の定義も人それぞれなところもあるよなぁ…。

      私は条件分岐三項演算子を多用しますが、「読みにくい」と言って嫌いな人もいるようで。
      #flg = (isLast) ? "1" : "0";みたいなやつ。
      親コメント
      • by vikke (8037) on 2004年11月30日 20時06分 (#659760) 日記
        クラス数の増加って可読性の低下につながりますか?
        クラス数が少なめで実現されるってことは、ひとつひとつのクラスの仕事が膨大になるため、かえって可読性の低下・拡張性の低下につながりません?
        少ないほうが、そのクラスの仕事が明確化されるし、いっぺんに見なくちゃならない部分が減るからかえって楽な気が・・・。
        --
        安易なAC発言反対運動中
        親コメント
        • by raccoon (16317) on 2004年11月30日 20時33分 (#659779)
          Eclipseのおかげでだいぶ読みやすくはなりましたけどね。
          Ctrl-クリックによるジャンプやステップ実行は私のコード読む時間を劇的に短縮しました。
          #秀丸でやってたころは…(涙

          十数行のクラスが7つも8つもあるとゲンナリしますよ…。
          一個のクラスの複数メソッドでええやん!と。
          親コメント
    • 「コメント」という選択肢があれば, それに入れたんですけど. 今回は該当無しで無投票です. 10何年前から, 自分が書いたソースは3日で忘れると公言してコメント「だけ」充実させていましたから.

      本当は日本語でコメントを入れたいんですけど, 日本語を読めない人が多いので英語で書いています.

      # ENVY24(HT)のbinary outputルーチンで悩んでいるのでID

      親コメント
      • by zumapon (9208) on 2004年12月01日 13時32分 (#660046)
        逆にコメントすら必要の無いプログラムを心がける方向もあると思います。
        例えば「i.have('a pen')」とコード自体が何をしているかを表すことが出来れば、そこにコメントは必要ありません。

        勿論、全員が全員同じように記述して理解できる訳じゃないのでただの理想に過ぎないかもしれませんけども。
        親コメント
    • 以前古いソースで変数名に全部「女性の名前」を使ったやつがあって、
      すんごく脱力したことがあります。
      #それに比べるとお前のは「ベタ」で分かりやすい
      #カッコつけて英語なんか使うと本人が忘れるぞと先輩に言われた

      「ベタ」な変数名はいけませんか?(^^;
      親コメント
  • 収入 (スコア:3, おもしろおかしい)

    by parsley (5772) on 2004年11月30日 21時23分 (#659794) 日記
    きれいごとなんてきらいだ~
    --
    Copyright (c) 2001-2014 Parsley, All rights reserved.
  • コメント (スコア:2, 参考になる)

    by baffclan (9449) on 2004年11月30日 20時12分 (#659766) ホームページ
    面倒でもコメントを書く。

    プログラムなんてカッコイイ物は書けませんが、手間を省くためちょっとしたマクロを書いた時など、
    後で見るとわからなくなることがありました。
    やっぱり、コメントは重要です。
    • Re:コメント (スコア:2, 参考になる)

      by Yakza (13745) <yakza@funifuni.net> on 2004年12月01日 10時59分 (#659988) ホームページ 日記
      下3行は同意だが、上1行は疑問。
      面倒と思って書くコメントほどいいかげんになりがち。
      ヘタしたらコピペの書き換えミスとか古いコメントの改訂忘れで
      嘘になっているようなところもよくある。
      コメントを過剰に義務化するからこうなる。
      だから俺は、複雑な部分,試行錯誤した部分に限定した上で
      詳しく書けと教えてる。
      --

      --
      Ath'r'onならfloatあたりに自信が持てます
      親コメント
    • 基本的には同意できるのですが…
      ソースコードの全行にわたってコメントを書いてあるのは逆効果ですよ。
      見づらくてしかたないのです。

      それでもまだ、内容が論理的なところまで叙述できてればまだ少しはいいのですが…

      // 整数型変数i に0を代入する
      int i = 0;

      なんてコメント書かれてもね…。
      誰に説明しているつもりなんだろうと。

      当人いわく、新人君にもコメントの書き方の見本になるようなコメントを書いたとのこと。
      見事に見本になってます。反面教師の。

      # いいや。IDで。
      親コメント
      • Re:コメント (スコア:3, おもしろおかしい)

        by TvT (19813) on 2004年12月02日 11時49分 (#660461)
        以前こんなコードを仕事で見ました。

        // コメントの始まり
        /*
        ...
        コードの質は推して知るべし。
        ……ええ、そっこーその仕事から逃げ出しましたとも。
        # 書いたのは別の会社のまったく知らない人でした。
        親コメント
      • Re:コメント (スコア:2, 参考になる)

        by calc (16044) on 2004年12月02日 18時40分 (#660628) ホームページ 日記
        >ソースコードの全行にわたってコメントを書いてあるのは逆効果ですよ。
        >見づらくてしかたないのです。

        同意。

        個人的には
        1. 関数の頭には何行でも関数に関する説明を書いていい
        2. 関数内部はいずれかに限り手短にコメントを入れる
        • if文等の分岐条件に関する解説
        • ミスリーディングしやすい部分の補足
        • 仕様上回避できないコンパイル時警告に対する言い訳
        というルールでコーディングしてます。
        このルールで不十分なコメントしか書けない場合はたいてい関数の作り方が腐ってます。
        (ちなみ、いわゆる「しみったれた高速化」は要求されないというのが前提です)
        親コメント
  • ステップの短さ (スコア:2, すばらしい洞察)

    by hhb02144 (6410) on 2004年11月30日 20時16分 (#659770) ホームページ
    というのがないのはナゼ?
    --
    ★田舎に生息する時代遅れのFortran&COBOLガイなオタク★
    • by Anonymous Coward on 2004年11月30日 22時33分 (#659822)
      昔からよく分からないのがこのステップという言葉。
      言語の要素の中の何が1ステップとして扱われるの?
      親コメント
      • by llm (11066) on 2004年11月30日 23時27分 (#659845) 日記
        僕も知らなくて、でも聞くのもアレなんで訊いてないんで未だに
        本当のところは知らないんですが。
        たまーに、訊いてくる人(or会社)いますね。
        たぶん、{や}だけでない意味のある行を1ステップと考えるんで
        はないだろうかと。
        たぶんコメントは含めないと思う。

        なので、1ステートメント≒1ステップ、みたいな・・・。

        #それがそのプログラムを推し量るのにどれほど有効かははなはだ
        #疑問ではありますが、訊いてくるからには上記をざっと計って
        #答えておりますです、はい。

        ---
        「萌え」「美少女」「メイド」に現実逃避してはいけませんか、そうですか。
        --
        人事を半分尽くして天命を待つ
        親コメント
  • by Anonymous Coward on 2004年12月01日 9時29分 (#659951)
    本物のプログラマはコードの美しさにこだわる
    本物のプログラマはわかりやすい変数名にこだわる
    本物のプログラマは派手ではないが直感的なUIにこだわる
    本物のプログラマは問題解決に最も適した言語にこだわる
    本物のプログラマは必要ならばメモリや速度にもこだわる(だが、チューニングは局所化する)
    本物のプログラマはたまにイースターエッグにもこだわる

    本物のプログラマは本物の怠惰さについて最もこだわる

    # 自分の目的をいかに「本当に」怠惰にこなすかが腕の見せ所!!
    • >本物のプログラマはたまにイースターエッグにもこだわる

      ゲームの話だけど、マスターアップ直前に勝手に裏技追加したアホがおってな…
      それだけならクライアントから叱られる程度で済んだのだが、
      最終テスト潜り抜けて致命的なエンバグ起こしたもんだからさあ大変。
      製造工程に入った後に発覚して全回収。億クラスの損失だそうな。
      まさに、喜劇。

      てなわけで、茶目っ気もほどほどにね。
      思い付き仕様はαまで。
      --

      --
      Ath'r'onならfloatあたりに自信が持てます
      親コメント
  • by yukichi (12361) on 2004年12月01日 19時10分 (#660212) ホームページ
    コメント関連なのですが、ちょっとお聞きしたいことが。

    みなさん、仕事でプログラムを修正する場合、特に削除をする場合は、どのようにやりますか?
    僕は最初の現場で「コメントアウトして削除しろ」と教わったのですが、人によっては、そうでもないみたいなのです。
    削除をコメントでやると、かなりソースがみっともなくなるのですが、普通(?)はどうなのでしょう?
    履歴管理ツールでやるのが、一番なんですかね。
  • by madcrown (15492) on 2004年12月01日 23時31分 (#660314) 日記
    ってのはないのかな?

    レイモンドさんが、
    「ロジックがひどいのは書き換えればいいが、データ構造がひどいのは直せない」
    みたいなことを言ってた気がするんです。

    どのソースか忘れちゃった。「伽藍とバザール」かな?
    --
    なんかもう、いろいろバテバテなんですけど。
  • by cooper (4658) on 2004年12月02日 1時21分 (#660354) 日記
    他愛もない遊びですが、Windows アプリの開発では秘密のショートカットで起動するスタッフロールを仕込むことが多いです。カットオーバーのタイミングで開発メンバーに御披露目すると、苦労した思い出が蘇えってくるようで、結構喜んでくれます。

    まあ、そこまで行くプロジェクトはまだ幸せなほうですが...
    --

    -- cooper

  • 「派手な」は余計 (スコア:2, すばらしい洞察)

    UI は重要ですよ。でも派手にすりゃいいってもんじゃない。見た目が派手でも爽快感を感じられない UI というのはあるものです (MS-Office の歴代ヘルプアシスタントとか -_-;)。そもそも「派手な」と言った時点で GUI しか想定されてないし (コマンドラインツールのオプション引数の設計だって UI だし、Web ツールの URL だってある意味 UI だし)。ユーザーにとっての「使いやすさ」に拘ることも、プログラマーの美学の一つであるべきだと、私は思うのですよ。

    --
    むらちより/あい/をこめて。
  •  偏見とは知りつつも、アセンブラでは目指さずにはいられない。
    --

    -----
    スケーター12号〜(┌  ┌  ┌  ´Д`)┘
  • by nodocuments (12199) on 2004年11月30日 18時32分 (#659711) 日記
    まったく面識も無いsinkope氏と
    意思の互換が取れるような
    見た目の美しいコード
    ということでFA?
  • ロジックがすっきりしてるとある程度は勝手に美しくなるんだけど。
    # たまに言語の制約に引っかかって悔しい思いをしたり...
  • 何が悲しゅうて、人間が loop unrollせにゃならんのや > ICL
    • コードをちまちま書き換えて、gccだとこっちの方が5%速い、なんて。
      1割速くなるなら美しくなくてもいいやと思ってしまう。

      大半が使い捨て前提だが、仕事が進まなければ進まないほどコードが長生きする(苦笑)
      親コメント
    • by oku (4610) on 2004年12月01日 1時24分 (#659904) 日記
      むか~し、V30 使ってた頃はやりましたけどねぇ... (今は、脳が老衰したのと、手が面倒臭がりになったのと、重い問題を解く機会がなくなったのと、プロセッサが富豪になったのでやらない)
      後はヘボいコンパイラが吐いたアセンブリコードを見て余計な MOV をループの外に出すなんてのもやりましたっけ (今は以下略)。
      親コメント
      • i386のころまでは実行に必要なクロック数えて。
        68020はLoopを小さくして256byteの命令キャッシュを有効活用。
        i486のころは巨大な8KBキャッシュを有効活用。
        Pentium4 内部でどんな風に実行されるかよくわからんので色々やってみて一番速い奴。

        # それでもアセンブラまでは手を出さない。せいぜい、コンパイラが吐いたコードをながめるだけ。
        親コメント
  • by moromama (23126) on 2004年11月30日 23時30分 (#659847) 日記
    日本語。
    ねたではありません。
    --
    Minder
  • 後から発覚したOSとかのBugで動作状況に問題が出た時の責任までは、検収後は取れませんよ。

    対応はしますけど。
    --

    /* Kachou Utumi
    I'm Not Rich... */
  • by oku (4610) on 2004年12月01日 1時34分 (#659907) 日記
    各種 *sh 間での (*csh は別言語なので無視)。

    ... 結構、苦しみだったり。
    # POSIX shell を仮定させてくださ~い... (;_;)

    • by tyuu (9154) on 2004年12月01日 19時31分 (#660221) ホームページ 日記

      csh はプログラムに利用するのは止めましょう。
      理由は「なぜ csh でプログラムを書くのが良くないのか」 [jmas.co.jp] を御覧ください。

      FreeBSD Q&A [freebsd.org] も csh のプログラム利用を推奨していません
      (しかし、例外とする条件が記載されています)。

      親コメント
      • by oku (4610) on 2004年12月03日 1時59分 (#660858) 日記
        csh はプログラムに利用するのは止めましょう。
        理由は「なぜ csh でプログラムを書くのが良くないのか」 [jmas.co.jp] を御覧ください。
        csh で script なんか書くな、というのは Unices の常識だと思うのですが、なぜ未だに「csh で書け。それがここの規約だ」なぞと言う仕事がゴロゴロあるのか... (;_;)

        それはさておき、ここで「移植性」と言っているのは /bin/sh を意図しています。 /bin/sh は A shell (Cygwin) だったり Bourne shell (一昔前までの Unices) だったり bash-1 や bash-2 (GNU/*) だったり pdksh (Windows SFU) だったり Korn shell や POSIX shell (最近の Unices) だったり Z shell (初期の MacOS X?) だったりするわけですが、どこでもそれなりに動くようにするには、まあ、それなりに面倒です。 Bourne shell の機能だけを仮定して書けば大抵は問題ないのですが、上述の「なぜ csh でプログラムを書くのが良くないのか」の最後の方にある通り、

        1003.2 が企業に対して強制力のある真の標準になったとき、状況ははるかに良くなることでしょう。 そのときまで、我々はそこらへんにあるバグあり互換性なしバージョンの sh で悩まされることでしょう。

        という時代の尻尾に私はいるようです。

        そう言えば、最近の HP-UX では、将来 /bin から /usr/bin への symlink をなくすと言っているようです (未確認)。 #!/bin/sh と書けない時代が来るかも知れない、ということなんですかね...。

        参考文献: Various system shells [in-ulm.de]

        親コメント
  • by GARIA (12647) on 2004年12月01日 3時55分 (#659935)
    比例します。Cの場合ですけど。
    他もそうだけど、Cはこの傾向が顕著に現れますね。
    Cの意図的な醜さは、美しく、速いコードを書いて、動いた後で
    最後のもう一押しで書き加えられます。
    // もちろんここで、勝ち誇ったようなコメントを。
    // 他の人に悟られないように。
  • by Anonymous Coward on 2004年12月01日 4時40分 (#659937)
    こんなところに気をつけてます

    ・単機能にする
    ・ソースを複雑にしない、無駄なことは書かない
    ・素早く書いて、素早くテストして、素早く実用
    ・使いまわす(以前作ったものをモジュール化するか、そのままパイプでつなげる)
    ・入力はSTDIOのみ、エラーはSTDERRのみ

    こんな感じなんで、使うのはいつもPerl。CPAN最高。
    業務支援か、自分の趣味でしか使わないので、、、
  • 最終的に出来上がったプログラムの全体像が、
    トップダウンで分かりやすい設計になっていることほど重要なことはない、
    と他人のソースを読みながらつくづく思う京子の頃。

    というか、トップダウンで最初に重要なのはクラス設計とかではなく、
    ソースファイルの配置と命名法だったり、
    プログラム名と設定ファイル名の一貫性だったりする。
    --
    # mishimaは本田透先生を熱烈に応援しています
  • 設計の手抜きはデバッグが大変になるだけなんだよぅ
    頼むからエラーチェックぐらいしてくれよぅ
    ぬるぽ放置して知らん顔すんなよぅ
    assert()やらabort()やらで引っかかりまくるコード上げて他人の作業まで止めんなよぅ
    float変数をイコールゼロで弾くだけでゼロ除算回避したつもりになんなよぅ
    メモリ少ない環境で断片化起こすような使い方すんなよぅ

    …とまぁ、たった数人のヘボPGがチーム全体をデスマーチに誘うわけで。
    最近出向先の地雷率高いので、スタッフの教育からさせてくれと思う今日この頃。
    --

    --
    Ath'r'onならfloatあたりに自信が持てます
  • by raccoon (16317) on 2004年12月01日 12時38分 (#660031)
    という回答もあるようですが、皆さんどんなの入れてます?

    …自分はセンスがないのか、あまりいいものを思いつかないんですが…。
    Webアプリなら、どっかに隠しリンクとかかなぁ?
    Architecture Nativeならコナミコマンドとか?

計算機科学者とは、壊れていないものを修理する人々のことである

処理中...