クセとはちょっと違いますが僕はコーディングルール的なものは結構変わったりします。ケースバイケースで色々と迷うんですよね…。 ただプチコンは文法が少ないので今のところは以下の感じです。ただこれもたぶんまた変わると思う…。 INC,DEC…使う。ただし不具合があるケースもあるんで必ずとは限らない。 OPTION STRICT…サンプル以外では使う。 カラー指定…あまり安定してない。黒などは0,0,0の方が短いので長さで決める場合もある。 1行の命令数…。基本１つ〜少なめ。とくに複数行になる長さにはならないように気をつけている。 配列、変数宣言。配列の場合はDIM。ただし普通の変数と配列を同時に宣言したいときはVAR。最近はVARに統一した方がいいかなぁ、と思ってきてる。 みたいな感じですね〜。

基本でんぺんさんと同じような感じですが僕の独特な書き方は、 ・変数名や関数名に大文字小文字を混ぜて使う 大文字だけだと認識しづらいから ・変数名の頭に[d]とか[g]とか[l]を付ける [d]define 値を変更しない定義系 [g]global 全体で使用可能な変数 [l]local 関数内で使用する変数 ・FOR文ではTO ○-1と書く FOR lYoubiLoop=0 TO 7-1 みたいな感じですかね～。

■INC,DEC 使わないですね･･･BASIC＝A=A+1、という固定観念があるので変えようと思わないというか。 ■OPTION STRICT 貧弱なBASIC出身故、変数名は短くするクセがあるため使わないです。 ■カラー指定 16進数は見た目がわかりやすい、10進数は文字数が少なくなる、というのがそれぞれのメリット。私はCOLOR命令以外では16進数で書きます。 ■1行にたくさんの～ 私は見やすさ重視で44文字以内に収まるように書いてますね。1行には多くても命令は3つくらい。DIALOGなどでどうしても長くなるときは･･･例外です！ ■配列宣言 DIM=dimension、VAR=variable が語源のはずなので配列宣言はDIM、変数宣言はVARとしています。 ■その他 今は定義命令を_で始まる名前にしてます。昔は_がCALL命令の短縮として使われていたので。

●INC/DEC 使います。変数名長くしちゃうので、変数 = 変数+1とするのが面倒（でも、そのうちバグを招きそうでちょっと怖い……） ●OPTION STRICT 使います（FOR 文使う時に、毎回 DIM I をやらないといけないのだけが不満） ●カラー指定 #AQUA とか使う。自分で指定するなら16進使うと思う。 ●1行複数命令 基本的には1行1命令。例外あり（単命令の繰り返しとかは1行） ●DIM/VAR 数値/文字列で使い分け。これは単に気分の問題。 ●その他 ・行端で折り返さない派 ・こまめにDEF する派 （プログラム上で1回しか実行しない処理は、DEF で命令/関数化する必要はないけど、それでもする）

でてきてないところで、IF文の条件は可能な限り「>」ではなく、「<」を使う。 IF 16 <= A && A <= 32 THEN ほげほげ IF X < 0 || 399 < X THEN ほげほげ と条件を書くと、範囲内を調べたいのか、範囲外を調べたいのかが、僕にはすっと入ってきます。

比較演算子と言えば、 IF X>7 && X<16 THEN みたいに、最小値の確認、最大値の確認の順番に書くことが多いかな… あと>=,<=はできるだけ（値が整数だとわかってるときなど）は>,<に変えます。

●INC/DEC 変数名長によりけり。 ●OPTION STRICT 大作では使う。 ●カラー指定 定数リテラルが好き。 ●1行複数命令 画面からはみ出さない範囲で。 ●DIM/VAR 配列はmkII以前からでDIM。 非配列は3号からなのでVAR。

私の場合、IF分の使用を避ける傾向があります。例えば、次のような感じです。 B=BUTTON() IF(B AND #LEFT)!=0 THEN DEC X IF(B AND #RIGHT)!=0 THEN INC X ↓ B=BUTTON() INC X,((B AND #RIGHT)!=0)-((B AND #LEFT)!=0) IF X<399 THEN INC X ↓ INC X,(X<399) 30年前当時の8ビットパソコンのBASICでは、IF文より論理演算の方が高速であると信じられており、ベー○ガでもこのプログラミング手法を推奨していたので、私にとって習慣化したものと思われます。

*inc,decは使う *option strictは必須 *カラーは定数リテラルか&h *コロンはよほどのことが無いかぎり使わない *配列はdim,それ以外はvar *定数扱いの変数はアンスコから *先頭以外のアンスコは所属や要素を示す(POINT_XとかCOLOR_Rとか) *dataの前にはラベルを置き、readの前はrestore *フラグや条件式には1/0よりt/f 　､､､面倒くせぇ

みなさんそれぞれ書き方にクセや、こだわり、分かりやすい書き方がありますね。 私の場合、色指定はコンソール画面以外は16進数で指定します。ガイドブックのカラー見本が16進数でしか書いてないので。 BU=BUTTON()、IF BU AND #UP THEN～のようにボタン関係は定数リテラル使ってます。OPTION STRICTはある方にお勧めされて使うようになりました。増分や減分はINC、DECを使ってます。1行に書く文はできるだけ少なくしてます。IF文で長くなる時はTHENの後に改行して、ENDIFで締めてます。こんな感じでしょうか。面白いのでもうしばらくトピックを受け付けています。みなさんの興味深いコメントありがとうございます。

ケインさん> OPTION STRICTモードで一度DIM Iを書いておくと、IF文でよく使うIは毎回宣言しなくても普通に使えますよ。

タバひめさん > それやっちゃうと、 FOR I=0 TO 9:FUNC:NEXT DEF FUNC FOR I=0 TO 5:PRINT I:NEXT END で無限ループに陥りませんか？

実はユーザー定義関数、命令は今日買った日経プチコン３号公式ムックで覚えたばかりなのでユーザー定義関数、命令に使う変数の宣言はよく分かってません。少なくともユーザー定義関数、命令にIを使わない場合は1回の宣言で普通に使えるはずです。

もっともローカル変数は別途宣言必要なはず。

いや、まあそれは(FOR ループで呼び出した先のルーチンで、そのFOR ループで使用したカウンタを使わなければいいというのは)そうなんですけどね。 ただ、そうすると各定義毎で常に「あれ、このカウンタ(I)って使ったっけかな？」と気にしないといけなくなったり、もしくは、各定義毎に専用カウンタを準備しないといけなくなったりして、ユーザー定義のメリットが半減しちゃう。 そういう意味で、各定義内でカウンタ変数を宣言するのは必須なんですが、その書式として、 FOR DIM I=0 TO 9 みたいな書き方を許してくれればいいのになぁ、という愚痴でした。

ケインさんの言うようにユーザー定義命令／関数のループ変数で変数を宣言するのはちょっと面倒ですよね。ただスコープを考えるとローカル変数にしたいところではありますので僕もFOR VAR I=0 TO 9としたくなることがあります。 おかっぺBEERさんのIFの時のルールは意味合いはよくわかるし、僕もそれを試したことはあるんですが、どうも比較対象が左側の方に慣れてしまっていて馴染めませんでした…。この辺（比較演算子）はあまさと　しおんさんのような感じにしちゃってますね。

リテラルが左辺値だと、他言語に移行したとき何かと都合がいいんですが､､､､､､慣れねぇ､､､､､､

KUさんの挙げた書き方…… ヨーダ記法を私は使ってます。今時のナウい言語ならエラーや警告出してくれるので、老害のテクニック。

INC・・・基本的には使わない（A=A+1の方が速いし変数名が1文字だとリスト短縮にならない） OPTION STRICT・・・基本的には使わない カラー指定・・・基本的には10進数（例えば-7E5でピンクを指定みたいな感じ） 1行・・・QSPなどではできるだけ行末ぴったりになるような文字数で記述 変数宣言・・・VARをよく使うけどQSPでは基本的に宣言はしない 自作関数内で使用しているグローバル変数は"_"＋関数名によってどの関数で使用しているグローバル変数であるかが明確になると同時にダブりの防止をしています。 あとクセというわけではないですが、QSPやOSPのような文字数制限があるプログラムではない普通のプログラムでもリスト短縮を行って記述しています。 ほとんど意味がないこと（下手すればマイナスにしかならない）と分かっていても無駄があるのが気になるわけです。

option strict: 気合が入っていれば使う。 option defint: 小数がたくさん出てくるプログラムでない限り使う。 dim/var: option strict使用時はvarで統一。 そうじゃなければdimで配列宣言。 たぶん前者はjavascript、後者はmkIIの影響 その他: *メインループにはrepeatを使う。 *vsyncは基本的にループの最初に置く。 *効果音は処理の前に鳴らす。(beep 64:cls '例)

inc/dec 配列にだけ使う option strict 必須 16進数 タイプ面倒 一行一命令 varのみ タイプ簡単だから 演算子の前後にスペース入れたいけど画面狭いから我慢 比較は < か >= じゃないと落ち着かない if 1==A とか見るといやーんな感じがする if x==true だけは許せない def は、呼び出される側、呼び出す側の順で書く、よってメインが一番最後 var 命令は変数を使う直前で def の名づけ方は object_method みたいな感じ(save_data より data_save) def 途中 return はたまに使う repeat/until/break/continue は使わない、goto/gosub は使ったことがない 遅いのはプチコンのせいであり、俺様のコードのせいではない

ミキさん、GOTO、GOSUB使わないんですか？私はメインループを作る時に使うのが普通と思っているのですが。 私は遅さ、処理落ちを感じるほどの大きいプログラムはまだ作ったことありません。コメント合わせても500行を超えるプログラムさえまだ作ったこともありません。みなさん中級者以上の方ばかりなので焦ってしまいます。まだユーザー定義関数、命令も使いこなしてない。

色指定-7e5とか指数表記使うって発想ないw

gosub は def で書き換え可能。 goto は ループ目的ならば while/repeat/for 等で書き換え可能。 処理の分岐目的ならば if then else endif で書き換え可能。 on x gosub は call sub$[x] で書き換え可能。 on x goto は if x==1 then .. elseif x==2 then .. endif で書き換え可能。 goto/gosub使うなと言ってる訳じゃないですよ。人それぞれスタイルがあるので、無理に変える必要はありません。 私の場合は def 無しでプログラムは書けないので、もしプチコンから def が消えたらプチコン捨てます。実際プチコンmkIIは買って一度もプログラム作らなかったし。

いろんな方法があるしどれが正解ってわけでもないと思います。ケースバイケースですしね〜。 チーム開発とか出なければ自分に合った方法でやればいいんじゃないかと思います。 僕は基本的には可読性重視ですが、プチコンの場合は画面が狭いので変数名が長いと変数名で意味がわかるのはいいんだけど構造としての可読性が落ちてしまうのが悩みどころで、結局中途半端な長さの変数名にしちゃいますね。 GOTOで飛ぶのはソースがスパゲティーになりやすいので嫌われますが、昔の行番号で指定する時代ならともかくラベルで指定する場合はラベル名などである程度わかりやすく処理できますし、流れをちゃんと意識して使う分には問題ないような気がしてきています。まあこれもケースバイケースですね〜。

私はこんな感じでループを使い分けています GOTO・・・最速、最短 WHILE～WEND・・・条件付きループでは最短 FOR～NEXT・・・回数が決まっているループでは最短 ON GOTO・・・条件付きループでは最速（比較演算子を使う場合はREPEAT～UNTILが最速） ちなみに無限ループはこのように記述できます。 WHILE 1～WEND REPEAT～UNTIL 0 FOR I=0 TO I+1～NEXT

使用されることが多いWHILE 1～WENDという無限ループですが、こうしてみると速度面でも短さの面でも使うメリットはありません。 まぁ最速や最短を気にしない場面では私もよく使っていますが。 あとGOSUBは速度重視の場面では使用するし、そうでない場面であればDEFの方が使い勝手が良いです。 結局可読性かリストの長さか速度かでどれを使うかのがベターかが決まると思います。 特に気にしないのであれば自分が使いやすいものを使うのがベターでしょう。 でんぺんさんも書かれているようにプログラミングに正解はありません。 趣味でやるプログラミングならば他人がとやかく言っても自分が楽しく作るのが一番ですね。

あまさとしおんさんへ 最短のためならば使えるものは何でも使うべきでしょう（笑） 例えば256という値が欲しければ、ボタン入力とは無縁の場所でも定数リテラル#Lを使用します。 ただし、#Lの後に別の命令を続けて記述する場合はスペースやコロンが必要になるためこれは短縮にはなりませんが。 QSPで作品作りを重ねることでプチコン3号ならではのリスト短縮テクニックを多数会得できたのでまた機会をみて自サイトの方でまとめたいと思います。

おちゃめさんのサイトも見て勉強してます。定数リテラル、同時おしで斜め移動ができない4方向移動等をそこで覚えました。ありがとうございます。まだ更新されてない講座もありますが、おちゃめさんの時間がある時にまたお願いします。

ループは、ほぼrepeat ラベルや変数を作りたくない(面倒な為) for文の繰り返しの変数は何故か"Q" 以上、自分の癖

訂正　500行以上のプログラムは作ったことないと言いましたが、KAZUATE GAMEはコメント含めて823行使いました。もっとスマートな書き方ができると700行ぐらいに収まると思います。

option strict...コードを綺麗にしたいときに使う inc/dec...なんそれ'-' 一行にたくさんのry...変数の代入の場合は割とたくさん dim/var...dim 他 bgmset使わない gosubあんま使わない 無限ループはwhile 1

INC、DEGを使う、使わない等は単にその人のくせやこだわりだと思ってましたが、みきさん、おちゃめさんは処理速度で選んでいるようですね。今の内から覚えておこうと思う。 ところで、最速は分かりますが、ここで言う最短の意味は何でしょうか？

あ、ネタバレにする意味ないのに間違ってネタバレになってる。

おちゃめさんがおっしゃる「最短」とは、プログラムの長さのことですね。「256」も「#L」も「&H100」も、プチコンでは同じ数を表すので、それなら「#L」と書くのが最も文字数が少なく、その分プログラムも短くなる（＝メモリ消費が少なくなる）という寸法です。 尤も、プログラムの規模にも依りますが、この方法で削減可能なメモリ容量は高々数10バイトであり、数ギガバイトはあるフラッシュ容量からすれば、影響は皆無に等しいでしょう。 おちゃめさんやみき★さんは、かつてのメモリが数キロバイトしかなく、メモリの節約が不可避だった時代を生き抜いてきた方々です（よね？）ので、メモリ容量不足の懸念がなくなった現在に至っても、メモリ消費最小化が習慣化されているのでしょう。 ちなみに私も、そういう時代を過ごしてきたはずですが、現在の潤沢なメモリ容量に慣れてしまい、すっかり腑抜けになってしまいました。

え、私はメモリ節約とか考えませんよ!! お殿様なんで、メモリよりも速度よりも書きやすさ優先。 (1) 最優先事項は完成させること。 (2) 速度は完成後考えればいいし、 (3) 十分な速度が得られたら、メモリ節約考えてもいい。 (大抵の場合、実行速度と使用メモリ量はトレードオフの関係になります。)

私も書きやすさ優先です(可読性とはいってない)

確かに私は昔は1KB程度しかメモリを搭載していない機種を使っていたためリスト短縮は必須テクニックでしたが、比較的メモリが潤沢なプチコン3号ならばOSP（1画面プログラム）やQSP（WIDTH 16の1画面プログラム）のように文字数に制限があるプログラムを作らない限りはほとんど不要なテクニックだと思います。 処理の高速化においてもWHILE～WENDとREPEAT～UNTILの速度差なんて微々たるものです。 速度に不満を感じた際はアルゴリズムの改良などで高速化をすべきでしょう。 文字数制限のあるプログラムは作らず、速度面で不満があるプログラムも作らないというのであれば自分が作りやすいように作ればいいと私は思います。 趣味で作るプログラムならば書きやすさ優先で何ら問題はありません。 「自分が作っていて楽しい」のが一番優先されるべきですからね。