50代の元プログラマ現管理職=岩田聡
楽しいバレンタインの季節がやってきました。
プログラマは頭の良さそうなカッコイイ人達ばかりなので女性にモテると思うのですが
どのくらいチョコ貰えたり女の子お持ち帰りできたりするんですか?
>>934 なにこれ?ex-boardのほうがいいし
チョンの作ったボードなど使いたくない
957 :
926:2009/02/07(土) 15:42:14
>>937 将来が無いなんて感じてないから答えられない。
将来があると思ってる奴は、意欲に溢れた奴か馬鹿。
将来がないと思ってる奴はただの無能。
未来は自ら切り開くといいたいんですね
あの・・・バレンタイン・・・
将来はあるさ
潰れる将来があるだけで
>>954 喪男に配慮して貰ってないフリをしてるが10個前後は貰ってる。
という妄想で抜いた
>>959 将来が無いと思ってるならさっさとやめて転職すればいいのに
それが出来ないっていうのは無能に他ならない。
今から就職作品送ろうと思います
コードには注釈文を入れまくった方がいいですか?
それとも必要最低限のところだけのほうがいいでしょうか
コメントが無いと見る気がしない。
>>965 沢山入れるのが、(就職作品ではなく)将来の君のためだ。
適切なコメントを書くのは大変難しいが、努力で少しは良くなることだから、今から練習を始めよう。
ついでに、行間に無用な改行を入れないようにする訓練も今のうちにやっておこう。
>>967 むしろ行間に改行無いソースは糞ソース。
レスありがとうございます!
ヘッダーファイルとソースファイルで同じ様な注釈文入れるっていう
大バカなことだけはするなよ?
絶対落ちるぞ絶対
>>970 わかるw
たまにいるよねそういうやつw
Doxygenなり何なりのドキュメントジェネレーターに準拠したコメント入れとけ。
そうすると得点高いぞ。
そうか?
コメントが自分だけの物じゃないって言ってる以上
ヘッダーの宣言だけ見る人間も居るかも知れないじゃん
俺なんか他人のソースで改造とかやらされるけど
はまらない限りヘッダーしか見ないからヘッダーにコメント欲しいタイプだが
ガッツリ調べる時にソースも見るから確認する意味でも両方入れといて欲しいと思う
両方に同じ事書いてあっても別にいいともうが?
逆にコピペの手間一つで、他人にやさしい事だと思うけど…
>>973-974 変更の手間とか更新忘れの危険性も考えてみろ。
同じコメントが2つあるというだけで正しく保守できる自身は無い。
むしろ、必ず更新し忘れるという自身があるぐらいだ。
976 :
975:2009/02/08(日) 17:19:48
ごめん。 ×自身 ○自信
C++で例えるなら
cppに詳しい注釈書いてヘッダー部分は大まかにかけばいいと思うよ
>>975 どんな理由かと思えば…
自分の無能ぶりを自信たっぷりに理由にされてもなw
それ、俺バグ出す自信があると言ってるのも同然じゃん
自分のコード&担当したコードくらいメンテしっかりやれよww
>>975 そんな理由じゃお前はコメント云々語る資格はない
>>978 仮に自分が正しく保守できるとしても、全員がそれをできるとは言えないだろ。
重複したコメントがあるソースは迷惑。
コメントのメンテも出来ない奴が
ソースとコメントの連動が出来ると思えないw
つまり、コメント活用が出来ない奴に合わせて
コメントの有用な使用が出来ないと…
ココで偉そうにコメント語るなよw
>>974 > 逆にコピペの手間一つで、他人にやさしい事だと思うけど…
他人への親切のつもりでやってるならぜひやめてくれ。
それは将来の更新者に、毎回忘れずにコピペすることを強制していることになる。
>cppに詳しい注釈書いてヘッダー部分は大まかにかけばいいと思うよ
例えこの方法でも保守できないと言うよう奴には無理だろ・・・
>>983 そう思うならヘッダーのコメントを消せば良いだろ
お前さんが更新したって事は、現担当なんだろ
まさか担当でも無い、他人のソースを更新するわけじゃないだろ?
しかもそれを言い出したら、ソースの更新しない設計とかクラス名とか
コメントなんかより重要な事を言いたいね
つまりコメントなしで理解できるコードを書けばいいんですね
>>985 > まさか担当でも無い、他人のソースを更新するわけじゃないだろ?
自分の書いたコードは自分しか変更しないってことか。そういう前提なら
好きにしてくれたら良いよ。
>>988 逆に、そう言う発想する貧弱な開発体制なんだね…
担当がいる == 自分の書いたコードは自分しか変更しないってことか
キミには真なんだね…
会話は出来ないよね…
因みに、他人が担当部分で問題があったら
俺はソイツ&チームで話して、ソイツに更新させる
それが仕事の方法、担当がいるってもんだろw
>>989 ヒント:担当がいつまでも会社に残ってるとは限らない
>>989 > 因みに、他人が担当部分で問題があったら
> 俺はソイツ&チームで話して、ソイツに更新させる
> それが仕事の方法、担当がいるってもんだろw
それだと「担当がいる」ことによって面倒に(修正しにくく)なってるだけにしか見えない。
なんかメリットあんの?コメントのコピペができてうれしい以外に。
今このスレにゲームプログラマ(だとしらら)
びっくりレベルだなw
例え、前任者のコードだろうが、外注から引き上げたコードだろうが
担当以外がソースさわるわけ?
>変更の手間とか更新忘れの危険性も考えてみろ。
>同じコメントが2つあるというだけで正しく保守できる自身は無い。
>むしろ、必ず更新し忘れるという自身があるぐらいだ。
こんな発言するクセに、よってたかってソース更新するわけだw
お笑いだなww
>>991 分ります、引継ぎも出来ないくらい
辞める人間が多発する酷い現場なんですねw
ようは良い悪いなんか関係ない
今の現場のレベルで楽な方法を真としたいだけだろ、お前らw
バグ回避等の危険性なんか語るなw
とりあえずプログラミング作法読め
一つのソースファイルやコードを
同時期に複数人で更新するなんてどもにも書いてないな
それとも、CVSやSVNがそれをする為のものだと思ってる?w
それをするためのものだよ
機能的に可能な事と、仕事的に行なう事は別の事
コメントの更新もままならない奴が、同じファイルを触るわけだ
大変な職場だなww
ある日、関数仕様が更新されたとしよう
それを呼んでるソースは全部コンパイルが通らなくなる
その関数を担当してる奴が、変更理由を皆に話して了解取れば
後は、各担当で古いコールを直してもらえば良いだけだろ
それが担当が居るって事
担当が居ないと関数仕様を変えた奴が、全リポジトリの関数コール部分を直すのか?
1001 :
1001:
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。