mel面白いですよね。
mel色々できますよね。
ただ、場合によっては重大な事故を引き起こしてしまうこともあるので、
自分が後輩さんらに1度は言ったことを幾つか
{ } で囲め
とにかくスクリプトエディタなんですよ。
みなさんスクリプトエディタで書いて、実行すると思うんですよ。
割と危険なんですよ。
例えばこんな感じのスクリプトを書いて実行したとしますわ
string $qbozHoge[] = `ls -sl`;
for($i in $qbozHoge)
{
print($i + "\n");
}
この時、$qbozHoge はglobal変数としてmayaさんに登録されてしまうんですね。
（global変数の確認は env; でできます。）
これの何が問題かというと、
- global変数さんは1回登録されると型を変えられない
- global変数さんはglobalなので、他でも使える
という事ですね。
つまり、
万が一 会社で使っているツールのglobal変数と名前が被ってしまった場合
- そもそもツール自体が動かなくなる
- 変数にツールが予期せぬ値が入り、深刻なエラーを発生させる。
という考えたくないレベルの面倒が発生します。
スクリプトエディタでmel単発の処理を書く際は {}で囲む 事で変数のglobal化を防げます。
{
string $qbozHoge[] = `ls -sl`;
for($i in $qbozHoge)
{
print($i + "\n");
}
}
自分で書く場合も、他人から貰った場合も
スクリプトエディターでmelを実行する際は気を付けてくださいね。
global procは気軽に作るな
これも理由としては前項と一緒ですね。
global proc は後から上書き定義できてしまうので、作るのはまぁ良いのですが
被りそうな名前(誰でも気軽に思いつきそうな名前)で作ると
万が一 会社で使っているツールのglobal proc と名前が被ってしまった場合
- そもそもツール自体が動かなくなる
- ツールが予期せぬ挙動をし、深刻なエラーを発生させる
という面倒が待ってます。
なので、melでprocをバリバリ作ってくときは
global procの量は必要最低限にし、
命名時はなるべく固有になるようにした方が安全ですよ。
UIのパーツ名は被らせるな
これも一緒。
万が一 会社で使っているツールのUI と名前が被ってしまった場合
- そもそもツール自体が動かなくなる
- ツールが予期せぬ挙動をし、深刻なエラーを発生させる
です。
最終的にUIパーツ名をつけるのが面倒になったので、
UIパーツ名は定義せずにそのまま変数に放り込むようにしました。
まとめ
なぜこうも細かいところまで一々指示していたのかというと、
過去に自分が全てやってしまったらなんですね。
ほんとうに面倒でした。