所以長痛不如短痛，就按照正規的語法寫吧，以前 sanc 的 code
可以這樣寫
test_func() <= 不必宣告其型態
{
.
.
}
set("long",@^_^ <= 這樣子也可以後來就不行一定要像 @LONG 或 @DESC 這樣
^_^
);
ppl->move("/d/wiz/room/disc");
return notify_fail("你被移動到了這裡.\n"); // 不能 return 0 一定要 return 1
#define XXX "/x/x/xxx"
int a,b,c; <= 改成一定要在 inherit 後
inherit ROOM;
諸如此類的，sanc 共換過至少三次的 mudos，第一次跟第二次換
的時候最痛苦，因為都要大修 code，但等到第三次起就輕鬆了，
code 幾乎不太需要再改什麼。反之，如果第一次、第二次都不想
大改，等越後面的 mudos 版本要求越嚴格時，處理就會越麻煩。
那也是因為有這些經驗，越到後期寫區域相關物件才會越借重產生
器，因為產生器的原理就是
原稿→產生器→實體
換言之如果將來產生出的實體有問題，只要把實體砍掉，產生器改
一改，再把原稿丟進去，出來的新的實體物件就會是符合格式的物
件，這樣至少就不用再一個一個去改，而且也盡量讓產生出的物件
繼承共通樣本，這樣有時只需改繼承樣本就能解決。
基本上寫法越符合 mudos 的要求，就執行效率上來說也會比較好。