「お仕事プログラミング」の編集履歴(バックアップ)一覧はこちら
「お仕事プログラミング」(2005/12/06 (火) 23:25:32) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
趣味でやるプログラミングと違って、お仕事にしてしまうといろいろと制限も出てくる。
そのなかで、割と軽視されている(少なくとも今の職場では)のが設計書とコーディング規約。これはホントに環境によると思うんだけど。
というわけで今日はコーディング規約のお話。
お仕事のプログラムに求められるのは、まず第一に仕様書どおりに動くこと。趣味の範囲ならそこまででもかまわないんだろうけど、その次にそのソフトウェア資産を次回新機種に使ったり、機能拡張をしたりとメンテナンスする必要がある。
しかも、最初にコーディングした人がメンテするとは限らない(むしろまれ)。頼りは、設計書とソースコード、およびソース内のコメントだけ。
そのため、設計書の精度とソースコードの可読性というものが非常に重要となる。前に言ったコーディングスタイルの統一も個人レベルだと有効だけれどそれが人によって異なるのではやっぱり読解に時間がかかってしまう。
だから、例えば変数や関数の命名規則を統一したりといった一定のルールを決める。それがコーディング規約。これによって「この変数は何に使ってるの?」っていうのをまあ名前からある程度予測できるようになったり、変数のサイズ(型)によるミスを減らしたり。。あるいはswitch caseには必ずdefaultを入れて、イリーガルなスイッチによるエラーに強くしたり。。
・・・できるはずなんですよ。みんなが守ってくれたら!
グローバル変数に誰でも使いそうな名前付けるのやめてくれよぅ。せめてstaticつけてファイルスコープ内とかならまだしも。。。よそで同じ名前定義されちゃうと、変数の値を保障できないんだけど。こういう不具合って見つけるの大変なんだよぅ。
・・・とか、ね。
得てして、ある程度年季のある(年季しかない)人に限って独自のコーディングスタイルを優先させようとする傾向にあるみたい。あと古い人ほど識別子の名前が長くなるのが嫌みたいでわけわからないくらい短い名前にしたりする。
いや、いいですよ別に。100%不具合でないんならね。ええ。
いいんですよ。これからも永久にあなたがそのソースのメンテしてくれるならね。ええ、ええ。
-------------------------------------------
ここからは、愚痴。
そういう人に限って、
なんで私よりも10年以上もキャリアあって、そんな詰まらん不具合だすかなあ?領域破壊してこっちのデータ壊すのやめてくださいよぅ(別々の場所で過去3回ほどあった。最初私の部分でお亡くなりになるので疑われたりしたし)。unssignedの変数にマイナスの値とか入れないで。。wtc.
全部、ちゃんと変数に規約どおりに名前つけときゃ用途もサイズもはっきりするわけで。ほんのちょっと、注意してくれたらいいでしょう、と思うんですけどね。
しかも、途中でチームから抜けちゃうし。んで、すでにその人のやった名残はほとんどありません。いろんなところにあるコピペしたと思しき処理をサブ関数にしたり、処理自信が非常に臭かったのをロジック自体変えて修正したり、変数や定数もあらたに切りなおし。。
おいおい、ほとんで新しく作り直してるじゃないか。みたいな。
結局半年以上もいて実績ないじゃんかぁ。。
愚痴終わり。
-------------------------------------------
おんなじ様な理由で、設計書についてもあるんですけど。。
またまた今日も長くなったのでそれはまたの機会に。
表示オプション
横に並べて表示:
変化行の前後のみ表示: