フラグ
プログラミングをしたことの無い人は、「え？」っと思うかもしれませんが、自分で作製したプログラムは、どんな作りになっていて、どの様に記事したかを全く忘れてしまいます。ですので、納品後、数ヶ月経って、お客様から、「ここの部分をチョッと変えてもらいたいんだけど」と依頼を頂いても、直ぐには、自分のプログラムを思い出せず。自分で作ったプログラムを前にチンプンカンプンと言うのは、実は、当たり前なのです。
そこで、チンプンカンプンから早く立ち直るためにシステム会社には、ドキュメントやルールが必要になります。（それだけではなく、他のシステム会社にシステムが引き継がれた場合に、引き継いだ会社がシステムを理解できるようにする目的もあります。） 今日は、その中のソースコードについてです。
開発したシステムは、当然、納品後の修正やメンテナンスのために分かりやすいソースにしておく必要があります。コード規約と言う物が、大抵のシステム会社には存在していて、そのコード規約に沿ってプログラミングを記事することにより、そのコード規約を理解している人間であれば誰が見ても、そのプログラムを読みやすく理解できる様にしています。
しかし、コード規約というものは、もともと、暗黙の了解でプログラマーが理解している常識によって構成されている事が多いです。上級プログラマーが、今までの経験で、メンテナンスしやすいコードの書き方がルール化されています。（ルール化した人たちの独断と偏見も多分に入っていますが・・・）
つまりは、初級プログラマーが犯すメンテナンスしにくいコードを書いてしまう過ちをルールによって矯正するのが目的です。
しかし、世の中には、多くのシステム会社やプライベーターが存在しており、そんなルールを持たない会社、素人に毛が生えたようなプライベーターや、逆に素人の集まりの様な会社も存在したりします。
私の会社では、時々、現在、使っているシステム（当社が作ったシステムではない）の改修をお願いしますと依頼を受けたりします。そのシステムを解析しますと、ライブラリを使用しソースコードもきれいに書かれておりオブジェクト指向（プログラムの書き方）を駆使した理解しやすいプログラミングがされていると思わず、「お～。きれ～に作ってるな～。」と感嘆の声をあげてしまいます。作った人の技量が感じられ、逆に私が勉強させていただきます。
しかし、その逆に、理解しずらく、特にスクリプト言語であるPHP、ASP等のソースで、HTMLの隙間にプログラムされている様なソースを見ると愕然とします。「○○○○～な～」と思わず口にしてしまいます。
その中で、最も私が嫌うものがフラグの多様です。フラグとは、ある条件が成立したら立てておく目印です。例えば、文字が１文字でも入力されたらフラグを立てておき、送信ボタンが押された時に、そのフラグが立っているなら次の画面へ、立ってないなら、次の画面へは進まない。と使用します。それの何がいけないのか疑問に思うかもしれません。
では、先程のフラグをaflagと名付けましょう。そして、もう少しフラグを追加してみます。上記の入力ですが、20文字を超えたら、他のフラグbflagを立てましょう。それと、文字の中に使ってはいけない文字が入ったら、また、他のフラグcflagを立てましょう。1文字以上で20文字以下、使用してはいけない文字を使用していなければ、次の画面に進めるとしましょう。じゃあ、次の画面に進めるのは、各フラグが、どういう状態ですか？
答えは、aflagが立っていて、bflag、cflagは、立っていない状態です。まだ、理解できると思います。
それでは、1文字も入力されていない、もしくは、20文字以上入力されていたら「入力文字数を確認下さい」と表示させます。1文字以上、20文字以下で、使用出来ない文字が入力されていたら「使用できない文字が入力されました」と表示させます。20文字以上入力されていて、使用できない文字が入力されていたら「入力条件を確認下さい」と表示します。
これだけ条件が増えてくると分からなくなってきます。挙げ句の果てには、条件を紙に書き出したりします。特に何十行、何百行にもおよぶプログラムの途中で、突然、aflagに対しての条件処理が出てきたりした場合、「aflagって何だったっけ？」となります。
問題は、３つあります。
①フラグを使用する必要が無い
フラグを立てるときに何がしか関数等を使用してフラグを立てているのだからフラグを使用せずに、その関数等を使用すれば良い。
②フラグを使用してもフラグの命名が悪い
aflag、bflag、cflagで、何を意味するフラグか分かりませんね。zero_flag、twenty_flag、unusable_flagとすれば、少しは分かりやすくなります。
③フラグの個数が多すぎる
フラグを使用せずに、変数を使用し、それぞれの条件の時に、意味のわかる文字を値として保持させる。例えば、1文字も入力されていない、もしくは、20文字以上入力されていたら変数に「number」という文字を入れるという様にです。
そう、一番最悪なのは、flagというフラグをプログラムに書く事です。完全に何のフラグか分からない事と、他の条件でも、このフラグを併用している可能性があることです。そうなると、解析には、かなり時間がかかる様になります。
さあ、大分忘れましたかね、aflag、bflag、cflagが全て立っていない時は、何の処理をするんでしたか？
あけましておめでとうございます。
あけましておめでとうございます。
本年もよろしくお願いします。
本日より、出社です。頑張って仕事します。
今年の目標は、
１、当然、売上アップ。
２、ライブラリの再整備。
３、次期開発指針調査。
です。
正月返上で仕事
年末となり、私の仕事も、やっとめどが付きました。なんとか、無事に年を越せそうです。
この時期に、納品が間に合わなく、正月期間中、出勤が確定してしまったSEさん、プログラマーさん、ご愁傷様です。まだ、出勤程度なら良いです。正月から徹夜とか、除夜の鐘、数えきってしまうSEさん、プログラマーさんもいると思います。日本で、この業界、何人くらいの人が正月出勤してるんでしょうかね？各業界別、正月の出勤人口率を出してみると面白そうです。うちの業界が、No.1かと思います。
正月出勤で思い出すのが、2000年問題ですね。Y2Kと言われてました。社内では、みんな、「2000年問題」と呼んでいましたが、課長のだけ、なぜか「Y2K」と連呼していました。まあ、よいでしょう。
その2000年問題とは、年表示は、昔、省略された西暦2桁年表示が使用されていました。（まあ、未だに使用している人を時々、見かけますが。）99年と入力されれば、1999年の事です。じゃあ、2000年になったらどうなるかと言うと、00年と表示します。しかし、一部のプログラムでは、それを、2000年とは、判断せず、1900年と判断してしまうのです。特に古いプログラムや機器がそう判断する作りになっていました。記録や履歴、ログが全て1900年と記録されてしまいます。それによる誤動作や不具合が発生する事により業務に支障をきたす可能性があるため、それらの調査と年を越した時の動作チェックが行われました。
当然、システム系は、駆り出されます。その時は、直接、プログラムの修正等は行いはしませんでしたが、動作確認や機器のチェック等を行いました。正月には、なぜか、朝の6時頃から動作チェックが始まり。システムや機器は、問題なく正常に動作していたため、7時前には、チェックが完了し、8時前には、家に帰った記憶があります。ついでに、その後、また、寝ました。
ちなみに、その時、一部の機器に異常が発生しており、日付が正しく印刷されず1900年で表示されていましたが、先輩に報告したところ、それは、以前から、そうだったとの事で、2000年問題ではなく、ただ単に、機器が壊れているとの結論でした。