プロのプログラマーって他人のコード見て「美しくない」とか言うの?
■ このスレッドは過去ログ倉庫に格納されています
演算子の前後にスペース入れないやつには殺意を覚える 他人の作ったコードが良いと
「やりますねぇ!」とか思う 見やすい見やすくないは思うけどコード見て美しいとかよく分からん バグって酷い目にあった書き方を大抵体で覚えてるから、酷い書き方見ると嫌な事を思い出す まともな環境でIDE使ってりゃ保存時に規約にそってコード整形してくれるからインデントがずれてるとかあんまりなくないか?
訳分からん変数名とかネストが深いとかそういう意味での見づらさが大半な気がする モダン環境でしか開発したことないので限界集落の事は分からんすなぁ 本当に頭のいい人の書いたコードはマジで美しい
多分>>1が一切の知識なく見てもある程度わかると思う 有名なOSSとか見ても美しいとかよく分からん…
感性の問題だろうか 他人が書いたソースなんかいちいち理解するつもりはないから好きに書け edのソースコード読んだことあるけど、関数ポインタの配列作って、キー入力の値(つまりアスキーコード)を引数にして処理ルーチンに飛ばして、キー入力処理してた。 ぶっちゃけOSSとかライブラリのソース見ても美しくないコードは多い >>10
これだなぁ
コンポーネント設計とかアーキテクチャ設計とかだと
ものによって関心させられることはあるが 自分が美しいと思って書いたソースを翌日に見てそう思うことがままある >>22
比喩みたいなもんで一般的に可読性が高かったり効率の良いコードを美しいって言ってるだけだぞ
美しい絵画とか景色見た時の感情と同じではない 美しいかどうかはある
でもそれはGoFのパターンがちゃんと実現できてるかどうかって事だから
デザインパターンになってないプログラムを見て「美しい」とか言う奴絶対にハッタリ
プログラムにおける美しさとは合理的な必然性を説明できるって事なので
GoFの通りに作ってあったら何が美しいのかを説明できるんだよ >>31
これはどうかなぁ
別にシングルトンパターンやファクトリパターンやらetcで書いてたら美しいってわけじゃないし
クラス/レイヤー間で責務が分けられてなくて依存関係ぐっちゃぐちゃだったら保守できないゴミだってはっきり分かるけど >>33
シングルトンを一度でも作ったら作り方など無限にあることが分かるはずだ
その無限の中でより理念に近いものを美しいと呼ぶ VBAだけどうちの職場ネストが8くらいあってコメント無かったから絶望ですわ >>34
そうそう。そこはちゃんと強調しておきたい
デザインパターンかじって表面だけ読んでコード例をトレースしたようなのは読みづらかったり後で拡張したい時に融通効くようになってなかったり…
理念をちゃんと理解してる奴が書いたのとは雲泥の差がある
その「理解してる奴のコード」の中でも頭いい人が書いた奴は本当にひと握りかもしれんがマジで美しい ifとかforが何重にもなってるのって実際対処のしようがあるの? なるほどなるほど
じゃあ花火職人の人は花火大会で「へっ。汚ぇ花火だ」と言ったりするのか。浪漫溢れるな var1、var2、var3...、var500
くらいまで全部この名前の変数が
グローバルに置かれてて
全てのコード、関数からこれをいじりまわす
という糞コードをメンテすることになって萎えてた時
コードの初めの方に
class Unko{
Unko(){}
}
という空クラスあって
「こういうのは消せよ、もう…」と思って消すと
Unkoクラスが見つからないエラーになる
俺、うんこ入りのコード弄るのかよ…って気持ちになった 学生のコードとか見ると教授の変な癖とかうつっててガチで汚い ■ このスレッドは過去ログ倉庫に格納されています