ゲームプログラマの人に聞きたい 32問目

５０代の元プログラマ現管理職＝岩田聡

>>952
カリスマやんｗ

楽しいバレンタインの季節がやってきました。
プログラマは頭の良さそうなカッコイイ人達ばかりなので女性にモテると思うのですが
どのくらいチョコ貰えたり女の子お持ち帰りできたりするんですか？

>>934
なにこれ？ex-boardのほうがいいし

チョンの作ったボードなど使いたくない

>>937
将来が無いなんて感じてないから答えられない。

将来があると思ってる奴は、意欲に溢れた奴か馬鹿。
将来がないと思ってる奴はただの無能。

未来は自ら切り開くといいたいんですね

あの・・・バレンタイン・・・

将来はあるさ
潰れる将来があるだけで

>>954
喪男に配慮して貰ってないフリをしてるが10個前後は貰ってる。

という妄想で抜いた

>>959
将来が無いと思ってるならさっさとやめて転職すればいいのに
それが出来ないっていうのは無能に他ならない。

今から就職作品送ろうと思います

コードには注釈文を入れまくった方がいいですか？

それとも必要最低限のところだけのほうがいいでしょうか

コメントが無いと見る気がしない。

>>965
沢山入れるのが、（就職作品ではなく）将来の君のためだ。
適切なコメントを書くのは大変難しいが、努力で少しは良くなることだから、今から練習を始めよう。
ついでに、行間に無用な改行を入れないようにする訓練も今のうちにやっておこう。

>>967
むしろ行間に改行無いソースは糞ソース。

レスありがとうございます！

ヘッダーファイルとソースファイルで同じ様な注釈文入れるっていう
大バカなことだけはするなよ？
絶対落ちるぞ絶対

>>970
わかるｗ
たまにいるよねそういうやつｗ

Doxygenなり何なりのドキュメントジェネレーターに準拠したコメント入れとけ。
そうすると得点高いぞ。

>>970

なんでダメなの？

そうか？
コメントが自分だけの物じゃないって言ってる以上
ヘッダーの宣言だけ見る人間も居るかも知れないじゃん

俺なんか他人のソースで改造とかやらされるけど
はまらない限りヘッダーしか見ないからヘッダーにコメント欲しいタイプだが
ガッツリ調べる時にソースも見るから確認する意味でも両方入れといて欲しいと思う

両方に同じ事書いてあっても別にいいともうが？
逆にコピペの手間一つで、他人にやさしい事だと思うけど…

>>973-974
変更の手間とか更新忘れの危険性も考えてみろ。

同じコメントが２つあるというだけで正しく保守できる自身は無い。
むしろ、必ず更新し忘れるという自身があるぐらいだ。

ごめん。 ×自身 ○自信

C++で例えるなら

cppに詳しい注釈書いてヘッダー部分は大まかにかけばいいと思うよ

>>975
どんな理由かと思えば…
自分の無能ぶりを自信たっぷりに理由にされてもなｗ

それ、俺バグ出す自信があると言ってるのも同然じゃん
自分のコード＆担当したコードくらいメンテしっかりやれよｗｗ

>>975
そんな理由じゃお前はコメント云々語る資格はない

>>978
仮に自分が正しく保守できるとしても、全員がそれをできるとは言えないだろ。

重複したコメントがあるソースは迷惑。

>>978-979
実際そういうことが頻発するから推奨はされてない。

普通は>>977でしょ。

コメントのメンテも出来ない奴が
ソースとコメントの連動が出来ると思えないｗ

つまり、コメント活用が出来ない奴に合わせて
コメントの有用な使用が出来ないと…

ココで偉そうにコメント語るなよｗ

>>974
> 逆にコピペの手間一つで、他人にやさしい事だと思うけど…

他人への親切のつもりでやってるならぜひやめてくれ。
それは将来の更新者に、毎回忘れずにコピペすることを強制していることになる。

＞cppに詳しい注釈書いてヘッダー部分は大まかにかけばいいと思うよ

例えこの方法でも保守できないと言うよう奴には無理だろ・・・

>>983
そう思うならヘッダーのコメントを消せば良いだろ
お前さんが更新したって事は、現担当なんだろ

まさか担当でも無い、他人のソースを更新するわけじゃないだろ？

しかもそれを言い出したら、ソースの更新しない設計とかクラス名とか
コメントなんかより重要な事を言いたいね

つまりコメントなしで理解できるコードを書けばいいんですね

>>986
そういうこと。

>>985
> まさか担当でも無い、他人のソースを更新するわけじゃないだろ？

自分の書いたコードは自分しか変更しないってことか。そういう前提なら
好きにしてくれたら良いよ。

>>988
逆に、そう言う発想する貧弱な開発体制なんだね…

担当がいる == 自分の書いたコードは自分しか変更しないってことか

キミには真なんだね…
会話は出来ないよね…

因みに、他人が担当部分で問題があったら
俺はソイツ＆チームで話して、ソイツに更新させる
それが仕事の方法、担当がいるってもんだろｗ

ゲームプログラマの人に聞きたい 33問目
http://pc11.2ch.net/test/read.cgi/prog/1234083564/

>>989
ヒント：担当がいつまでも会社に残ってるとは限らない

>>989
> 因みに、他人が担当部分で問題があったら
> 俺はソイツ＆チームで話して、ソイツに更新させる
> それが仕事の方法、担当がいるってもんだろｗ

それだと「担当がいる」ことによって面倒に（修正しにくく）なってるだけにしか見えない。
なんかメリットあんの？コメントのコピペができてうれしい以外に。

今このスレにゲームプログラマ(だとしらら)
びっくりレベルだなｗ

例え、前任者のコードだろうが、外注から引き上げたコードだろうが
担当以外がソースさわるわけ？

＞変更の手間とか更新忘れの危険性も考えてみろ。
＞同じコメントが２つあるというだけで正しく保守できる自身は無い。
＞むしろ、必ず更新し忘れるという自身があるぐらいだ。

こんな発言するクセに、よってたかってソース更新するわけだｗ
お笑いだなｗｗ

>>991
分ります、引継ぎも出来ないくらい
辞める人間が多発する酷い現場なんですねｗ

ようは良い悪いなんか関係ない
今の現場のレベルで楽な方法を真としたいだけだろ、お前らｗ

バグ回避等の危険性なんか語るなｗ

とりあえずプログラミング作法読め

一つのソースファイルやコードを
同時期に複数人で更新するなんてどもにも書いてないな

それとも、CVSやSVNがそれをする為のものだと思ってる？ｗ

それをするためのものだよ

機能的に可能な事と、仕事的に行なう事は別の事

コメントの更新もままならない奴が、同じファイルを触るわけだ
大変な職場だなｗｗ

ある日、関数仕様が更新されたとしよう
それを呼んでるソースは全部コンパイルが通らなくなる

その関数を担当してる奴が、変更理由を皆に話して了解取れば
後は、各担当で古いコールを直してもらえば良いだけだろ

それが担当が居るって事
担当が居ないと関数仕様を変えた奴が、全リポジトリの関数コール部分を直すのか？

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。