【UiPath】読みやすいフローを書くコツ（変数・引数編）

# はじめに

この投稿は、RPAツールの「UiPath Studio」で「読みやすいフロー」を書く方法 について、個人的にまとめたものです。量が多いので 数回に分けて書きます。

2023年7月開催の「UiPathブログ 発信チャレンジサマー」の7日目の記事でもあります。

https://note.com/shumpei_w/n/nd082bdf28853

前回は「概要編」として、以下の記事を紹介しました。

https://qiita.com/miya_gis/items/991c9afa0492377c4b9a

今回は「変数・引数」について。

```
目次
# 1）Studioにおける「変数・引数」
# 2）変数・引数は「分かりやすさ」が大事
# 3）変数の良くない使い方
# 4）変数引数を見やすくするコツ
# 5）ワークフローアナライザーでチェック
```

# 1）Studioにおける「変数・引数」

変数とは一般的に「`値・状態を格納する箱`」と言われます。

UiPathでも同様で、変数は「`Xamlの処理の中で値・状態を格納する`」ために使用されます。 引数は「`Xamlフローを呼び出したときに渡される変数`」のことです。

UiPath Studio では「`変数パネル`」で変数引数の設定ができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/092a0bd7-6edb-9eec-f77a-ccf6f9ec484a.png)
「Studio version22.7」以降では「`データマネージャーパネル`」でも変数引数を設定できます。
最近はこの「データマネージャー」を推している感じがあり、設定次第では変数パネルが表示されません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/f49ccaa2-db71-7e2b-92c0-37ccafdcb6ca.png)

データマネージャーを使うと「フローの縦幅が長く取れる」「タブを切替え不要で変数引数を一覧で見れる」「スコープが狭い隠れ変数を見逃さない」「グローバル変数を管理できる」などのメリットがあります。

https://docs.uipath.com/ja/studio/standalone/2022.10/user-guide/managing-variables

また、Studio上の「変数・引数」には、ルールがあります。

| 項目 | 内容 |
|:-:|:-:|
| 長さ | 制限は無い（？）が、推奨は３０文字以内  |
| 使用できる文字  | 数字・英字・アンダーバー  |
| 使用できない文字  | 記号・予約語  |
| 先頭文字 | 数字はダメ  |
| その他  | 日本語の使用可 |

変数引数の「長さ制限」はありませんが、ワークフローアナライザーでは、変数の文字列は「３０文字」とされています。長いと「可読性が下がる」ためでしょう。

https://docs.uipath.com/studio/lang-ja/docs/st-nmg-008

数字英字以外は「アンダーバー」しか使えません。「And・Or・Byte」等の.NETの予約語も使用できません。

https://learn.microsoft.com/ja-jp/dotnet/visual-basic/language-reference/keywords/

日本語の使用は可能です。英語とのmixも可能です（例：dt_価格マスタ）

# 2）変数・引数は「分かりやすさ」が大事

変数や引数を見た時に「分かりにくい」と可読性が落ちてしまい、フロー自体が読みにくくなります。

例えば、以下のような「変数」は、どうでしょうか？

```
・num　　　　　 ・・・番号の数字っぽいけど、なんだろう？行番号とか？
・データ値　　　・・・データという言葉が広すぎて予想できない。商品名とか？
・str_AriFlag　 ・・・フラグなのにString型？フラグONのときの文字は「ON」or「True」？
・AccountsReceivable　・・・どういう意味だろう？翻訳すると「売掛金」という意味だった！
```

どれも「パッと見」では分かりません。「曖昧／嘘の情報／長すぎる」のが分かりにくさの原因です。
もし分かりやすくするなら

```
・num　⇒ 「rowNumber」や「行番号」など
・データ値 ⇒ 「商品名」など
・str_AriFlag ⇒ 「bln_Exists」や「商品ありフラグ」など
・AccountsReceivable ⇒ 「売掛金金額」など
```

など、より「具体的な情報」を「シンプルに」示すようにすると良いでしょう。

:::note info
見たときに「何の値なのか？」を「違和感なく」伝えると、他の人にも優しくなって可読性が上がります。
:::

個人的には、以下を意識しています。

```
・できる限りシンプルに（短くズバッと）
・自然な名前（変に思われないように）
・スペルミス・誤記はダメ（もったいない）
・少し時間をおいて見直す（頭を冷やしてから再度見る）
・他の変数と足並みを揃える（書きっぷりを合わせる）
・他の人に見てもらう（意見をもらう）
```

自己チェックには限界があります。現場の書き方・ルールもあるでしょう。
他の人に相談したり、レビューしてもらうことで、プロジェクトに合った書き方を模索することが大事です。

:::note info
① 名前付けにこだわる
　「すっと理解できる」「誤解や疑問のない」「客観的に見て相応しい」名前が良い
② 周囲・周りのメンバーに合わせる
　独りで決めない。「プロジェクト」「メンバー」に合わせた書き方を探す
:::

UiPathでは変数引数に「日本語」も使用可能です。日本語のほうが「自然な名前」を付けやすく便利です。

https://qiita.com/miya_gis/items/3b94b7300fe3413fb252

:::note info
日本語で書いてもOK（日本語なら書きやすく分かりやすい）
「型名」を付けても良いかも（その方が良ければ）
:::

中身をイメージしやすくするために、先頭に型名をつけるのも有効です。

個人的に、配列・リスト・ディクショナリ・データテーブルなどの「複数の値から構成されるもの」は、型名をつけると区別できるので、分かりやすいと思います。（先頭に型名が付いていれば、名前の後ろに「リスト」等の文字が不要になるし。）

```
dt_　 ：DataTable型
lst_　：list型
ary_　：Array型
dic_　：Dictionary型

例）商品番号のリスト ⇒ lst_商品番号
```

少し変わった変数も、先頭に型名を付けることで「違う」という意思表示ができます。

```
elm_エラーメッセージ　・・・　画面上のエラー要素を取得した「UiElement型」の変数を示す
```

:::note info
大事なのは「ルール云々」ではなく「分かりやすさ・伝わりやすさ」を意識すること。
後で保守することも考えて、後で読み返した時に「優しくなる」ようにしたいものです。
:::


# 3）変数の良くない使い方

UiPathに限らず「変数の使い回しは避けるべき」です。バグの温床になりがち。

https://teratail.com/questions/335316

ただ「変数をやたらと増やしたくない」という気持ちは分かる。その場合は
```
　・初期化を必ず実施して事故を起こさない
　・分かりやすいコメントを付ける
```
等の工夫が必要です。

:::note info
「ループの中で使い回す変数」の扱いが悪く（初期化していないなど）、バグになることが多い。
「ループ」と「変数使い回し」は特に注意が必要です。
:::


Studioでは「変数スコープは狭い方が良い」という話もあり「取り間違え・使用ミス」を未然に防ぐ観点ではその通りなのですが、可読性を考えると「スコープが狭い」と変数自体を見逃してしまうデメリットがあります。（変数パネルでは、現在いるシーケンスの変数しか表示されないため、スコープの狭い・隠れた変数を見つけることが難しい）

:::note info
可読性を考えると、スコープが狭い変数は「悪／デメリットが大きい」です。
:::

ただ、前述の「データマネージャー」を使用すれば、xaml内の変数すべてを一覧で確認できるので、「データマネージャーを使って変数を管理しよう！」というプロジェクト／チームなら、スコープを狭くするのもありでしょう（現時点では、データマネージャーを使いこなしている人は少ないと思いますが）

ちなみに、Studio 23.4 で「宣言不要の変数」機能が追加されました。（下位互換は無いため、使用は注意が必要です）
将来的には「局所的に使用する変数は変数宣言しない」ほうが良くなるかもしれません。

https://qiita.com/miya_gis/items/b6a487a55a3ce3b62990#15%E5%AE%A3%E8%A8%80%E4%B8%8D%E8%A6%81%E3%81%AE%E5%A4%89%E6%95%B0


# 4）変数引数を見やすくするコツ

実装時に「この変数・引数が必要だな」と追加していくと、不要な変数が残ったり、変数の並びがバラバラになったりします。

変数引数パネルで見た時に「`並びがきれい`」例えば「同種類の変数は纏める」などの工夫があると「`変数から処理内容を予測出来る`」ので、可読性が上がります。

この時に「`引数に移動／変数に移動で並びをキレイに揃えられる`」ことを知っておくと便利です。
![uianime08.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/6faf3a30-3005-6924-2218-26c8f9ac46da.gif)

見やすさとは違いますが、新しく変数を作る際に「`すでにある変数の型を選択する`」ことで、型選択プルダウンに該当の方を表示させることが出来ます。
![uianime09.gif](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/fba6bf40-70f0-9bdd-b3e7-b890a1d9d2cc.gif)

また、変数引数に注釈／アノテーションを付けたものを見かけますが、注釈は確認しにくいので

```
・注釈が無くても、見た目で分かりやすい名前にしたほうが良い
・引数の説明が必要なら、Xaml上部に「引数説明」を書いたほうが分かりやすい
```

など、読み手を意識した実装をしたほうが良いと思います。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/641a219f-7816-00f6-4d21-8d8a75de2664.png)

# 5）ワークフローアナライザーでチェック

ワークフローアナライザーは、UiPathStudioに付いている静的コード アナライザーです。
高品質で信頼性のあるコードか？をチェックしてくれます。

https://docs.uipath.com/ja/studio/standalone/2022.10/user-guide/about-workflow-analyzer

ワークフローアナライザーのチェック項目に「変数引数」についてのチェック項目があり、例えば前述の「変数の名前は30文字を超えないようにする」も、チェックしてくれます。具体的なチェック項目は以下です。

| 名称 | 扱い| 内容 |
|:-|:-|:-|
| [ST-NMG-001 - 変数の命名規則](https://docs.uipath.com/ja/studio/standalone/2022.10/user-guide/st-nmg-001) | 警告|変数名が特定ルールに従っているか（正規表現でルールを指定）| 
| [ST-NMG-002 - 引数の命名規則](https://docs.uipath.com/ja/studio/standalone/2022.10/user-guide/st-nmg-002) | 警告|引数名が特定ルールに従っているか（正規表現でルールを指定）|
| [ST-DBP-002 - 多数の引数](https://docs.uipath.com/ja/studio/standalone/2023.4/user-guide/st-dbp-002)|エラー|ワークフローの引数が多いと分かりにくい|
|[ST-NMG-016 - 引数の長さが最大文字数を超過](https://docs.uipath.com/ja/studio/standalone/2023.4/user-guide/st-nmg-016)|警告|引数の名前が長いと分かりにくい|
|[ST-NMG-005 - 変数が変数をオーバーライド](https://docs.uipath.com/ja/studio/standalone/2023.4/user-guide/st-nmg-005)|警告|ワークフロー内の変数名はスコープが違っても同じではダメ（危険）|
|[ST-NMG-006 - 変数が引数をオーバーライド](https://docs.uipath.com/ja/studio/standalone/2023.4/user-guide/st-nmg-006)|警告|変数と引数で同じ名前になっていると、混乱を招く|

ワークフローアナライザーを使うと、コードの品質・可読性があがるので、ぜひ使ってみてください。


# 終わりに

以上「変数・引数編」でした。

この記事が参考になったら、 いいね をお願いします。閲覧ありがとうございました。