PowerShell -Part 7

**デフォルトの名無しさん** · 2025/11/27(木) 16:35:40.04

powershell民なら
} else
と書いておく
こうすると解釈が延長するわけでelse節が無ければ次行で
{}
と書いて終わらすこともできる
これはpowershell民に限らず行志向言語の常識的イディオム

**デフォルトの名無しさん** · 2025/11/27(木) 16:51:14.83

>>661
その理由はおかしくないか？
以下のように同様の理屈が成り立つ

}
で終わらせておく
elseで続けたい場合は
else {
で始められる

**デフォルトの名無しさん** · 2025/11/27(木) 16:53:53.08

ああ、インタープリタ的な使い方ってことか

**デフォルトの名無しさん** · 2025/11/27(木) 16:58:55.38

ならとりあえず
} else {
と書いておくほうが良い気がする

**デフォルトの名無しさん** · 2025/11/27(木) 21:48:18.93

elseは使わないようにする

**デフォルトの名無しさん** · 2025/11/27(木) 23:03:58.47

5.xは三項演算子がないので他の言語よりelseを使う機会が多くなりがち

**デフォルトの名無しさん** · 2025/11/28(金) 10:07:39.92

Weekend Scripter: Best Practices for PowerShell Scripting in Shared Environment
https://devblogs.microsoft.com/scripting/weekend-scripter-best-practices-for-powershell-scripting-in-shared-environment/#use-consistent-indentation
PowerShellのコーディングスタイル
https://tech.guitarrapc.com/entry/2017/12/03/230119

**デフォルトの名無しさん** · 2025/11/28(金) 10:46:55.41

>>667
「ただし、これは、普段どちらで書いているかなどに左右されますし、チームでの共通化がとれていればいいのでしょう。

ちなみに、コミュニティでは、Stroupstrupが意外と多い結果です。」

**デフォルトの名無しさん** · 2025/11/28(金) 11:06:29.89

if 真ならelse の中いかないし
if 偽ならelse の中やりたいし
else 閉じて走るのがまずい状況がすぐに思い浮かばない

**デフォルトの名無しさん** · 2025/11/28(金) 15:12:40.52

これだけアチコチで使われてるとなると新興宗教とは言えない雰囲気

**デフォルトの名無しさん** · 2025/11/28(金) 20:46:10.65

なんにしろ行志向言語で中括弧を採用すること自体が悪手だったのは間違いない

**デフォルトの名無しさん** · 2025/11/28(金) 21:20:01.11

>>667
Stroupstrupって構文スタイルなのか…

しかもちゃんと「式解釈では問題ありませんが、PowerShellにはった時elseでエラーがでます。」って説明まで書いてる

いや、なんでこれが多いんだよ
意味わかんねぇよ…

**デフォルトの名無しさん** · 2025/11/28(金) 21:59:10.04

https://ja.wikipedia.org/wiki/字下げスタイル

ストロヴストルップ・スタイルはビャーネ・ストロヴストルップがC++で使ったK&Rスタイルで、ストラウストラップのプログラミング入門 C++によるプログラミングの原則と実践やThe C++ Programming Languageといった彼の著書で使われている。

前述のスタイルと異なり、cuddled else (elseの前後に}と{を置くスタイル) を使わない。したがってストロヴストルップ式では次のようになる。

if (x < 0) {
puts("Negative");
negative(x);
}
else {
puts("Non-negative");
nonnegative(x);
}

**デフォルトの名無しさん** · 2025/11/28(金) 22:18:41.05

誰だよスッポスッポ先生のことふざけた空耳日本語で呼ぶジャップは・・・

**デフォルトの名無しさん** · 2025/11/28(金) 23:42:10.29

else の後ろに括弧置いてるじゃん…

あ、いやそういう事じゃなくて不都合が発生しうる可能性があるスタイルをわざわざ使うってPowerShellにおいてはバカでしかないと思うって話
自分が良ければそれでいいって事？
少なくともインターネッツに載せるなら可能性が考慮されてなくてダメじゃね？

**デフォルトの名無しさん** · 2025/11/29(土) 10:54:08.34

ある人が書いたpowershellで動くスクリプトの書き方が
別の人がpowershellで動かしてエラーが出るのは困るよね
っていう話なの？

**デフォルトの名無しさん** · 2025/11/29(土) 12:36:08.79

スタイルだからそれぞれ拘りがあるってだけだろ
そのスタイルで統一されてれば問題ない

**デフォルトの名無しさん** · 2025/11/29(土) 14:43:58.37

良いスタイル悪いスタイルがあるのになぜか悪いスタイルが流行ってるって話だろ
そもそもスタイルが分かれるような構文を採用したのがだめなんだけどな

**デフォルトの名無しさん** · 2025/11/29(土) 15:48:53.71

おそらくC++から流れてきたんだろうと想像する
>>673にあるプログラミング入門 C++、The C++ Programming Languageが教科書になった人々

**デフォルトの名無しさん** · 2025/11/29(土) 16:28:37.98

C/C++のK&R派ではあるけど
文における{}
関数定義における{}
構造体/クラス宣言における{}
namespaceにおける{}
どれも扱いが違う
成形ツール使えばなんとでもなる
PowerShellなんてどうせ描き棄てだからどうでも良い

**デフォルトの名無しさん** · 2025/11/29(土) 16:48:02.25

例えば

先輩「PowerShell でこうやって IDE で書くこともできるけど普通に貼り付けて実行も1行ずつ実行する事もできる」

新人「ホントだ！ありがとうございます！」

新人「Windows標準で使えるし家でも勉強がてらやってみよう」
新人「うーん…よく分からない。検索するかぁ」

初心者向けWebサイト「(Stroupstrupスタイルで記述)」

新人「(貼り付けて)あれ？エラーが出る…よく分からない…」

みたいな話

初心者向けWebサイトはチームとかもないし誰が見るかも無いから、Stroupstrupスタイルは適していないってこと

ブログやQiitaとかならまぁええかとは思うし、チーム内で決めて使うならいいと思う

**デフォルトの名無しさん** · 2025/11/29(土) 17:02:38.86

} をどんな構文でも常に行末としておき、if と else if を行頭に並べればブロックが対称的に見えるので美しく感じる
そんな理由があるという
けど全然共感できない
ifブロックが単に2つ続いているだけのパターンと、ifとelse ifが続いているパターンを取り違えるのは古典的なバグ
ならcuddled elseのほうがあえて相似形を崩して即座に峻別できるように喚起できるので合理的

**デフォルトの名無しさん** · 2025/11/29(土) 18:21:27.95

powershellなんて基本書き捨てだしスタイルなんて気にしたことない
vscodeのフォーマッタ任せ

**デフォルトの名無しさん** · 2025/11/29(土) 23:17:33.20

公式ドキュメントでも
}
else {
になってるな

about_If
https://learn.microsoft.com/ja-jp/powershell/module/microsoft.powershell.core/about/about_if

**デフォルトの名無しさん** · 2025/11/30(日) 14:27:29.65

}
else{
でしか理解出来ないってのは池沼

**デフォルトの名無しさん** · 2025/12/04(木) 00:02:31.58

そういえばChromeとかFireFoxの開発者ツール画面のPowerShellでコピーっていつの間についてたのかしら
社内のしょうもないシステムのデータ落とすだけならマジでRPAとかいらんな

**デフォルトの名無しさん** · 2025/12/10(水) 08:52:12.78

PowerShell 5.1: Web コンテンツからのスクリプト実行の防止
https://support.microsoft.com/ja-jp/help/5074596

**デフォルトの名無しさん** · 2025/12/11(木) 09:00:26.27

「Windows PowerShell 5.1」に「IE」要素排除のための仕様変更
「Invoke-WebRequest」に警告を追加、2025年12月のセキュリティパッチ以降の適用で
https://forest.watch.impress.co.jp/docs/news/2070166.html