1 :
上級ぷよらー:
あまりの美しさに見入ってしまって
コーディングがちっとも進まないのですが、どうすればいいでしょうか。
2 :
音速の名無しさん:2001/06/03(日) 19:07
とりあえずコード貼れ
3 :
仕様書無しさん:2001/06/03(日) 19:09
駆け落ちして溺愛の果てに美しく心中するのだ。
>>1 ほっほっほ
それはとてもよいことじゃ(笑)
でも、世の中にエレガントにコーディングできる人って
どれくらいいるんだろう?
日本人でいる? そんな人。
そんな人が身近にいるなら最高だね!!
5 :
仕様書無しさん:2001/06/03(日) 19:29
>>4 俺がいるじゃねーか俺が。
俺のコードなんざ1よりもはるかに美しいぜ。
コード自体が美術館行きだもんな。
けけ。
断腸の思いでリファクタリング
7 :
仕様書無しさん:2001/06/03(日) 19:32
冷静な同業者に客観的にみてもらって意見をもらえばどうか。
俺: (完璧だ。これ以上のコードは考えられない。)「Tさん、こんな感じでどうですか?」
Tさん:「ここはこうした方がいいんじゃない?あとここのelseいらない」
俺: 「・・・・・はい」
9 :
仕様書無しさん:2001/06/03(日) 19:48
藤原博文の本で長い方のelseを取ってネストレベルを下げることを
推奨してるけどelseで対比した方が構造的にはわかりやすい
11 :
まだ内定ない:2001/06/03(日) 20:07
elseを取る前に条件を反転させるなりしてネストを下げれないか
どうか考えてみる事が重要だ。
まあ、スピード重視ならそれも難しいけど。
とにかくelseはいるに賛成です。
12 :
仕様書無しさん:2001/06/03(日) 20:39
わかるよ。
苦労したコードを見ると自分の才能に惚れ惚れするね。
if (.........) {
/* 真の処理 */
...................................
return;
} else {
/* 偽の処理 */
...................................
return;
}
14 :
仕様書無しさん:2001/06/03(日) 20:42
アセンブラでプログラム書いてて、
パイプラインにうまく乗り、分岐予測も完璧、すくねーレジスタもうまく
やりとりして作った時のソースは滅茶苦茶愛着があるぞ。
こんなの、業務ではまず出来るわけないし、仕事に追われて時間もない。
無駄な時間がたくさんあった子供のころに戻りたい。。。
15 :
仕様書無しさん:2001/06/03(日) 20:45
>13
その場合は return の位置がアホかと思われ
if (.........) {
/* 真の処理 */
...................................
} else {
/* 偽の処理 */
...................................
}
return;
16 :
仕様書無しさん:2001/06/03(日) 20:48
「苦労したコード」ってあんまし良くないんじゃない?
まぁ苦労が見えるコードというべきか・・・
17 :
まだ内定ない:2001/06/03(日) 20:49
>>13 普通そうだと思う。
けど、僕じゃ説得力ないな。
PS. return;はいるの?
>>1 あんまり自己評価が高いのは、技術者としてどうかと思うが、どうよ?
常に批判的に検討しなくてはな!
19 :
仕様書無しさん:2001/06/03(日) 21:15
>>14 漏れも~
>>18 普通Cとかのコードを見て、あまり美しいって感じないよね。
20 :
K&Rの本で:2001/06/03(日) 21:25
while(*s++=*t++);
昔、これを見て泣きそうなほど感動したんだけどなぁ・・・
21 :
仕様書無しさん:2001/06/03(日) 21:46
22 :
仕様書無しさん:2001/06/03(日) 21:48
最近はコードよりお絵かき(クラス図他)の美しさを追求してしまうな。
23 :
仕様書無しさん:2001/06/03(日) 21:51
>>20 なんだこりゃ。いつループ抜けるんですか?
24 :
仕様書無しさん:2001/06/03(日) 21:53
わかりづらいか?
そのまんまやん?
25 :
仕様書無しさん:2001/06/03(日) 21:54
こんな駄スレに投稿している奴の気が知れない。
26 :
仕様書無しさん:2001/06/03(日) 21:56
>>23 tのポインタが指す先の値が0になれば
ループを抜けます。それがsのポインタが指す
先に代入され、その値が評価の対象となるわけです。
ってまじレスしてどうすんの。
ここプログラマー板でしょ。
27 :
仕様書無しさん:2001/06/03(日) 21:57
1へ
1に逢いたい。
今、この夜に、突然逢いたくなった。
訳も無く、理由も無く…ただ、1に逢いたい。
そう、心が求めてしかたない…
今、何をしてる?
もう眠ったか?
レスしようとした指が、一瞬とまってしまう。
「せめて、1の自作自演が見たい…」
俺の我が侭を、許してほしい
1のことを、こんなにも好きだったなんて
離れてはじめて知った。
淋しくて、切なくて、どうしようもない、苦しい…
「駄スレを見せて欲しい」「クソスレが見たい」
1が俺の心を占める。
俺の中に、1に伝えたくて伝えたくてしかたが無い
たくさんの言葉が交差してる。
吐き出しても、吐き出しても、次々に溢れでる言葉が
1への想いが…
枯れること無い俺の気持ちを、どうか聞いてほしい。
伝えたいことはひとつ。
「1が、好きだ。誰よりも。」
それだけだ。
1が、この間のように、少し驚いて
「俺にレスもらえて嬉しい」って、言ってくれたら
それで、俺も幸せなんだ。
繰り返す。「1が、好きだ。」
センスも、文も、その、クソスレも。
すべてが好きだ。
28 :
23:2001/06/03(日) 22:01
>>26 たったいま転職を決意しました。さいなら。
29 :
仕様書無しさん:2001/06/03(日) 22:33
>>20のコーディングだけど、慣れればあたりまえのように感じると思うよ。
いいコーディングって何かというのは議論が尽きないところだけど、
少なくとも分かり易さという基準だけで判断するのは間違っていると思う。
「分かり易さ」っていうのは主観が入るし、万人にわかりやすいなんてあり得ないしね。
特に権力を持った人が「分かり易さ」を言い出すと、コーディングは逆にわかりづらく、
かつ一貫性のないものになりがちだと感じているのは俺だけかな?
31 :
仕様書無しさん:2001/06/03(日) 22:55
「わかりやすさ」にも3種類あると思う。
まず、
1.初心者にとってわかりやすい
2.中上級者にとってわかりやすい
3.自分にとってわかりやすい
であろう、
でも、結局の所、日頃、自分が良く使っている書き方が一番理解
しやすくて、なれてない奴だとかえって難しいだろう。
それに、コードの美しさも2種類あって、
1.初心者や一般の人にとって美しい
2.上級者にとって美しい
だろ、それで、
1.初心者や一般の人にとって美しい=どちらかといと表面的な美しさ、
もしくは、内面的には良くわからないが、神秘的な美しさがある
2.上級者にとって美しい=内面的な技術的な美しさのことで、
これはかなりの技術を持っている人はその技術がまるで芸術の如き
に感じられるもので、多分、一般の人には何がなんだかわからなくて、
かなりつまらないものに見えると思う。
結局の所、上級者にとって美しいことは、その芸術作品が見る人を選ぶ、
ということで一般の人にはあまり価値の無いものになるだろう。
32 :
仕様書無しさん:2001/06/03(日) 22:57
要は職業プログラマか職人プログラマかってことでいいか?
33 :
仕様書無しさん:2001/06/03(日) 23:16
>>32 職人を悪く言っているようで、安易には同意できない。
最近の技術レベルの低下には、そら恐ろしいモノがある。
ビジネス感覚も重要だろう…
しかしそれが招いた結果は?
34 :
:2001/06/03(日) 23:30
>>33 > 最近の技術レベルの低下には、そら恐ろしいモノがある。
そうなんですか?
昔に比べて、プログラミング技術の書籍もWEBサイトも増えていて
情報量は多くなっているのだから、向上しそうなもんですが。
いや、技術レベルが低いのはウチの壊社だけかと思ってましたが。(苦笑)
35 :
仕様書無しさん:2001/06/03(日) 23:34
教科書に載っているようなコードでは
飯は食えんのよ。
37 :
仕様書無しさん:2001/06/03(日) 23:41
よい教科書を探せるのも実力の内と思われ
38 :
仕様書無しさん:2001/06/03(日) 23:44
技術レベルの低下って言うのは全体的なことではないかな?
これだけプログラマーの数が増えてしまって、教育とか経験を積む
時間もないわけだから、全体的なレベル低下は避けられないと思う。
しかし、やはり中には優れた人もいるわけで、そういう人のレベルに
合わせるように底上げされればいいのだけれど、現実は逆で、
プログラムのレベルは全体的なレベルに合わせて作られることが多い。
そういうことがまた優れた人のやる気をなくなせているという悪循環
なんだよね。
39 :
:2001/06/03(日) 23:47
>>35 いやいや、情報量が増えているのは入門/初級レベルだけの話ではない
と思いますが?
もっとも、全然勉強しない人が多いのも事実ですが・・・。
40 :
仕様書無しさん:2001/06/04(月) 00:46
そういえば、コメントの美しさも実力のうちだよね。
教科書~で言えば、教科書レベル(以上)のプログラムを書ける人は
尊敬します。あとで本やWebみて「あちゃー。こっちのが綺麗やん。」
というのはままある話。(-:
# まだまだ修業中。
41 :
仕様書無しさん:2001/06/04(月) 02:05
>38
あぁ、自分のこと優秀だとは思っていないけど、それなりに出きるつもりではある。
私は、あなたの言いたいことを実感しているプログラマの1人です。
今のプロジェクトC++使ってるんですが、
C++(っていうかC)が分からない人のために
・ポインタ使っちゃダメ。
・構造体使っちゃダメ。
・規定外のクラス作っちゃダメ。
・継承なんてもっての他。
っていう規則があります。
で、どーしろっちゅーねん!!って感じでやる気起きません。
っていうか、下に合わせようっていう風潮で技術力が向上するわけ無いじゃん。
マジで会社を変えようと思っているところです。
42 :
仕様書無しさん:2001/06/04(月) 02:12
>>41 ポインタ使わないでCのプログラムを書くのは難しいな (w
表面だけでも配列の形式にすればいいの (WWW
43 :
仕様書無しさん:2001/06/04(月) 02:14
あ、規定内のクラスとリファレンスを使って書けばいいのか!
うんうん、リファレンスがあればなんとか。
そういう問題ではない?
44 :
仕様書無しさん:2001/06/04(月) 02:15
45 :
K&Rの本で:2001/06/04(月) 02:17
他にもいろいろ感涙コードいっぱいあるんだけど・・・時代なのかなぁ。
最近はコンパイラも賢くなって最適化とか神懸りチックになってきたし
年寄りには色々きつくなってきたけど、やっぱりプログラミングはイイよ。
40超えても楽しいもんは楽しいって。
>>30 見てみたけど、ちっとも感動できなかった…。
>>1 よいコードを書きたければ
自分の書いたコードよりよっぽどいい方法があると常に思ってましょう。
>>35-36
教科書のコードっていってもいろいろあるしね。
50 :
仕様書無しさん:2001/06/04(月) 22:37
>>41 VB使え(゜д゜)ゴルァってな感じの規定ですね(藁
でもCでポインタ不可縛りで組むのも面白そうかも(w
51 :
仕様書無しさん:2001/06/04(月) 22:42
~縛り、ってなんか罰ゲームみたいで面白いな。
ifつかっちゃだめ、とか。
for,while,goto使っちゃだめとか(w
再帰で号
53 :
仕様書無しさん:2001/06/04(月) 22:48
そういや goto は禁止されてたなぁ。
goto 使った美しいコードってないのかな?
54 :
まだ内定ない:2001/06/04(月) 22:50
>>41 そんな規則無視しろ!分からない奴が悪い!
おれはC++勉強して1週間目で継承つかったぞ。
趣味で。
55 :
仕様書無しさん:2001/06/04(月) 23:01
>>41 その仕事って何かの罰ゲーム?
その仕事って何かの罰ゲーム?
57 :
仕様書無しさん:2001/06/04(月) 23:14
>>53 exit()を使いたくない時(dllなど)で、かつ、解放しないといけない
リソースが多いような時は、goto使うと綺麗なことも多いみたい。
>>46 TAILQ_PREV() は、以前は次のように定義してあった。
#define TAILQ_PREV(elm, field) ((elm)->field.tqe_prev)
これと
>>30 を見比べると、ちょっとうまいと思わん?
59 :
仕様書無しさん:2001/06/05(火) 00:21
>>41 ファイル開かないのか?
あ、open()/close()つかうのか!
stdio.h/iostream.hを使わない初心者って、それはそれでカコイイ。
>15
if (.........) {
/* 真の処理 */
...................................
return TRUE;
} else {
/* 偽の処理 */
...................................
return FALSE;
}
>>60 13は「if-blockの最後に(無条件の)returnがあるなら、続くelse-block自体、
省略できるのでは?」といいたかったのだろう?
で、15はその場合は、ってことわって「void型でif-elseの各blockの最後の
returnならまとめられるやん。」って例、示してんのに、関数のsignature変
えてどうすんの。(藁
それに例題へぼすぎ。あくまでif-elseペアにこだわるなら、局所変数使えば
よし。
enum BOOL { FALSE, TRUE };
.....
{
BOOL retval;
.....
if (.........) {
/* 真の処理 */
...................................
retval = TRUE;
} else {
/* 偽の処理 */
...................................
retval = FALSE;
}
.....
return retval;
}
60はなんちゃってか?
62 :
仕様書無しさん:2001/06/06(水) 17:10
金融系のバッチ処理にアクションゲームのフロー放り込んでみたら
めちゃめちゃ性能でた。
DLTの速度がボトルネックになっちまったけどな(w
63 :
ほげほげ:2001/06/06(水) 23:11
>>1 わかるよ。その気持ち。
きたないコードばかり見てると、ついつい自分のを見てしまう。
eかげん疲れた。メンテはいや。おれに作らせてー。> リーダー
64 :
名無しさん@そうだ選挙にいこう:2001/06/06(水) 23:27
入社前からシコシコプログラム書いて悦に入ってたような
ヲタクはこういうナルシストばっかでタチ悪い。
本人は芸術のつもりか知らないけど、メイテナンス性最低の
コードばっか書いてくれる。他人が簡単に手を入れられない
ようなソースは産業界ではゴミ。趣味でやってろバカ。
この手の「プログラム命」みたいな職人気取りの低学歴を
採用するくらいなら、プログラム経験ゼロのそこそこの大卒
を3ヶ月仕込むほうがずっとよい。
65 :
仕様書無しさん:2001/06/06(水) 23:30
>>64 張飛型かぁ・・・。
自分も昔はそうだったなぁ・・・。
66 :
仕様書無しさん@65:2001/06/06(水) 23:41
零細企業でなくて、比較的大きな会社であれば、
64さんのようなタイプを沢山そろえた方がいい。
話は変わるが、歴史的に見てもこのタイプの戦
略を取った軍隊の方が勝利を多く収めている。
あとは企業のお偉いさんや、お客などにこの意
識が広がり、
リストラ = コスト削減
の構図が崩れれば、もっとPGの
メンテナンスは容易になるだろう。
67 :
仕様書無しさん:2001/06/06(水) 23:48
>>66 >あとは企業のお偉いさんや、お客などにこの意
>識が広がり、
無理無理。
国内企業の客やお偉いさんには、袁術が多いもん。
68 :
仕様書無しさん:2001/06/07(木) 00:01
>>64 君の意見をオープンソースコードの人らが聞いたら
切れるだろうな
69 :
ほげほげ:2001/06/07(木) 00:02
>>64 > この手の「プログラム命」みたいな職人気取りの低学歴を
> 採用するくらいなら、プログラム経験ゼロのそこそこの大卒
> を3ヶ月仕込むほうがずっとよい
ま、やってみ。どっちも変わらんから。
ツーかスレ題とかんけーねーねーねーねーね。
70 :
よーはこういう事なんじゃないの?:2001/06/07(木) 00:08
if(.....){
/* 偽の処理 */
return FALSE;
}
/* 真の処理 */
if(....){
/* 偽の処理 */
return FALSE;
}
/* 真の処理 */
return TRUE;
71 :
仕様書無しさん:2001/06/07(木) 00:17
>>70 たのむからreturnはひとつにまとめてくれ!
デバッグしにくくてしょうがないんだよ!
73 :
仕様書無しさん:2001/06/07(木) 00:24
>>72 そんなわけじゃあないが、分散されると見にくくないか?
エラールートにreturnがあるのは構わないけど、
エラーならエラー、正常なら正常でそれぞれひとつずつくらいに
return は絞った方がブレーク張りやすいし。
74 :
72:2001/06/07(木) 00:28
>>73 returnを一つにまとめようとして、逆にわかりにくいコードを見たことが
あったので、すっきりするのならどっちでもいい
75 :
70:2001/06/07(木) 00:28
正常ルート(終了は常に関数の最後)と
例外ルートを分散したほうがソース見易くないかな?
これってそんなに変な書き方?
変なら今後直そうかと思うんで・・・
76 :
71=73:2001/06/07(木) 00:43
>>75 変じゃない。ただ、例外ルートは例外ルートで
まとめられるならまとめた方がいい。と思う。
>>64 の文章は、優秀なプログラマが書いたものか、
ヘボプログラマが書いたものかで解釈が大きく変わるな。
78 :
仕様書無しさん:2001/06/07(木) 01:03
>>77 ヘボな奴のメンテ性ほどシビレル論理も無いな(ワラワラ
64がそうとは言わんが。
かといって構造化オタもイタイ。
79 :
仕様書無しさん:2001/06/07(木) 01:42
>>61 アセンブラになったとき、たいていの場合60の方が有利だよ。
リターンをいちいち変数に突っ込むなんて、MOV系の命令が
余計に入っちゃうでしょ。たとえば、この関数が一定時間に
すごい回数呼ばれるような状況があったら、MOV1回の違いが
パフォーマンスに大きく影響してきます。
(普通、そういう部分はコンパイラまかせにしないで自分で
アセンブラで書いちゃいますが)
プログラムは、当然メンテナンスのしやすさも大事だけど
スピード、リソースをいかに使わないで同じことが出来るかが
とても重要ですよ。職業プログラマなら、普通それを考えますけど。
最適化したりしてプログラムが読みにくくなってきたら、コメントの
数を増やせばいいだけのはなし。ぜんぜんコメントも入れずに
ただだらだらとプログラムを書くやつは最低ですね。
>>79 最適化作業は後回しの方がいいと思うよ。
機能テストが完了した時点で最適化作業をしても
バチはあたらないと思う。
アセンブラレベルでデバッグするときならなおさら
returnが一箇所にまとまってないと戻り値のログが
とりにくくってしょうがない。と思う。
>たとえば、この関数が一定時間に
>すごい回数呼ばれるような状況があったら、MOV1回の違いが
>パフォーマンスに大きく影響してきます。
……いったい何千万回呼ばれればパフォーマンスに影響するんで?
いや、あたしゃ
>>61で挙げられてるような書き方は
(単なる好みの問題で)やらないけど。
>>81 「バイナリになったときに性能がいい」という煽り文句には、心惹かれてしまいます。
たとえほんの数クロックしか高速化しないとしても。
83 :
sage:2001/06/07(木) 02:16
>>72 バグが出たときに、現場の人と修正担当者が
頭抱えて悩む時間をクロック数にすれば、
大体、どういう風に書いたほうがいいのか決まります。
あちこちでbreak outするコードを書くと
メモリリークなんかの、見つけづらい系バグに悩まされる
確率高いです
>>81 けっこう影響するよ。制御系なら。
それ以外で影響する場面は俺も知らない
85 :
仕様書無しさん:2001/06/07(木) 09:56
Cだとリークの問題はあるけど、基本的にそのあと何もしないのに
関数末尾のreturnまで処理を飛ばすのは逆に可読性を落とすよ。
try {}finally{}があればリークは関係なくなるからがんがんreturnするね。
あと、elseを略すべきか否かは、それぞれの条件における処理のレイヤが意味的に
等価な場合は略さない方が見やすいでしょう。
関数の処理を打ち切る(後続とは明確に異なる)という意思表示のためにelseを
省くことはある。
例:
if (condition) {
:
} else {
:
}
if (!isEnabled) {
return;
}
:
前者でブロック内の処理が一定以上あって、その後何もしないなら、ブロック内でreturnして
しまった方が後続を見なくてすむ分読みやすいです(当然主観)。
しかし、そんな場合そもそもブロックないを関数化してしまうので、その必要性もあまりない
ともいえますけど。でも、結局
if (condition) {
return processTrue();
} else {
return processFalse();
}
みたいにするかな。
86 :
61:2001/06/07(木) 10:20
>>79 わかりにくくてすまそ。
個人的には、if-elseのペアや1関数1returnに拘ったりはしない。
70が上手く表現してくれたが、続く処理の例外を先に除去していき、その際、
必要に応じて return や exit(), setjump()/longjump(), try-catch をする
方かな。
例外ケースが複数あれば、もちろん自然と
if (例外1)
else if (例外2)
....
のようにもなる。
optimizationについては、register 宣言&コマンドオプション程度で、
たまに profile を使ったりもするけど、高級言語ではアセンブラまで落として
を入れることは滅多に無いので、tuningに関してはコメントを差し控えます。m(_ _)m
< たまに profile を使ったりもするけど、高級言語ではアセンブラまで落として
< を入れることは滅多に無いので、...
---
> たまに profile を使ったりもするけど、高級言語ではアセンブラまで落として
> 手を入れることは滅多に無いので、
スマソ。>ALL
return (condition) ? processTrue() : processFalse();
>>20 タダのオナニーにしかすぎんと思うけどどうよ?
おそレススマソ。
91 :
仕様書無しさん:2001/06/08(金) 11:49
プログラマー=理系の変態
>>1 if (p*~v^_* q/*やったね!*/)
こんなコードか?