こんばんは、Sugachanceです。
かふぇルネ内を検索してみても出てくるように、みなさまは普段、temporarilyを表す変数名や関数名にtmpやtempという文字列を使用されていると思います。PC系のプログラミングではなくマイコンが絡んでくると、温度センサの情報を扱う事もあるかと思いますがtemperatureとの違いを明示的にわけたりされていますでしょうか？・temporarilyはtmp／temperatureはtemp・略さずにtemporarily／temperature と全部書く など…
通常の会社であれば、このあたりルール化されているのだと思いますが、弊社の場合、直接マイコンプログラムで商売をしているような会社ではないのできちっとしたルールがなく、現在検討しているところです…
そもそも、temperatureをtempやtmpなどと略すのは私だけだったり？？
Sugachanceさん こんにちはNAKAです。
何の温度かを示すとをデータ名に付加することもありますし、
水温情報：AB_TMP
そのままデータ名にすることもあると思います。
外気温：AMB
吸入空気温度１：THA１
エンジン水温情報：THWX
NAKAさん、おはようございます。Sugachanceです。
ありがとうございます。やはり、使いますよね…
たしかに「何の」温度の変数か明示する方法は良いかもしれません。(tmpはtemporarilyにとっておいて、温度は対象の名前を付ける)
※THはthermalですかね？センサを指してthermocouple?
Sugachanceさん こんにちは一会員です。
遅くなりましたが、温度の変数名の付け方について返信します。
私は幾つかのソースコードを見る機会がありましたが、
温度を格納する変数名はtemperaturetmpethなどの記述を見たことがあります。
一時的に値を格納する変数名はtemptmpなどです。
変数名の命名ルールを一覧表にしている組織もありましたが、これまでのソースコードの資産活用やメンテナンス、各組織の流儀などもあり、組織横断の統一の命名ルールを策定することは難しいと感じました。
Sugachanceさん はルールを検討中とのことですが、ソースコードの可読性やメンテナンス性を挙げるのに大変役立つと思いますので頑張って下さい。
【追伸】既に検討済かもしれませんが、変数名にデータ型などを表わす接頭文字を付けることも、代入やキャストの妥当性確認などで役に立つと思います。
ハンガリアン記法が有名ですが、RL78などであれば次のようなルールも簡易で分かり易いのではないでしょうか。（接頭文字として符号とビット数を記述する）
signed char → s8_・・・unsigned char → u8_・・・signed int → s16_・・・unsigned int → u16・・・signed long int → s32・・・unsigned long int → u32_・・・・・・等々・・・
差し出がましいとは思いましたが、ご参考まで。
一会員様、こんにちは Sugachanceです。
ありがとうございます。やはり、tmp,tempと温度関係はしっかりと分けてらっしゃるケースが多そうですね。システムハンガリアンは悪ってのも通説になっていますし慎重に考えたいところです。社外に出すことはほとんどないだろうし、Cだと特に問題はないのかもしれませんが...
「システムハンガリアンは悪が通説」との情報提供ありがとうございます。「システムハンガリアンは悪」と言うのはマイクロソフトが「一般的な名前付け規則」(2007年)でハンガリアンを禁止したのがきっかけのようですね。私はＰＣ系のプログラミングにはあまり関係してこなかったので、浦島太郎になっているようです。
確かに、最近のルネサスエレクトロニクスのサンプルプログラムの変数の接頭文字もグローバルを意味するg_・・・だけになっているようですね。
ただ、ルネサスエレクトロニクスのサンプルプログラムにも、次のような接頭文字を使用しているものもあります。
g_u1_・・・g_u2_・・・g_u4_・・・g_s1_・・・g_s2_・・・g_s4_・・・（変数の有効範囲_符号バイト数_・・・）
三相誘導モータのベクトル制御 (RL78/G14実装編) Rev.1.00 - Sample Code Back to topwww.renesas.com/.../vector-control-three-phase-induction-motor-rl78g14-rev100-sample-code
また、私が関係した組織の中には、接頭文字をルールとして定めているところもありました。
近年、変数の接頭文字が省略されてきているのは、現在のＩＤＥのテキストエディタは、変数にカーソルを合わせると型が表示されるので、演算・代入時の型の整合性チェックが容易になっていることや、チェックツールが充実してきていることもありそうですね。
演算・代入時の不整合が起きなければ、慣れた使いやすいルールを定めるのが良いと思います。一般的に複雑なルールは、効率が悪く、使われなくなっていくようですから。
こう言っては身も蓋もないですが文脈によるのではないでしょうか？一律に統一しようというのは無理があると思います。
温度を扱わないアプリならどうでも良いと思いますし、温度に加えてテンプレートを扱うアプリならtmpでもtempでも困りますよね。
ローカル変数ならあまり気にする事は無いですが、温度と一時データを扱う関数があるのならフルで綴るか、いっそのこと温度の方を”ondo”にしてしまうのも個人的にはアリだと思います。
大事なのはアプリの中で統一されてる事、混在する場合は違いが分かる事だと思います。
ハンガリアンについては非常に良い文書があります。本人が辞めてしまったのでWeb Archiveで申し訳ないですが。
間違ったコードは間違って見えるようにする
Sugachanceさんがルール化をしようとしているのは応援したいです。
Sugachanceさんがルール化をしようとする動機はわかりませんが、
一般的に、ルール化をしようとするのは、
・多人数での開発や相互レビューを円滑にしたい・他の開発者へのソースコードの引き継ぎを円滑にしたい・長期間経過後に改造やメンテナンスの必要がある
ため少しでも組織内や自分自身の可読性を上げておきたいということなどが考えられます。
変数名が長くなるとソースコードが読みにくくなりますので、ある程度
よく使われる変数名の省略形を統一しておくことは良いことだと思います。
windypon said:一律に統一しようというのは無理
ですよね
ひとつの方法ですがつながっているハードウェアなりにしています
PT100温度センサであればpt100とか
windypon様＞温度と一時データを扱う関数があるのならフルで綴るか、いっそのこと温度の方を”ondo”にしてしまうのも個人的にはアリだと思います。この辺が個人個人でバラバラなので、決めましょうというところが本質であります。個人で選べるなら選べるで、「プロジェクト開始時に明示する(ヘッダーに書く、文書に書くetc...)」というようなことすら何にもないので、必要なのではないかと思っているところです。
ハンガリアンについては参考にさせていただきます。ありがとうございます。
一会員様
おっしゃる通りの内容と、機能安全など世の中の流れを見ていると、この辺りのドキュメントをしっかり作っておいたり、静的解析ツールみたいなものを使っていかなければならなさそうな雰囲気を感じております。IPAのお作法ガイドなどを参考に少しずつ始めようという事でまずはとっつきやすそうな(他のメンバーも不便を感じたことがありそうな)変数名を考えるところからスタートした次第です。