プログラミングでのこだわり
| 980 票 / 44% |
| 222 票 / 10% |
| 72 票 / 3% |
| 152 票 / 6% |
| 84 票 / 3% |
| 298 票 / 13% |
| 257 票 / 11% |
| 122 票 / 5% |
投票所 | 他の国民投票
- 選択肢が少なくても文句禁止。だって、そもそもがジョークだし、場所は有限だし、選択肢を決めるのに事前投票なんてできないから。
- なんか良い投票ネタがあったら是非タレコんでくれ(国民投票用と明記)。毎回かなり悩みまくりなんだな、これが。ぶつぶつ言わずに助けてくれよぅ。
- この投票はとってもテキトーだ。四捨五入の誤差、投票マニア、ダイナミックなIP、 システムのバグ、プロキシーやファイヤウォールなんて考慮しちゃいない。統計だと思って このデータを大事な事に流用しようと思うなら小学校からやり直しましょう。
この議論は賞味期限が切れたので、アーカイブ化されています。
新たにコメントを付けることはできません。
美しさというよりは (スコア:4, 参考になる)
メンテしやすい事。
♪それが~一番大事~
# いや、本当にメンテしやすいソースコードはそれなりに
# 美しいとは思います
『今日の屈辱に耐え明日の為に生きるのが男だ』
宇宙戦艦 ヤマト 艦長 沖田十三氏談
2006/06/23 JPN 1 - 4 BRA
Re:美しさというよりは (スコア:1)
いかにデザインパターンをうまく適用して美しく見えても、
クラス数が膨大になったりして可読性が下がってしまっては
ヒトリヨガリでしかないと思う。
でも「メンテしやすい」の定義も人それぞれなところもあるよなぁ…。
私は条件分岐三項演算子を多用しますが、「読みにくい」と言って嫌いな人もいるようで。
#flg = (isLast) ? "1" : "0";みたいなやつ。
Re:美しさというよりは (スコア:1)
クラス数が少なめで実現されるってことは、ひとつひとつのクラスの仕事が膨大になるため、かえって可読性の低下・拡張性の低下につながりません?
少ないほうが、そのクラスの仕事が明確化されるし、いっぺんに見なくちゃならない部分が減るからかえって楽な気が・・・。
安易なAC発言反対運動中
Re:美しさというよりは (スコア:1)
Ctrl-クリックによるジャンプやステップ実行は私のコード読む時間を劇的に短縮しました。
#秀丸でやってたころは…(涙
十数行のクラスが7つも8つもあるとゲンナリしますよ…。
一個のクラスの複数メソッドでええやん!と。
Re:美しさというよりは (スコア:2, すばらしい洞察)
> 一個のクラスの複数メソッドでええやん!と。
is-a なのか has-a なのかを検討せずに
集約するのは危険かと。
Re:美しさというよりは (スコア:1)
「コメント」という選択肢があれば, それに入れたんですけど. 今回は該当無しで無投票です. 10何年前から, 自分が書いたソースは3日で忘れると公言してコメント「だけ」充実させていましたから.
本当は日本語でコメントを入れたいんですけど, 日本語を読めない人が多いので英語で書いています.
# ENVY24(HT)のbinary outputルーチンで悩んでいるのでID
Re:美しさというよりは (スコア:1)
例えば「i.have('a pen')」とコード自体が何をしているかを表すことが出来れば、そこにコメントは必要ありません。
勿論、全員が全員同じように記述して理解できる訳じゃないのでただの理想に過ぎないかもしれませんけども。
Re:美しさというよりは (スコア:1)
すんごく脱力したことがあります。
#それに比べるとお前のは「ベタ」で分かりやすい
#カッコつけて英語なんか使うと本人が忘れるぞと先輩に言われた
「ベタ」な変数名はいけませんか?(^^;
収入 (スコア:3, おもしろおかしい)
Copyright (c) 2001-2014 Parsley, All rights reserved.
コメント (スコア:2, 参考になる)
プログラムなんてカッコイイ物は書けませんが、手間を省くためちょっとしたマクロを書いた時など、
後で見るとわからなくなることがありました。
やっぱり、コメントは重要です。
Re:コメント (スコア:2, 参考になる)
面倒と思って書くコメントほどいいかげんになりがち。
ヘタしたらコピペの書き換えミスとか古いコメントの改訂忘れで
嘘になっているようなところもよくある。
コメントを過剰に義務化するからこうなる。
だから俺は、複雑な部分,試行錯誤した部分に限定した上で
詳しく書けと教えてる。
--
Ath'r'onならfloatあたりに自信が持てます
Re:コメント (スコア:2, 興味深い)
ソースコードの全行にわたってコメントを書いてあるのは逆効果ですよ。
見づらくてしかたないのです。
それでもまだ、内容が論理的なところまで叙述できてればまだ少しはいいのですが…
// 整数型変数i に0を代入する
int i = 0;
なんてコメント書かれてもね…。
誰に説明しているつもりなんだろうと。
当人いわく、新人君にもコメントの書き方の見本になるようなコメントを書いたとのこと。
見事に見本になってます。反面教師の。
# いいや。IDで。
Re:コメント (スコア:3, おもしろおかしい)
コードの質は推して知るべし。
……ええ、そっこーその仕事から逃げ出しましたとも。
# 書いたのは別の会社のまったく知らない人でした。
Re:コメント (スコア:2, 参考になる)
>見づらくてしかたないのです。
同意。
個人的には
1. 関数の頭には何行でも関数に関する説明を書いていい
2. 関数内部はいずれかに限り手短にコメントを入れる
- if文等の分岐条件に関する解説
- ミスリーディングしやすい部分の補足
- 仕様上回避できないコンパイル時警告に対する言い訳
というルールでコーディングしてます。このルールで不十分なコメントしか書けない場合はたいてい関数の作り方が腐ってます。
(ちなみ、いわゆる「しみったれた高速化」は要求されないというのが前提です)
ステップの短さ (スコア:2, すばらしい洞察)
★田舎に生息する時代遅れのFortran&COBOLガイなオタク★
Re:ステップの短さ (スコア:1, 興味深い)
言語の要素の中の何が1ステップとして扱われるの?
Re:ステップの短さ (スコア:1)
本当のところは知らないんですが。
たまーに、訊いてくる人(or会社)いますね。
たぶん、{や}だけでない意味のある行を1ステップと考えるんで
はないだろうかと。
たぶんコメントは含めないと思う。
なので、1ステートメント≒1ステップ、みたいな・・・。
#それがそのプログラムを推し量るのにどれほど有効かははなはだ
#疑問ではありますが、訊いてくるからには上記をざっと計って
#答えておりますです、はい。
---
「萌え」「美少女」「メイド」に現実逃避してはいけませんか、そうですか。
人事を半分尽くして天命を待つ
Real Real Programmer (スコア:2, 興味深い)
本物のプログラマはわかりやすい変数名にこだわる
本物のプログラマは派手ではないが直感的なUIにこだわる
本物のプログラマは問題解決に最も適した言語にこだわる
本物のプログラマは必要ならばメモリや速度にもこだわる(だが、チューニングは局所化する)
本物のプログラマはたまにイースターエッグにもこだわる
本物のプログラマは本物の怠惰さについて最もこだわる
# 自分の目的をいかに「本当に」怠惰にこなすかが腕の見せ所!!
Re:Real Real Programmer (スコア:1)
ゲームの話だけど、マスターアップ直前に勝手に裏技追加したアホがおってな…
それだけならクライアントから叱られる程度で済んだのだが、
最終テスト潜り抜けて致命的なエンバグ起こしたもんだからさあ大変。
製造工程に入った後に発覚して全回収。億クラスの損失だそうな。
まさに、喜劇。
てなわけで、茶目っ気もほどほどにね。
思い付き仕様はαまで。
--
Ath'r'onならfloatあたりに自信が持てます
コメントで削除 (スコア:2, 興味深い)
みなさん、仕事でプログラムを修正する場合、特に削除をする場合は、どのようにやりますか?
僕は最初の現場で「コメントアウトして削除しろ」と教わったのですが、人によっては、そうでもないみたいなのです。
削除をコメントでやると、かなりソースがみっともなくなるのですが、普通(?)はどうなのでしょう?
履歴管理ツールでやるのが、一番なんですかね。
データ構造の合理性 (スコア:2, 興味深い)
レイモンドさんが、
「ロジックがひどいのは書き換えればいいが、データ構造がひどいのは直せない」
みたいなことを言ってた気がするんです。
どのソースか忘れちゃった。「伽藍とバザール」かな?
なんかもう、いろいろバテバテなんですけど。
スタッフロール (スコア:2, 興味深い)
まあ、そこまで行くプロジェクトはまだ幸せなほうですが...
-- cooper
「派手な」は余計 (スコア:2, すばらしい洞察)
UI は重要ですよ。でも派手にすりゃいいってもんじゃない。見た目が派手でも爽快感を感じられない UI というのはあるものです (MS-Office の歴代ヘルプアシスタントとか -_-;)。そもそも「派手な」と言った時点で GUI しか想定されてないし (コマンドラインツールのオプション引数の設計だって UI だし、Web ツールの URL だってある意味 UI だし)。ユーザーにとっての「使いやすさ」に拘ることも、プログラマーの美学の一つであるべきだと、私は思うのですよ。
むらちより/あい/をこめて。
見た目のコーディングの美しさ (スコア:1)
-----
スケーター12号〜(┌ ┌ ┌ ´Д`)┘
Re:見た目のコーディングの美しさ (スコア:1)
と言うのは趣味で、古いヤツのメンテとか改造だと、小容量のメモリに如何に突っ込むかが問題になるんだよなぁ。
んでもって、そう云うヤツはこの頃の若いヤツには理解できない事らしい。
んでも、慣れると面白いんだけどねぇ。
Re:見た目のコーディングの美しさ (スコア:1)
--
Ath'r'onならfloatあたりに自信が持てます
Re:はぁ~ビバノンノン (スコア:1)
「コンパイラは信用できないからね」ってヤツですね。
# 「アセンブラとリンカは信用できないからね」な今日この頃... どうしろと。
sinkopeとの互換性 (スコア:1)
意思の互換が取れるような
見た目の美しいコード
ということでFA?
否。 (スコア:1)
引き継ぎで一番重要なのは可読性です。
--
Ath'r'onならfloatあたりに自信が持てます
Re:否。 (スコア:2, すばらしい洞察)
可読性は本当に重要です。
コメントをつけて読みやすくしているのではなく、
コメントが無くても何をしているか追えるのが、
可読性のあるコードだと思います。
実際にはロジックがすっきりしてることを目指します。 (スコア:1)
# たまに言語の制約に引っかかって悔しい思いをしたり...
CPUの1Clockは血の一滴 (スコア:1)
数値計算は速さが命 (スコア:1)
1割速くなるなら美しくなくてもいいやと思ってしまう。
大半が使い捨て前提だが、仕事が進まなければ進まないほどコードが長生きする(苦笑)
Re:CPUの1Clockは血の一滴 (スコア:1)
後はヘボいコンパイラが吐いたアセンブリコードを見て余計な MOV をループの外に出すなんてのもやりましたっけ (今は以下略)。
Re:CPUの1Clockは血の一滴 (スコア:1)
68020はLoopを小さくして256byteの命令キャッシュを有効活用。
i486のころは巨大な8KBキャッシュを有効活用。
Pentium4 内部でどんな風に実行されるかよくわからんので色々やってみて一番速い奴。
# それでもアセンブラまでは手を出さない。せいぜい、コンパイラが吐いたコードをながめるだけ。
使用言語 (スコア:1)
ねたではありません。
Minder
Re:使用言語 (スコア:2, おもしろおかしい)
Re:使用言語 (スコア:1)
#モシ hoge ナラバ hogehoge ニイケ
免責 (スコア:1)
対応はしますけど。
/* Kachou Utumi
I'm Not Rich... */
移植性 (スコア:1)
... 結構、苦しみだったり。
# POSIX shell を仮定させてくださ~い... (;_;)
csh でプログラムを組まない事 (スコア:2, 参考になる)
csh はプログラムに利用するのは止めましょう。
理由は「なぜ csh でプログラムを書くのが良くないのか」 [jmas.co.jp] を御覧ください。
FreeBSD Q&A [freebsd.org] も csh のプログラム利用を推奨していません
(しかし、例外とする条件が記載されています)。
Re:csh でプログラムを組まない事 (スコア:2, 参考になる)
それはさておき、ここで「移植性」と言っているのは /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 でプログラムを書くのが良くないのか」の最後の方にある通り、
という時代の尻尾に私はいるようです。
そう言えば、最近の HP-UX では、将来 /bin から /usr/bin への symlink をなくすと言っているようです (未確認)。 #!/bin/sh と書けない時代が来るかも知れない、ということなんですかね...。
参考文献: Various system shells [in-ulm.de]
美しさと速さ (スコア:1)
他もそうだけど、Cはこの傾向が顕著に現れますね。
Cの意図的な醜さは、美しく、速いコードを書いて、動いた後で
最後のもう一押しで書き加えられます。
// もちろんここで、勝ち誇ったようなコメントを。
// 他の人に悟られないように。
速度、ただし実行速度ではなく作成速度 (スコア:1, 興味深い)
・単機能にする
・ソースを複雑にしない、無駄なことは書かない
・素早く書いて、素早くテストして、素早く実用
・使いまわす(以前作ったものをモジュール化するか、そのままパイプでつなげる)
・入力はSTDIOのみ、エラーはSTDERRのみ
こんな感じなんで、使うのはいつもPerl。CPAN最高。
業務支援か、自分の趣味でしか使わないので、、、
何で「設計」がないんだ! (スコア:1)
トップダウンで分かりやすい設計になっていることほど重要なことはない、
と他人のソースを読みながらつくづく思う京子の頃。
というか、トップダウンで最初に重要なのはクラス設計とかではなく、
ソースファイルの配置と命名法だったり、
プログラム名と設定ファイル名の一貫性だったりする。
# mishimaは本田透先生を熱烈に応援しています
タフさ (スコア:1)
頼むからエラーチェックぐらいしてくれよぅ
ぬるぽ放置して知らん顔すんなよぅ
assert()やらabort()やらで引っかかりまくるコード上げて他人の作業まで止めんなよぅ
float変数をイコールゼロで弾くだけでゼロ除算回避したつもりになんなよぅ
メモリ少ない環境で断片化起こすような使い方すんなよぅ
…とまぁ、たった数人のヘボPGがチーム全体をデスマーチに誘うわけで。
最近出向先の地雷率高いので、スタッフの教育からさせてくれと思う今日この頃。
--
Ath'r'onならfloatあたりに自信が持てます
Easter Egg (スコア:1)
…自分はセンスがないのか、あまりいいものを思いつかないんですが…。
Webアプリなら、どっかに隠しリンクとかかなぁ?
Architecture Nativeならコナミコマンドとか?
Re:Easter Egg (スコア:1)
Webアプリなら・・・これも [srad.jp]ですか?
==
桑原、桑原
Re:仕様書と整合性ってないのかな? (スコア:2, おもしろおかしい)
紙の仕様書でも、仕様は動きます。
#それでいいのかよ?
タブレット中毒者。
Re:仕様書と整合性ってないのかな? (スコア:2, おもしろおかしい)
# それでいいのかよ?