自分が書いたコードにホレてしまいます

あまりの美しさに見入ってしまって
コーディングがちっとも進まないのですが、どうすればいいでしょうか。

とりあえずコード貼れ

駆け落ちして溺愛の果てに美しく心中するのだ。

>>1
ほっほっほ
それはとてもよいことじゃ（笑）
でも、世の中にエレガントにコーディングできる人って
どれくらいいるんだろう？
日本人でいる？　そんな人。
そんな人が身近にいるなら最高だね！！

>>4
俺がいるじゃねーか俺が。
俺のコードなんざ1よりもはるかに美しいぜ。
コード自体が美術館行きだもんな。
けけ。

断腸の思いでリファクタリング

冷静な同業者に客観的にみてもらって意見をもらえばどうか。

俺：　　（完璧だ。これ以上のコードは考えられない。）「Tさん、こんな感じでどうですか？」
Tさん：「ここはこうした方がいいんじゃない？あとここのelseいらない」
俺：　　「・・・・・はい」

>>8
わかりやすさのelseはいるんだよ！

藤原博文の本で長い方のelseを取ってネストレベルを下げることを
推奨してるけどelseで対比した方が構造的にはわかりやすい

elseを取る前に条件を反転させるなりしてネストを下げれないか
どうか考えてみる事が重要だ。
まあ、スピード重視ならそれも難しいけど。
とにかくelseはいるに賛成です。

わかるよ。
苦労したコードを見ると自分の才能に惚れ惚れするね。

if (.........) {
　　/* 真の処理 */
　　...................................
　　return;
} else {
　　/* 偽の処理 */
　　...................................
　　return;
}

アセンブラでプログラム書いてて、
パイプラインにうまく乗り、分岐予測も完璧、すくねーレジスタもうまく
やりとりして作った時のソースは滅茶苦茶愛着があるぞ。
こんなの、業務ではまず出来るわけないし、仕事に追われて時間もない。
無駄な時間がたくさんあった子供のころに戻りたい。。。

>13
その場合は return の位置がアホかと思われ
if (.........) {
　　/* 真の処理 */
　　...................................
} else {
　　/* 偽の処理 */
　　...................................
}
return;

「苦労したコード」ってあんまし良くないんじゃない？

まぁ苦労が見えるコードというべきか・・・

>>13
普通そうだと思う。
けど、僕じゃ説得力ないな。

PS.　return；はいるの？

>>1
あんまり自己評価が高いのは、技術者としてどうかと思うが、どうよ？
常に批判的に検討しなくてはな！

>>14
漏れも〜

>>18
普通Cとかのコードを見て、あまり美しいって感じないよね。

while(*s++=*t++);
昔、これを見て泣きそうなほど感動したんだけどなぁ・・・

わかりにくコードを書くな！！>>20

最近はコードよりお絵かき（クラス図他）の美しさを追求してしまうな。

>>20 なんだこりゃ。いつループ抜けるんですか？

わかりづらいか？
そのまんまやん？

こんな駄スレに投稿している奴の気が知れない。

>>23
tのポインタが指す先の値が0になれば
ループを抜けます。それがsのポインタが指す
先に代入され、その値が評価の対象となるわけです。
ってまじレスしてどうすんの。
ここプログラマー板でしょ。

１へ

１に逢いたい。
今、この夜に、突然逢いたくなった。
訳も無く、理由も無く…ただ、１に逢いたい。
そう、心が求めてしかたない…

今、何をしてる？
もう眠ったか？
レスしようとした指が、一瞬とまってしまう。
「せめて、１の自作自演が見たい…」
俺の我が侭を、許してほしい

１のことを、こんなにも好きだったなんて
離れてはじめて知った。
淋しくて、切なくて、どうしようもない、苦しい…
「駄スレを見せて欲しい」「クソスレが見たい」

１が俺の心を占める。
俺の中に、１に伝えたくて伝えたくてしかたが無い
たくさんの言葉が交差してる。
吐き出しても、吐き出しても、次々に溢れでる言葉が
１への想いが…
枯れること無い俺の気持ちを、どうか聞いてほしい。
伝えたいことはひとつ。

「１が、好きだ。誰よりも。」

それだけだ。
１が、この間のように、少し驚いて
「俺にレスもらえて嬉しい」って、言ってくれたら
それで、俺も幸せなんだ。

繰り返す。「１が、好きだ。」
センスも、文も、その、クソスレも。
すべてが好きだ。

>>26 たったいま転職を決意しました。さいなら。

>>20のコーディングだけど、慣れればあたりまえのように感じると思うよ。

いいコーディングって何かというのは議論が尽きないところだけど、
少なくとも分かり易さという基準だけで判断するのは間違っていると思う。
「分かり易さ」っていうのは主観が入るし、万人にわかりやすいなんてあり得ないしね。
特に権力を持った人が「分かり易さ」を言い出すと、コーディングは逆にわかりづらく、
かつ一貫性のないものになりがちだと感じているのは俺だけかな？

>>20
これの TAILQ_LAST(), TAILQ_PREV() は、ちょっと感動した。
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/sys/queue.h?rev=1.43&content-type=text/x-cvsweb-markup

「わかりやすさ」にも3種類あると思う。
まず、
1.初心者にとってわかりやすい
2.中上級者にとってわかりやすい
3.自分にとってわかりやすい
であろう、
でも、結局の所、日頃、自分が良く使っている書き方が一番理解
しやすくて、なれてない奴だとかえって難しいだろう。

それに、コードの美しさも2種類あって、
1.初心者や一般の人にとって美しい
2.上級者にとって美しい
だろ、それで、
1.初心者や一般の人にとって美しい＝どちらかといと表面的な美しさ、
もしくは、内面的には良くわからないが、神秘的な美しさがある
2.上級者にとって美しい＝内面的な技術的な美しさのことで、
これはかなりの技術を持っている人はその技術がまるで芸術の如き
に感じられるもので、多分、一般の人には何がなんだかわからなくて、
かなりつまらないものに見えると思う。
結局の所、上級者にとって美しいことは、その芸術作品が見る人を選ぶ、
ということで一般の人にはあまり価値の無いものになるだろう。

要は職業プログラマか職人プログラマかってことでいいか？

>>32
職人を悪く言っているようで、安易には同意できない。
最近の技術レベルの低下には、そら恐ろしいモノがある。
ビジネス感覚も重要だろう…
しかしそれが招いた結果は？

>>33

> 最近の技術レベルの低下には、そら恐ろしいモノがある。

そうなんですか？
昔に比べて、プログラミング技術の書籍もWEBサイトも増えていて
情報量は多くなっているのだから、向上しそうなもんですが。

いや、技術レベルが低いのはウチの壊社だけかと思ってましたが。（苦笑）

教科書に載っているようなコードでは
飯は食えんのよ。

>>35
教科書にもよると思われ。

よい教科書を探せるのも実力の内と思われ

技術レベルの低下って言うのは全体的なことではないかな？
これだけプログラマーの数が増えてしまって、教育とか経験を積む
時間もないわけだから、全体的なレベル低下は避けられないと思う。
しかし、やはり中には優れた人もいるわけで、そういう人のレベルに
合わせるように底上げされればいいのだけれど、現実は逆で、
プログラムのレベルは全体的なレベルに合わせて作られることが多い。
そういうことがまた優れた人のやる気をなくなせているという悪循環
なんだよね。

>>35

いやいや、情報量が増えているのは入門／初級レベルだけの話ではない
と思いますが？
もっとも、全然勉強しない人が多いのも事実ですが・・・。

そういえば、コメントの美しさも実力のうちだよね。
教科書〜で言えば、教科書レベル(以上)のプログラムを書ける人は
尊敬します。あとで本やWebみて「あちゃー。こっちのが綺麗やん。」
というのはままある話。(-:
# まだまだ修業中。

>38
あぁ、自分のこと優秀だとは思っていないけど、それなりに出きるつもりではある。
私は、あなたの言いたいことを実感しているプログラマの１人です。

今のプロジェクトC++使ってるんですが、
C++(っていうかC)が分からない人のために
・ポインタ使っちゃダメ。
・構造体使っちゃダメ。
・規定外のクラス作っちゃダメ。
・継承なんてもっての他。
っていう規則があります。

で、どーしろっちゅーねん！！って感じでやる気起きません。

っていうか、下に合わせようっていう風潮で技術力が向上するわけ無いじゃん。
マジで会社を変えようと思っているところです。

>>41
ポインタ使わないでCのプログラムを書くのは難しいな (w
表面だけでも配列の形式にすればいいの （WWW

あ、規定内のクラスとリファレンスを使って書けばいいのか!
うんうん、リファレンスがあればなんとか。
そういう問題ではない？

ロンドンの黒魔術師が呪いをかけて作ったサイトです。
3分以上見ると「死」にます！！　マジネタです！！！
体内の細胞が変化を起こし急逝心筋梗塞を起こします。
最初は頭痛がしてきます。
そして、左の男の目が赤く見えてきたら危険です！
その後は・・・・・・・・。

http://www.mayhem.net/juke/bodiesbeat1.html

他にもいろいろ感涙コードいっぱいあるんだけど・・・時代なのかなぁ。

最近はコンパイラも賢くなって最適化とか神懸りチックになってきたし
年寄りには色々きつくなってきたけど、やっぱりプログラミングはイイよ。
４０超えても楽しいもんは楽しいって。

>>30
見てみたけど、ちっとも感動できなかった…。

>>38 >>41
職業プログラマは大変だね…。

>>1
よいコードを書きたければ
自分の書いたコードよりよっぽどいい方法があると常に思ってましょう。

>>35-36
教科書のコードっていってもいろいろあるしね。

>>41
VB使え（゜д゜）ｺﾞﾙｧってな感じの規定ですね（藁
でもCでポインタ不可縛りで組むのも面白そうかも(w

〜縛り、ってなんか罰ゲームみたいで面白いな。
ifつかっちゃだめ、とか。

for,while,goto使っちゃだめとか(w
再帰で号

そういや goto は禁止されてたなぁ。
goto 使った美しいコードってないのかな？

>>41
そんな規則無視しろ！分からない奴が悪い！
おれはC++勉強して1週間目で継承つかったぞ。
趣味で。

>>54
オマエが内定ないのも理解できるよ

>>41
その仕事って何かの罰ゲーム？
その仕事って何かの罰ゲーム？

>>53
exit()を使いたくない時(dllなど)で、かつ、解放しないといけない
リソースが多いような時は、goto使うと綺麗なことも多いみたい。

>>46
TAILQ_PREV() は、以前は次のように定義してあった。

#define TAILQ_PREV(elm, field) ((elm)->field.tqe_prev)

これと >>30 を見比べると、ちょっとうまいと思わん？

>>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はなんちゃってか？

金融系のバッチ処理にアクションゲームのフロー放り込んでみたら
めちゃめちゃ性能でた。
ＤＬＴの速度がボトルネックになっちまったけどな(ｗ

>>1
わかるよ。その気持ち。
きたないコードばかり見てると、ついつい自分のを見てしまう。
ｅかげん疲れた。メンテはいや。おれに作らせてー。＞ リーダー

入社前からシコシコプログラム書いて悦に入ってたような
ヲタクはこういうナルシストばっかでタチ悪い。

本人は芸術のつもりか知らないけど、メイテナンス性最低の
コードばっか書いてくれる。他人が簡単に手を入れられない
ようなソースは産業界ではゴミ。趣味でやってろバカ。

この手の「プログラム命」みたいな職人気取りの低学歴を
採用するくらいなら、プログラム経験ゼロのそこそこの大卒
を３ヶ月仕込むほうがずっとよい。

>>64
張飛型かぁ・・・。
自分も昔はそうだったなぁ･･･。

零細企業でなくて、比較的大きな会社であれば、
64さんのようなタイプを沢山そろえた方がいい。

話は変わるが、歴史的に見てもこのタイプの戦
略を取った軍隊の方が勝利を多く収めている。

あとは企業のお偉いさんや、お客などにこの意
識が広がり、

　リストラ　＝　コスト削減

の構図が崩れれば、もっとＰＧの
メンテナンスは容易になるだろう。

>>66
>あとは企業のお偉いさんや、お客などにこの意
>識が広がり、

無理無理。
国内企業の客やお偉いさんには、袁術が多いもん。

>>64
君の意見をオープンソースコードの人らが聞いたら
切れるだろうな

>>64
> この手の「プログラム命」みたいな職人気取りの低学歴を
> 採用するくらいなら、プログラム経験ゼロのそこそこの大卒
> を３ヶ月仕込むほうがずっとよい
ま、やってみ。どっちも変わらんから。

ツーかスレ題とかんけーねーねーねーねーね。

　　if(.....){
　　　　/* 偽の処理 */
　　　　return FALSE;
　　}
　　/* 真の処理 */

　　if(....){
　　　　/* 偽の処理 */
　　　　return FALSE;
　　}
　　/* 真の処理 */

　　return TRUE;

>>70
たのむからreturnはひとつにまとめてくれ！
デバッグしにくくてしょうがないんだよ！

>>71
１関数１リターン主義なの？

>>72
そんなわけじゃあないが、分散されると見にくくないか？
エラールートにreturnがあるのは構わないけど、
エラーならエラー、正常なら正常でそれぞれひとつずつくらいに
return は絞った方がブレーク張りやすいし。

>>73
returnを一つにまとめようとして、逆にわかりにくいコードを見たことが
あったので、すっきりするのならどっちでもいい

正常ルート（終了は常に関数の最後）と
例外ルートを分散したほうがソース見易くないかな？
これってそんなに変な書き方？
変なら今後直そうかと思うんで・・・

>>75
変じゃない。ただ、例外ルートは例外ルートで
まとめられるならまとめた方がいい。と思う。

>>64 の文章は、優秀なプログラマが書いたものか、
ヘボプログラマが書いたものかで解釈が大きく変わるな。

>>77
ヘボな奴のメンテ性ほどシビレル論理も無いな(ﾜﾗﾜﾗ
64がそうとは言わんが。

かといって構造化オタもイタイ。

>>61
アセンブラになったとき、たいていの場合60の方が有利だよ。
リターンをいちいち変数に突っ込むなんて、MOV系の命令が
余計に入っちゃうでしょ。たとえば、この関数が一定時間に
すごい回数呼ばれるような状況があったら、MOV1回の違いが
パフォーマンスに大きく影響してきます。
（普通、そういう部分はコンパイラまかせにしないで自分で
アセンブラで書いちゃいますが）

プログラムは、当然メンテナンスのしやすさも大事だけど
スピード、リソースをいかに使わないで同じことが出来るかが
とても重要ですよ。職業プログラマなら、普通それを考えますけど。

最適化したりしてプログラムが読みにくくなってきたら、コメントの
数を増やせばいいだけのはなし。ぜんぜんコメントも入れずに
ただだらだらとプログラムを書くやつは最低ですね。

>>79
最適化作業は後回しの方がいいと思うよ。
機能テストが完了した時点で最適化作業をしても
バチはあたらないと思う。
アセンブラレベルでデバッグするときならなおさら
returnが一箇所にまとまってないと戻り値のログが
とりにくくってしょうがない。と思う。

>たとえば、この関数が一定時間に
>すごい回数呼ばれるような状況があったら、MOV1回の違いが
>パフォーマンスに大きく影響してきます。

……いったい何千万回呼ばれればパフォーマンスに影響するんで？
いや、あたしゃ>>61で挙げられてるような書き方は
（単なる好みの問題で）やらないけど。

>>81
「バイナリになったときに性能がいい」という煽り文句には、心惹かれてしまいます。
たとえほんの数クロックしか高速化しないとしても。

>>72
バグが出たときに、現場の人と修正担当者が
頭抱えて悩む時間をクロック数にすれば、
大体、どういう風に書いたほうがいいのか決まります。

あちこちでbreak outするコードを書くと
メモリリークなんかの、見つけづらい系バグに悩まされる
確率高いです

>>81
けっこう影響するよ。制御系なら。
それ以外で影響する場面は俺も知らない

Cだとリークの問題はあるけど、基本的にそのあと何もしないのに
関数末尾のreturnまで処理を飛ばすのは逆に可読性を落とすよ。
try {}finally{}があればリークは関係なくなるからがんがんreturnするね。
あと、elseを略すべきか否かは、それぞれの条件における処理のレイヤが意味的に
等価な場合は略さない方が見やすいでしょう。
関数の処理を打ち切る(後続とは明確に異なる)という意思表示のためにelseを
省くことはある。
例:
if (condition) {
:
} else {
:
}

if (!isEnabled) {
return;
}
:
前者でブロック内の処理が一定以上あって、その後何もしないなら、ブロック内でreturnして
しまった方が後続を見なくてすむ分読みやすいです(当然主観)。
しかし、そんな場合そもそもブロックないを関数化してしまうので、その必要性もあまりない
ともいえますけど。でも、結局
if (condition) {
return processTrue();
} else {
return processFalse();
}
みたいにするかな。

>>79
わかりにくくてすまそ。
個人的には、if-elseのペアや１関数１returnに拘ったりはしない。

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();

>>1は
ttp://www.ioccc.org/2000/anderson.cや
ttp://www.ioccc.org/2000/bmeyer.cや
ttp://www.ioccc.org/2000/dlowe.cや
ttp://www.ioccc.org/2000/thadgavin.orig.c
に対抗できるなら応募してみるのも良いかも。(w

>>20
タダのオナニーにしかすぎんと思うけどどうよ？

おそレススマソ。

プログラマー＝理系の変態

>>1
if (p*~v^_* q/*やったね！*/)
こんなコードか?