UiPath で些細だけど意識しておきたいあれこれ
自分の備忘録をかねて。
コーディング規約やチェックツール
先に一番大事なことを書くと、なによりこういったことをコーディング規約化したり、ワークフローアナライザーなどを整備したりすることですね、はい。
しかし、きちんとした開発プロジェクトで書かれるコードだけでなく、アドホックに導入されたライセンスや環境で、自分の部署の目の前の仕事を自動化するようなお膳立てのない環境で使われることも多いでしょう、ノーコードは。それなので、コーディング規約やアナライザーの整備とは別に、直感的に分かりやすい書き方を個々人がなんとなくでも意識しとくことがそれなりに大事なんじゃないかなとも思っています。
かっこを省略できるメソッドがある
だけどかっこは省略せずに書いたほうがいい。そのほうがメソッドだと一見してすぐ分かるので。 toStrng とか連発するコードだと少しでもコードを短くしたいという気持ちも分かるが。
ちなみに、引数が０なら常にかっこが省略できる、というわけではないようだが詳細を知らない。 VB の仕様を調べれば分かるのかな。
参考
なるべく Activity 個別にプロパティの値を変更しない
ここの遷移でたまにおちるんだよな、よし Timeout 値を長くしたろ
というのはよくあるんだけど、基本的にはプロジェクト全体のデフォルト値を調整することをまずは意識する。そうしないと全体のパフォーマンス悪化に繋がったり、個々の処理のブラックボックス化が進む。ユーザコードに一覧性があるテキストプログラミングとビジュアルインターフェイスで階層化されるノーコードで感覚を Adjust するポイントの１つ。
それでも Activity 個別にプロパティの値を変更するならアノテーション（コメント）を書く
さらに、コメントは「なぜ変更しているか」を添えて書く。じゃないとさらにいじっていいのか他の人に分からない。
変数名の先頭は型名を反映する
入力ファイル名 や 入力ファイル名の文字列 ではなく、
ｓｔｒ_入力ファイル名 のように。
商品名リスト のようなケースでは lst_商品名 とすることで情報量を損なわずより判然とする。
型名をどう省略するかのルールはあまり体系だったものを見つけなかったけど、メジャーな型はふんわりと慣習があるようだ。
-
dt_→DataTable型。 これは ワークフローアナライザーのルールにもあるようですね。個人的には [DateTime] 型とまぎらわしい場合もあるかも（なのでコーディング規約大事） -
str_→String型 -
int_→Int32型 -
ary_→Array型 -
dic_→Dictionary型
Boolean型 は bool_ ？ それとも is_XXXXXX にするほうが分かりやすいのかな？
今後も思い出したら随時追記予定です。
Discussion