1: 名無しさん
全然知識ないけど見辛いとかあるんだ
2: 名無しさん
たぶんサイゲ社内の実話
3: 名無しさん
個人でやるならともかく仕事や共同作業なら可能な範囲で読みやすいコードを書くのは義務だ
4: 名無しさん
いわゆるスパゲッティコードってやつかな
本当にそんな見にくくなるもんなんだろうか
本当にそんな見にくくなるもんなんだろうか
5: 名無しさん
6: 名無しさん
自分でやってる内は問題なかったから…
11: 名無しさん
何がやりたいのかっていう思想が書いてないとわかりづらい
12: 名無しさん
研究機関出身とかだとマジで書かないんだよなコメント…
あとワンライナーに詰め込むほうが美しいと思ってるやつ
あとワンライナーに詰め込むほうが美しいと思ってるやつ
14: 名無しさん
自己満足としてのスマートさと可読性保守性は別
15: 名無しさん
ズブの素人からすると同じ動作するもん作ればだいたい同じ文になるんじゃないのかって思っちゃうのよ
23: 名無しさん
>>15
キッチンにラベルの付いてない白い粉が入った容器がいっぱいある感じ
キッチンにラベルの付いてない白い粉が入った容器がいっぱいある感じ
20: 名無しさん
自分がわかればヨシ！
21: 名無しさん
>>20
自分でもわからなくなる！
自分でもわからなくなる！
25: 名無しさん
>>21
だからコメントを残しておくんですね
だからコメントを残しておくんですね
24: 名無しさん
29: 名無しさん
可読性を犠牲にしている
至言ですな
至言ですな
31: 名無しさん
N日前に書いたコードは他人が書いたコードだと思えが格言としてある時点で…
41: 名無しさん
コメントはマジで入れろ
88: 名無しさん
一度コメントは要らないから消せって言われたことはある
91: 名無しさん
>>88
そういう思想もある
そういう思想もある
92: 名無しさん
>>88
そいつ退場させてぇ～
そいつ退場させてぇ～
94: 名無しさん
他人事だから笑えるが自分も人のこと言えないわ…
116: 名無しさん
任天堂で作るゲームコードの綺麗なやつと汚いやつ
121: 名無しさん
>>116
左右同じプログラムなの
左右同じプログラムなの
123: 名無しさん
>>121
やりたいことと結果は同じ
やりたいことと結果は同じ
117: 名無しさん
こういうのって構文が短いとプログラム早くなるとかあんの？
125: 名無しさん
>>117
そうとは限らない
だから難しい
あと結果としては同じ動作だけど二度手間になって重くなるとかもある
ちゃんと勉強してないとそこら辺がいい加減になってどんどん見た目も分かりづらく処理も重くってなって行く
そうとは限らない
だから難しい
あと結果としては同じ動作だけど二度手間になって重くなるとかもある
ちゃんと勉強してないとそこら辺がいい加減になってどんどん見た目も分かりづらく処理も重くってなって行く
126: 名無しさん
基本的に他者にソース見せるってしてなかったんだろうから余計にきったねえよって怒られてるのはある
まあトークイベの諸々を見るに博士がその辺りかなり雑なのはあるんだろうが…
まあトークイベの諸々を見るに博士がその辺りかなり雑なのはあるんだろうが…
129: 名無しさん
今はいい時代になった
Aiに読ませればエラーチェックしてもらえる
Aiに読ませればエラーチェックしてもらえる
131: 名無しさん
「コメント消したら動作しなくなるから消すな！」みたいな現象もあるらしくてなんでそんなこと起きるのかちんぷんかんぷんだよ
35: 名無しさん
動けばヨシ！！！！！
動かない…
動かない…
1000: 名無しのトレーナー 2018/01/01(月) 00:00:00.00 ID:umamusume
→
→
→
→
→
→
コメント一覧(112)
（あれ！？ ずいぶん話のレベルが高いな）
わかんない人からしたら、ワイがゲームガチ勢のやり取り見聞きしても何のことやらちんぷんかんぷんなのと同じ感覚なんかな
ヨシ！(よくない)
バグを利用したコードとか止めてください、誰も理解できないんです
ナーシャさんの悪口はやめろ
スクとエニが合併してドラクエを初めて内製にしたとき真っ先に「俺が書いた」じゃなくて「後から他の人が読めるように書く」に矯正したって言ってたわ
ナーシャはもうとっくに帰った後だし合併してからも相当経った後だけど、そういったスター性のあるプログラマーへのリスペクトや憧れの気風は長く残ってたらしい
まあコメント信じてたのにコメントが間違えてるってのもありますし
コメントを信じて改修したコードがうんともすんとも言わなくなって
S木君の鎮魂歌が聞こえてくる事になるなんて・・・
//ここを通ることは絶対に無いけど一応処理書いとくね
↑普通に通るしバグの原因じゃねーか！
普通はそこにエラートラップを置いとくもんだけど、
他の条件下で呼び出されることが予想される場合、処理を書くこともあるな。
処理修正したけど軽微だしコメント直さなくても見りゃわかるだろ
なおその後
バージョン管理システムは絶対使おうね！
でもそういうところも博士の魅力なんだよなぁ
// なぜか動く
/* なんか知らんけどこのprint文消すと動かなくなるので消すな */
いっちゃん困るやつ
過去の自分が書いたコード→この変数なんだっけ？ここの処理何がしたいんだっけ？
AIに書かせたコード→コメント細かく書いてあるし分かりやすーい！
動いたからヨシ！
→アップデートで新機能を追加します！
→もうだめぽ…
左は爆弾かなんかですか？
博士は今まで一人でやっていたから自分が分かれば良いと思ってるんだろうね。
でも、共同研究することになったからこういう話が出たと・・・
研究にせよ仕事にせよ、基本複数人でやるものだから、分かりやすくするのには越したことはないけどね。
個人プロジェクトあるある。
とりあえず、動く事が優先で、他人が読むことを想定してないやつ。
シャカールと悲しみながらリファクタリングしたい
私は自分が数日前に書いたコードすら何がやりたかったのか忘れることあるからコメント必須です
というか会社なら製造するうえでどういう風にコード書くとかどんなコメント入れるとか規約ない？
情報、IT系なら当然ある
例えば電気とか機械エンジニアで、個人ツールとしてのプログラミングだとそういうのはなかった
おしごと的に（正式業務として）数値計算する場合でも、個人の裁量で全て済まされた
あるね
C言語とかならK&RとかLinuxカーネルスタイルとかBSDスタイルとかGNUスタイルとか
フリーソフト、OSSでもその開発コミュニティの中で自然と固まったスタイルがある
急いでたり適当にやってると3日前に自分が書いたコードの意図が全くわからないのあるある
わかる方が大事なのでコメントなんかガンガン入れたらええ
プログラミングの世界は楽しかった、だからこそ仕事にはしなかった、出来なかった。
自分が楽しいことをわざわざ仕事にして、つまらない感情にしたくないからだ。
趣味で書いて動かして楽しむ分には可読性とか二の次でも良いし、最速最軽量で動くならそれに越したことはない。
AIの台頭でプログラマーが楽しんでいた作業をAIに奪われて嫌な作業ばかり人間に押し寄せてきておまけに仕事は増える時代になってしまった
プログラマには２種類ある。クリエイターとIT土方。IT土方の仕事は「自然言語で書かれた仕様書をコンピュータ言語に翻訳する」ことだから、自動化されることが正しい。
自然言語間の翻訳(日本語-英語など)と違って、コンピュータ言語には動作に複数解釈の入り込む余地がない(あってはいけない)。つまり、そもそも複数解釈などできない厳密な仕様書を用意する必要があって、IT土方はそれをせっせと翻訳してるに過ぎない。
プログラマが「楽しんでいた」作業というのは、全てクリエイターとしての範疇にある。
IT土方はただの下働き。要求されるのはコンピュータ言語に翻訳できることだけで、コンビニ店員のルーチンワーク(と突発的なクソ客対応)と変わらない。
とはいえ
自分の思った通りにプログラムが動作すれば、それは嬉しいんだけどね。
それは基礎技術の修得でしかないから。野球で言えば「無死走者なしで内野ゴロ打たれたら捕球後1塁に送る。他は1塁フォローに入る」といった基礎の手順を覚えただけ。コンビニなら弁当を買う客に温めますかと聞くようなもの
ルールを覚えるだけで面白いのは観客と戦力外の初心者だけで、戦力として勝ちを目指す前、”プログラマになるための準備をしている”段階。戦力になって勝ちを目指してる”プログラマ”が面白いわけじゃない。
オフショア開発とかといっしょで作り方に口出せないのに品質と納期は保証しないといけないのは神経削れるわ
昔の買い切りのゲームならともかくプログラムというのは場合によっては10年20年以上手を加え続けることになるから、グチャグチャでもいいからスピード命で作らせたりすると却って高くつくのだ
AIでこの先どうなるかは分からんけど少なくとも現時点では完成速いけどあとから手を加えるの辛えよって事態になるケースが課題になっている
余白にミュウを一つまみ…ｗ
今思えば超危険行為
だけど結果的には超ファインプレー
デバッグプログラムを削除した領域にマスターアップ後に仕込むというヤバさ限界突破の所業なんですが…
余白に上司への愚痴と下ネタをひとつまみ…w
えりかとさとるの夢冒険か…
あれはやりすぎなんよ
攻略本に盗める可能性を一つまみ…
決して許すな
似たような処理を共通化するのはいいけど
共通処理を通りまくるせいで処理追うのが大変なのは勘弁してください
あと共通処理に例外を入れまくってめっちゃ肥大化してるのはもっと勘弁してください
本末転倒だよね
あとそういうプログラムってオーバーヘッドやメモリコピー多くて遅い
コード量を圧縮させるような共通化は大体悪だよね。ある程度冗長にしてしまった方が保守性も拡張性も高くなる
ウマ娘では多分アオハル杯でそれやって、大きなバクを出してしまった
読めば分かるけどどことどこが繋がって作用しているか分かりにくいコードというのは画面をバーン！ってしたりマウスをダーン！ってしたくなりますね
追っているうちに頭が真っ白になることがあります
読みやすいコードは全体を見ても流れが分かるものなんです
もう一つ挙げると細かく切り過ぎても繋げ過ぎても分かりにくいという点では、小説の句読点の使い方の良し悪しに似ているかも知れませんね
最適化できたぞ！なんて効率的なコードだ！
1か月後…
機能追加するか…なにこの暗号
個人開発勢はこれ連発しちゃいます
複数人開発やった事ないからだらけちゃうわ
Linuxカーネルとかの大人数が参加しているOSS開発コミュニティだと、読みにくかったり意図がわかんないコードのあるパッチを投稿するとボロクソに叩かれるから鍛えられるぞｗ
その筆頭格がLinuxカーネルの産みの親ことLinus Torvalds。
直接会うと非常に温厚な人柄なのに、ちょっとでもわかりにくいコードをコミットしようとするとものすごい剣幕のメールで叱責される。
誰かが「あれは竹中直人の [笑いながら怒る人] だと思えばいい」と言ってたが、まさにその通り。
私は別にちゃんと動くならなんでもいいです
弊社のシステムのコードは汚くて遅くてバグありです
全くの門外漢だが個性がかなり出るらしいな
同じ動作でも極限まで簡素とか動くのが奇跡レベルのクセ強とか
複雑だから高度でもなくシンプルだから軽快なわけでもない
文系事務屋さんワイ
ニコニコとわかったふりをしてこのスレを眺める
自分の机をきちんと整理整頓してるかどうかみたいなもんだ
お前の会社にもどこから数値が飛んでどう計算されてるかわからないエクセルシートの一つくらいあるだろう
結局はそれと同じ話だ
そういった呪物に出会ったことがないならよほどデータの取扱がうまい会社かよほどデータの取扱がひどい会社（まともにEXCELすら使わない）のどちらかだ
・ローカルな略語だらけで部外者が理解できない手順書
・なぜやっているかは承認者すらわからないがやらないと稟議が通らない作業
・似た作業の担当者がバラバラ
・秘伝のタレ
#ここを消すとなぜか動かなくなる
今までで一番「イラッ」っと来たのは、インデントに何故かタブとスペースが混在してた事かな
これがCやVBみたいな基本的にはタブ使えって言われてた昔からある言語でさ、複数人がメンテしてとかならわかるんだけどよ……
なんで4文字スペースが標準のRustでタブ使ってんの？？
しかもGit見たら一人しか触ってないのになぜ？？？
外部からコピペしてきたとか？
多分エクセルからコピーしてきている可能性もある
あー、あるあるｗ
エディターでtabで自動で空白インデントにしてくれてたのが、たまにその機能切れててtabになったとか、viとかの別のエディターを使った時だけtabになったとかかねぇ
大学時代に過去の先輩たちの研究引き継いだ時に研究で使ってるプログラムも引き継いだけど長年個人レベルで好き勝手に継ぎ足してたみたいでマジで何書いてあるかわからなかったわ
先輩に聞いても先輩もわからないからもうお手上げだった
とりあえず動くからヨシ！でやるしかなかった
秘伝のソースは皆在学してる間だけ使えればいいからメンテしてないしする義理もないからね仕方ないね
仕方なくねえよ吹っ飛ばすぞという怨嗟もまた受け継がれていく
代々継ぎ足してるラーメン屋のスープみたいやなｗ
何をやりたいのかコメントとかで書いてないとわかんないよね
Pythonが流行るわけだ
インタプリタの話なんかしてないだろうけど
冷静で理知的な大人だけどそれでいて隙が多いの可愛いよね
可読性なんてマナー講座みたいなもん
実際に見やすいかどうかじゃなくて、誰かがこうすべきって言ったやつに従ってるだけ
仕事すると自分が見づらくても言われた通り書かないといけない
プログラミングセンスの無い人間は、コメントのセンスも無い。
# 配列の0〜i-1番目まで繰り返す
とか
# 引数param(0)を変数pに代入する
とかのコメント残すやつは死ねと思う。
そのぐらいなら頑張って覚えようとしてるんだなー程度で済ますわ なんなら微笑ましさすら感じる
それを書いてるのが40過ぎたオッサンだったら？
髪を毟る
わかるｗ
そんなのはコード見ればわかる
「何のために」繰り返してるのか、その引数は「どんなデータなのか」を書いて欲しいんだよな
プログラムの書式書いてるだけのコメントでは情報量ゼロなんよ
なんで動かねぇんだよ…←まだマシ
なんで動くんだよ…←ガチでやめろ
不発の爆弾状態だな
OSやライブラリのアップデートで動作しなくなったりする
元プログラマワイ、コメント見ると有る有る過ぎてニッコリしつつもクソな日々を思い浮かべて少々鬱
今はコード読めるけど書けなくなってしまった
ワイはそうなるのが嫌で転職したけど、転職した先でも結局書けない人だらけでコード書く仕事がほとんど発生しなくなった・・・
お前の変数のネーミングどうなってんだよ中身わかんねえよ！！！１
let hoge = 0, fuga = 1, piyo = 2;
hoge
hoge2
hoge3
hogehoge
hogehoge2
hogehoge3
実際に見た
逆に新人がJavaで変数名に「日本語」を使ってきたときは頭痛くなったｗ
何人もが繋ぎ足した、カオスの極み・・・その造形を楽しむのもまた良し・・・と、言えればいいんだけどねー
何かプログラムのことになったら急に空気が殺伐としてきたな……ちょっと漏らした
誰が呼んだか
プログラマ界隈、略して『マ界』
むしろシャカールこそスパゲティコード生産しまくってそうという偏見を持ってた…
リーダブルコードガチ勢だったのか、お見それしました
やる気ダウンイベントに他人のスパゲッティコード解読させられてブチ切れというイベントがあるぐらい最初から可読性重視のプログラマーだぞ
どこの会社にもあるもんだよね
「なんで動いてるかわからない。わからなかいから誰もどこもいじれない」ってブツが
1行で収められるけど可読性やメンテを考えると7～10行くらいに分けて書いた方がいいよねってあるある
AIに頼んでもよくならないどころか動作しないことも普通にあるからなあ
その辺難しいね、プロ同士なら話できるんだろうけど。
// 当店ご自慢のパスタです
今の業務でソースコードとにらみ合いしてるけど仕様書と細部が違い過ぎてイライラが募ってる
全部書き直したい
ライツ博士ってGitとか使ったらデグレ起こしたりしそう
インデントはちゃんとしろ
ループを入れ子にするな
変数名はちゃんとつけろ
モジュール化するときはシンプルにしろ
コメントをちゃんと入れろ
RPGツクールレベルの話だが、なんで突っ込んだのか後になって思い出せないけど、それを消すと全体の挙動が大きく変わってしまうイベントが多数発掘されることがある
AIはコードを書かせるだけじゃなくて既存のコードをぶち込んで何やってるコードなのか教えてくれるのがすごい
なんならそれを整理してコメント付きで書き直しまでしてくれる
AIの後ろでシャカールがブチ切れながら直してくれてるかもと思うと、なかなか感慨深い。
AI君って要求に対してそれっぽい回答をだすからみんな間違うタイプの問題で間違えたりしやすかったりするけど、ひと手間かければよくなるけどめんどくさいなってことはちゃんと指示すればさぼらずやってくれる傾向があるからやっぱ使い方なんだよな
// フリオーソ
// このコメントを消すと何故か動かない
if (1) {
}
return 0;
Shift-JISだとコンパイラ次第では↑みたいにコメントを消すと動かなくなるパターン作れるのか…
初めて知ったけど理由を見たら納得した
言うてこの例って、一般的にイメージする「なぜか消すと動かなくなるコメント」と違うように思える
この例だと、コメントを2行まとめて消しそうに見える、そうすればちゃんと動く
もっとポツンと1行謎のコメントがあるイメージだった
シャカールも自分の運命を捻じ曲げるまでは「原因不明、ソースコードなしのバグ」に悩まされてたからな
COBOLやらされていた時に1回だけあった。作った人捕まってニュースになっていたんで人柄出るなとは思えた
>こういうのって構文が短いとプログラム早くなるとかあんの？
速いプログラムってのは、プログラムがコンパイルされてマシン語になり、CPUとメモリ、I/Oをどのように使って動作するかをイメージ出来てないと速いプログラムは書けない
メモリは極力コピーしない、ループの多重は必要最小限にする、関数や割込みの呼び出しもなるべく少なくする、マルチスレッドのセマフォなどによる直列化区間は最低限に短くする、ものすごく使用頻度の高い小さい共通処理はアセンブリ言語で書く、など
速くするためにコード自体は長くなったりもする
たぶん、そういうのはAI生成じゃ出来ない
とはいえ、今時は実行時最適化とか先読み実行とかも当たり前の世界なので、ソースコード側での最適化はかえって逆効果なことがほとんど。
どっちかというと素直に実装して「あとはランタイムにお任せ」のほうが速い。
お任せのが速いというか、昔は条件によって処理を変える際の条件分岐コストを嫌ってメモリ上の機械語コードのほうを直接書き換えるみたいな涙ぐましい努力してたけど、そういう芸当がどんどんCPU側の保護機能やらキャッシュ機能やらで封じられた結果もうお任せする以外にはなんもできなくなったというか
自分はあんまりコンパイラの最適化は信用してないなあ
かつてカーネル開発者だったせいかもしれないけど
C言語だけじゃなく、Go言語でも標準のnet/httpモジュールよりはメモリコピーを極力減らしたfasthttpモジュールを使った方がかなり速かったりするんで、まだ人の手のノウハウ介在の余地はあると思う
コメント:a+bをcに代入する
コード:c=a+b
ちがう、あってはいるがちがうそうじゃない
改行とかTabとかで揃えるとかな
でもソース言語で揃え型が違って結局わかり難いんだ
コード解り辛い奴が書いたのはそいつが居なくなると崩壊するとかよく見るな
仕事でCOBOLを触ることなってJavaやC♯、Cですらお行儀のよい素直な言語だって分からされた、もちろん治安悪くもできるけどさ
しかも代々継ぎ足してきた秘伝のソースでコメントも全然ない
大したことはしてなんだけどずっと目が滑ってひたすら辛い
COBOLはプログラミング言語と自然言語の悪いとこ取りだからな・・
プログラミング言語として見た場合、定義(いわゆる「お約束」)は省略してはならないが、
自然言語として見た場合、定義は適宜省略され、前後の文脈からの判断が多数生じる。
なので自然言語をプログラミング言語に持ち込むと、非常に長ったらしい読みにくいコードになり、そこにコメントでも入れようもんなら、さらに長ったらしくわかりにくくなる。
わしも信金システムの保守でCOBOLやっとるけどマジつれぇわ
別にええやろコメント書いても書かんでも
どうせ次の担当も俺なんやし
俺の先輩方は皆ポンコツやし、上司・・・課長のあいつもパッとせん、部長は論外
新人くんはなあ・・・態度があかんわ
退職前のおじいちゃんと反対やったらよかったのになあ
そんなんだから天与呪縛のフィジカルギフテッド(AI)に負けるんだぞ
ちゃんとやったはずなのに動かない
より
ちゃんとやってないはずなのになぜか動く
方が怖いと聞く
何が原因でいつ動かなくなるか分からない状態だからな