見出し画像

仕事の話

ただいまマイスイート←挨拶。

だるいー。
だるいよー。
23時すぎに帰宅したよー。

しかも明日も仕事になったYO。
コロナ 患者が出たんよ…

Errorを探す仕事をしてきた。
いちばん苦手…

他人のプログラミングを見て、Errorを探す。

やりたくねー。

プログラミングは、みんなが思ってほど綺麗に書かれていないのです。

しちゃかちゃな奴いる。
キレそう。

メモを貼るんだけど(プログラミングの中にコメントが書ける)

他の人が見てわかるように、ちょっとなんか書いたりする。

このメモ(コメント)を書かないやつが多すぎて何かあった時、大変なります。

メモ=コメントとはソースコードに書かれているメモのことです。
コメントがあってもなくてもプログラミングの動作には影響がありません。

これがないと他の人が仕事を引き継ぐときに目の前のコード以外は、何一つ情報が残っていない状態になります。

くそが!
お前は何を考えてこういう風に組んだんだ!

だから色々な注釈をつけておき、他人が見てもプログラムコードを読みやすくするために、メモとしてコメントが使われます。

それを書かないクソヤローがいる。

コメントの書き方も問題です。

作業工程を書くうましかがいる。。
「ここで出力する」

メモだけど…
メモだろうけど!(意味が違うんよ)
そんな個人的な作業工程を書くな!

そんなことは コードを読めば こっちはわかるねん。

あほか!なんで訳した!
画面がごちゃごちゃするし、翻訳しただけだから読む量が増えるだろ!

知りたいのは 何でこんな しちゃかちゃ なコードを書いたか理由だボケ!

ソースコードを読めば 、だいたいのことはわかる。

問題は、なぜこうしたんや!
それはお前にしかわかんないことだろうが! それを書け!

時間が経てば 本人もわからなくなる!
そのためにコメントを残す。

システム構築は完璧にできたらいいんだけど穴ありきなんで…

「ここ無理やり修正しました。見て下さい」とか書け!

サーバーサイドの問題かな?とか、サーバー上限値を書いたりだな…

自分がトライ&エラーしまくった箇所などにコメントをつけ、失敗しそうなあるあるを書く(二度手間を防ぐ)

TODO: ・・・後でやるタスク

FIXME: ・・・不具合がある

XXX:  ・・・大きな問題がある

これが基本です。

コメントには「①ソースコードの処理の説明」「②そのソースコードを書いた理由」、「③他のエンジニアに向けての注意」以外を書くな!

必要な情報を絞ることが一番大事。
できるよね?できるよね?

なのになんで翻訳するのぶっころ。
殴るよ殴るよ!

たまに有能すぎておかしなコメントもある。
「ここは触るな神のコードだ」

ボスのメモ。
たしかに綺麗だ…

触らんわ!になるからスキなコメントです。

グライスの公理で書かないやつは死刑。

量の公理(Maxim of Quantity): 情報を過不足なく提供する。

質の公理(Maxim of Quality): 根拠のないことを述べない。嘘をつかない。

関係性の公理(Maxim of Relation): 関係のないことは述べない。

様式の公理(Maxim of Manner): 簡潔に理路整然と述べる。

マジックナンバーが、Magic過ぎる問題もある。

コード上で意味を持った数字のことをマジックナンバーと言います。マジックナンバーは数字を直接書いてしまうとわかりにくいです。

マジックナンバーは定数や変数として定義するとわかりやすいです。

わいか?わいはコメントは書かん!コメントが必要ない明瞭なコードを書くことが正義だ!

コメントは問題を回避するために通常とは異なった迂回処理をした場合のみ私は書きます!

仮実装であれば「未実装」、削除予定であれば「非推奨」、不具合を回避するための応急処置であれば、不具合の内容と暫定的な応急処置と書け!

そしたらそこだけ見るだろうが!
クソみたいなコメントを残すんじゃなねぇー。

読み手にとって意外なコードを書かなければコメントはいらん!

「くそみたいなコード書きやがって」とかコメントを書いたらあかんよ。。
それただのアンチコメントやから笑。

感想は書いたら駄目です笑。