HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2021
0123
アキアキノヒロロプログラムを書く上での工夫7解決


アキアキノヒロロ

リンク

2021/1/23(Sat) 08:47:35|NO.92130

皆さんは、エディタでプログラムを書いていく時、プログラムしやすいようにと、何か工夫していることはありますか。

万年初心者の私は、ちょっとプログラムが大きくなってくると、自分が今何をやろうとしていたのかさえ分からなくなることがあります。
で、当然できる限り、コメントをその都度いれるようにしていますが、これは誰もが多かれ少なかれやっておられることでしょう。

また、プログラムのその箇所が担当してやっていることも、見出しのように書き込んで、どこの行からどこの行までなのか、これも簡単に判断できるよう、

;…………………………………………………………………
;==================================================

などで区切っています。これは、ラベル・関数にすればいいじゃないか、と言われそうですが、そこまでのことはないものでも、行数を食ってしまう場合もありますから。

そして、ラベル/関数でないに関わらず、この見出しに「*」を付けることもあります。これは、反則技かも知れませんが。
何故そうするかというと、エディタのメニュー「編集」の「ラベル・関数一覧」でプログラム全体を俯瞰することができるからです。
その見出しになっている箇所に飛んでいき、その担当部分をすぐに参照編集もできます。
これでプログラムを実行しても、不都合はありませんが、この反則技は、プログラム上、よくないことでしょうか。

あと、プログラムを始めた当初、命令以外、変数のほとんどによく日本語を使いました。
これも、実行しても、不都合がなかったので、英語の苦手な私のよくお世話になっていた方法です。(アルファベットアレルギー?)

皆さんの工夫していること、教えてほしいです。



この記事に返信する


法貴優雅

リンク

2021/1/23(Sat) 12:49:13|NO.92135

私の場合は2.5時代に教えていただいた「構造化エディタ」を使用しています。
https://www.vector.co.jp/magazine/softnews/071218/n0712181.html
アウトラインプロセッサ風のテキストエディタです。
編集機能は弱いですが、サブルーチンや関数で区切り見やすく編集することができます。

あとは1ファイルだとコードが長すぎて編集しづらくなるため
機能ごとにモジュール化してファイル分割して
分割コンパイルっぽくしています。



Ve

リンク

2021/1/23(Sat) 13:08:57|NO.92136

;===========================
;   タイトル
;===========================
とかは普通の使うのですが、
やはりHSPは日本語でラベルが作れるので

*タイトル初期化
;処理の内容
(初期化関係の処理)
*タイトル
;処理の内容
  :
  :

として、F11で呼び出してもすぐ分かるようにしてます。

後はメインで使わないコードは全て外部ファイルにします。
・外部データ読込
・戦闘データ読込・処理
・マップデータ読込・処理 など



GENKI

リンク

2021/1/23(Sat) 17:11:46|NO.92137

そうかHSP3は日本語できるから変数名もラベル名も日本語でいいんですよね。
次からラベル名だけでも日本語にしようかな。


私の場合は、こんな感じでやっています。
書いておけば忘れたときに見に行けばいいので。

HSP3でのデザインパターン | GHP(仮)
https://mclab.uunyan.com/lab/hspneta/neta009.htm


書いてないことで最近良くやるのは、ファイルを分けるときの工夫。
サブルーチン群を別ファイルが膨らんできて整理が面倒なような場合は、別ファイルにしてこんな感じで書いています。
使うときは、どこで #include してもOK。先頭で #include 出来ます。
またサブルーチンだけをテストしたいとき、このファイル単体でデバッグモードが動くようにしてます。

#if 0 ; 0以外でデバッグモード ; デバッグ作業用コード ; ここでサブルーチンで使う変数を初期化してからサブルーチンのテストをします。 gosub *サブルーチン1 gosub *サブルーチン2 end #endif goto *@f *サブルーチン1 … return *サブルーチン2 … return *@
ファイル名は、「sr_….hsp」

エディタは、メインのファイルだけHSPスクリプトエディタで開いて、モジュールやサブルーチンのファイルは EmEditor で開いています。
アウトラインバーを表示すれば、HSPスクリプトエディタの「ラベル・関数一覧」と同じものが常時表示できるので便利です。



アキアキノヒロロ

リンク

2021/1/23(Sat) 23:09:59|NO.92142

モジュールに取り組む自信がないので、やったことがなく、だらだらと長くなりがちでした。
いつかはやらなければと思いつつ、先延ばしにしていたせいです。
で、長くなって、前後の脈絡が取りづらかったので、「*見出し」や「;=================」のような区切り用のものを多用していました。
少しずつでも勉強していこうと思います。

変数を日本語でやり始めたのは、「なでしこ」に親しんでいたからでもあります。
「HSP」でも、下手をすると、数千行にもなるプログラムでも、日本語と数字ばかりでプログラムが埋まってしまうぐらいのものになっていたこともありました。
それでも「HSP」は、思い通りに動いてくれたので、驚いたと同時に、嬉しかったのを覚えています。
でも、こんなんでは、動作が遅くなっていたんでしょうが、ただそのことに気付かなかったというだけでしょう。
それよりも、エラーのでないプログラムを作るだけで精一杯でしたから、そのことは問題ではありませんでした。

法貴優雅さん、Veさん、GENKIさん、有難うございます。
皆さん、やはり、全体の流れを作るメインのプログラム部分(ファイル)とモジュールやサブルーチンの部分(ファイル)とに分けてやっておられるんですね。
「構造化エディタ」や「EmEditor」にも触れてみようと思います。
あと、GENKIさんの「HSP3でのデザインパターン | GHP(仮)」すごく勉強になりそうです。

人それぞれに工夫したやり方がまだまだありそうな気がします。お教え頂けると嬉しいです。



アキアキノヒロロ

リンク

2021/1/25(Mon) 07:10:59|NO.92147

昨年でしたか、GENKIさんが、卒論で困っていた方へアドバイスしておられたことを思い出しました。

「心身の健康維持は業務の一環であり休養はその手段の一つ」

これ、業務の心構えとしての一般論とGENKIさんが考えることを、プログラミングの心構えにも言えることだとおっしゃっていた訳で、とすれば、このアドバイスは、

「心身の健康維持はプログラミングの一環であり休養はその手段の一つ」

と読めます。これ、忘れがちですが、とてもとても大事なことですね。
私も、プログラミングに詰まった時、とにかく手をおいて休むことが一番でした。これも、広い意味での工夫です。



とあるプログラマ

リンク

2021/1/25(Mon) 18:50:14|NO.92151

エディタを標準のものから変えるのは個人的にもオススメです。
自分はVisual Studio Codeを使っていますが、キーワードのハイライトや入力候補のおかげで見やすさも上がりますし入力ミスによるバグも大幅に減らせます。

参考までに自分の環境の画像です。
https://i.imgur.com/pGU7YiR.png


あとは関数中にもスペースや括弧を入れて位置を揃えたり見やすくすることとかですかね。

if hoge=piyo*3+2 { 〜 } よりも if (hoge == piyo * 3 + 2) { 〜 } のほうが見やすい (個人的に)


他にやっていることは

・インデント管理はしっかり行う (エディタがインデントで範囲を省略できるタイプなので)

・改行、コメントを使ってパッと見の見やすさを上げる

・一連の流れはモジュール関数化して機能ごとにそれぞれ別ファイルに保存 (例:描画周りは drawing.hsp、設定IOは config.hsp など) し、メインのコードからは#includeと関数の呼び出しを行うだけ。
 (ただしこの方法はスパゲティ化の懸念もある)

・定数、マクロを使う。共通して何回も使う式などもマクロ化

・関数、変数名の命名方法の規則化 (PascalCase、snake_caseなどで統一)

・コードの先頭に範囲コメント(/*〜*/)を使って注意書きや備忘録などを書く。(未来の自分へメッセージ残すの割と重要です。時間空くと大体忘れます)

・userdef.as を利用する。(自分はhspmath移植したり共通利用する独自定義など書き込んでます)


などですかね…



アキアキノヒロロ

リンク

2021/1/26(Tue) 11:49:58|NO.92157

とあるプログラマさん、ありがとうございます。

「パッと見の見やすさ」って、大切ですね。それと、「全体の構成・構造的な把握のし易さ」。

> スペースや括弧。インデント。そして改行、(コメント)。
これって、「パッと見の見やすさ」と同時に、その箇所のコードの「構成・構造的な把握のし易さ」にもなりますよね。

> モジュール関数化。定数、マクロを使う。関数、変数名の命名方法の規則化。
これは、「全体の構成・構造的な把握のし易さ」。私の場合、ここを頑張らないといけない。

> (未来の自分へメッセージ残すの割と重要です。時間空くと大体忘れます)
これ、身に沁みて、実感してます。「注意書きや備忘録」も書きますが、プログラムのネーミングも工夫してます。
完成したものは、新たに付けますが、それとは別に、開発中のプログラムは、各段階での名前もその内容が分かるよう、工夫して付けています。
「バージョン」は、その都度の段階での完成ですから、「完成時の名前_.Ver_」となると思います。
しかし、各段階での開発中のプログラム、言わば、ベータ版のネーミングは、新たに取り組み、追加しているものが何であるか、すぐ分かる名前を付けて、保存しています。
それで、一つのバージョンであっても、その中に言わゆるベータ版としてのプログラムが、多い時は、10数個も並びます。
何故、そこまで保存するかというと、プログラミングを始めた頃、一応できたと思うと、すぐそのまま上書き保存していて、幾度となく痛い思いをしてきたからです。
あとで、バグ・エラーが発生しても、もとに戻してやり直すのに大変な労力を要しました。
そこまでのものを、各追加ごとに保存してあれば、問題なく動いていた段階のものは、どのプログラムまでか、探しやすく、そこへ戻って、エラーを回避する方法も考えやすいからです。

もしかしたら、各段階での開発中のプログラム、どの程度で保存するかは、各自の感覚で違いはあるでしょうが、皆さん、多かれ少なかれやっておられることでしょうね。
日付をネーミングに使っておられるのを見かけるのも、そうでしょう。
私は、追加課題を名前に入れているということです。



ONION software Copyright 1997-2021(c) All rights reserved.