[WIP] ソースコードの整形の実験 #1172

m-tmatma · 2020-01-26T03:18:57Z

PR の目的

[WIP] ソースコードの整形の実験

カテゴリ

リファクタリング
実験 (master へのマージを目的としない)

PR の背景

sakura-editor/management-forum#29

でソースコードの整形をすることに関して議論したが結論が出なかった。
試しに整形してみて、議論のネタにする。

PR のメリット

Visual Studio が勝手にソースコードを整形しても不要な差分が出なくなる。

PR のデメリット (トレードオフとかあれば)

既存の PR がコンフリクト祭りになる
インデントがタブからスペースに代わる

注意

アセンブリ出力を確認するために、一部テストコードを入れている
(Debug用) とつけているコミットを入れることで一致させることができた。

assert の定義を空にする
ソースコードをアセンブリ出力に含めない
assert をコメントアウト (assert の中の条件式がログ出力のために文字列定数として使われるので完全一致させるためにコメントアウト)
メモリ関係の呼び出しの直前に #line で行番号を固定
- __malloc_dbg
- __realloc_dbg
- __wtempnam_dbg
- __wcsdup_dbg

ビルド

https://ci.appveyor.com/project/m-tmatma/sakura/builds/30513581 (整形前)
https://ci.appveyor.com/project/m-tmatma/sakura/builds/30513587 (整形後)

PR の影響範囲

参考資料

AppVeyorBot · 2020-01-26T03:47:54Z

✅ Build sakura 1.0.2568 completed (commit d845635630 by @m-tmatma)

beru · 2020-01-26T05:58:56Z

sakura_core/CEol.cpp ファイル冒頭のグローバル変数の配列初期化子の記述ですが、書いた人は意図して空白を入れてインデント位置を揃えてコードを見易くしていると思うんですよね。

今ある自動フォーマッタはまだまだこういうのを考慮して良い塩梅で調整はしてくれないと思うので、あーあ…って感じです。とはいえ人によっては、そんな些細な事より自動フォーマットで得られる価値の方が大きい、と思うかもしれません。

AppVeyorBot · 2020-01-26T06:21:27Z

✅ Build sakura 1.0.2570 completed (commit 559106f23a by @m-tmatma)

berryzplus · 2020-01-26T08:24:17Z

サクラエディタのソースコードに特有なフォーマット

関数呼出の丸括弧内部に空白が挿入される。
- 呼出と宣言と両方。
- Visual Studio のフォーマット設定で実現できそう。
- sizeof(aaa) や _T(aaa)、LS(aaa) のように例外となる規約（？）が複数存在する。
- 例外となる規約（？）についてはフォーマッタでの実装が無理っぽい。
if、else if、elseブロックの空白挿入位置が変。
- if( condition ){}という書き方。
- }else if( condition ){}という書き方。
- }else{}という書き方。
- 規約無視箇所多数。
- Visual Studio のフォーマット設定では実現できなさそう。

C++的な標準はたぶん、

func(arg1, arg2); という形式。
if (condition) {} という形式。
} else if (condition) {} という形式。
} else {} という形式。

やってしまってもいいと思いますが、#1172 (comment) の問題があるのでドキュメントフォーマットでやるのは辛いのかな、と思いました。

javaというか、Eclipseにはソースコードの自動フォーマットを一部除外する機能があります。
https://teratail.com/questions/85772

Visual Studio に同等の機能があれば、それを活用することも検討したいです。
（Eclipseと完全に同等だと除外範囲をコメントタグで囲わないといかんので、めんどいんですが。）

AppVeyorBot · 2020-01-26T10:32:07Z

✅ Build sakura 1.0.2573 completed (commit cfe0911b54 by @m-tmatma)

m-tmatma · 2020-01-26T10:47:44Z

現在の状態

fileNo → 指定フォルダ内の cpp/h ファイルの数
diffCnt → フォルダ内で asm ファイルが変更前と異なるものの数 (0 だと指定フォルダですべて一致)
(asm で計算しているので h ファイルの数は含まない)

folder	fileNo	diffCnt
.\HeaderMake	1	0
.\MakefileMake	1	0
.\sakura_core\apiwrap	5	0
.\sakura_core\basis	21	0
.\sakura_core\charset\icu4c	2	0
.\sakura_core\config	5	0
.\sakura_core\convert	37	0
.\sakura_core\debug	8	0
.\sakura_core\doc\logic	4	0
.\sakura_core\extmodule	14	0
.\sakura_core\func	8	0
.\sakura_core\mfclike	2	0
.\sakura_core\parse	2	0
.\sakura_core\print	4	0
.\sakura_core\util	35	0
.\sakura_core_os	5	0
.\tests\unittests	14	0
.\sakura_core\doc\layout	10	1
.\sakura_core\prop	20	1
.\sakura_core\types	24	1
.\sakura_core\charset	37	2
.\sakura_core\docplus	8	2
.\sakura_core\io	14	2
.\sakura_core\mem	12	2
.\sakura_core\plugin	14	2
.\sakura_core\uiparts	13	2
.\sakura_core\typeprop	18	3
.\sakura_core\cmd	24	4
.\sakura_core\doc	26	4
.\sakura_core\macro	26	4
.\sakura_core\outline	8	4
.\sakura_core\recent	37	4
.\sakura_core_main	18	4
.\sakura_core\env	24	6
.\sakura_core	70	8
.\sakura_core\window	18	8
.\sakura_core\view\colors	19	10
.\sakura_core\dlg	52	12
.\sakura_core\view\figures	16	14
.\sakura_core\view	36	17

AppVeyorBot · 2020-01-26T11:00:40Z

✅ Build sakura 1.0.2574 completed (commit b5be883d09 by @m-tmatma)

beru · 2020-01-26T13:04:49Z

javaというか、Eclipseにはソースコードの自動フォーマットを一部除外する機能があります。
https://teratail.com/questions/85772

Visual Studio に同等の機能があれば、それを活用することも検討したいです。
（Eclipseと完全に同等だと除外範囲をコメントタグで囲わないといかんので、めんどいんですが。）

Visual Studio で指定範囲をフォーマット対象から外す方法は分かりません。

clang-format の場合は下記のようにして囲めば対象外に出来ますが、それを入れる事でコードがなんか汚くなる気もして本末転倒だなと思ったりしました。細かい事を気にしすぎかもしれませんが…。

// clang-format off
フォーマット対象から外したいコード
// clang-format on

大量のコードを手動で特定のスタイルに修正するのは大変で普通は手動でやりたがらないだろうと思います。なので、一部のコードの見た目が崩れるとしてもそういうのには妥協というか目をつぶって自動フォーマッタを使いたいという考えもまぁ分からなく無いです。つまるところ人によって論理や感覚や何を優先するかの好みって色々だと思うので。

ある時点でスタイルを統一したとしても、その後に誰かがPRで変更を入れるたびに細かく指摘したり、あるスタイルに則るように強制したりとかがないと良いなぁと思います。常に特定のスタイルで統一させたい人もいるかもしれないですけど。:sweat_smile:

berryzplus · 2020-01-27T13:23:50Z

fileNo → 指定フォルダ内の cpp/h ファイルの数
diffCnt → フォルダ内で asm ファイルが変更前と異なるものの数 (0 だと指定フォルダですべて一致)
(asm で計算しているので h ファイルの数は含まない)

何故、差分が出るのか？って、検証してます？
コメントに差が出るのは仕方ないとして・・・コメントは削ってるっぽいので心当たりがないっす。

m-tmatma · 2020-01-27T13:25:31Z

解析は途中です

m-tmatma · 2020-01-27T13:26:50Z

ただ週末まで再開できないです

m-tmatma · 2020-01-27T13:28:23Z

主にデバック版で差分が出てます

berryzplus · 2020-01-27T13:32:50Z

大量のコードを手動で特定のスタイルに修正するのは大変で普通は手動でやりたがらないだろうと思います。なので、一部のコードの見た目が崩れるとしてもそういうのには妥協というか目をつぶって自動フォーマッタを使いたいという考えもまぁ分からなく無いです。つまるところ人によって論理や感覚や何を優先するかの好みって色々だと思うので。

ある時点でスタイルを統一したとしても、その後に誰かがPRで変更を入れるたびに細かく指摘したり、あるスタイルに則るように強制したりとかがないと良いなぁと思います。常に特定のスタイルで統一させたい人もいるかもしれないですけど。😅

機能的な差異が出ないことの確証がとれてからの話になりますが、
フォーマット適用後は「自動フォーマット適用推奨」の流れになると思っています。

というか、CIにチェックスクリプトを組み込む流れになる予想です。
そうなることを含めて、いまんとこフォーマッタ適用支持だったりします。

だって、目で見て指摘するのめんどくさいじゃないですか（色んな意味で。

berryzplus · 2020-01-27T13:37:19Z

ただ週末まで再開できないです

了解っす。気が向いたらこっちでも調査してみます。（たぶんやんないｗ

主にデバック版で差分が出てます

ヘッダをインクルードする順番によって使われる assert の定義が違ってしまっているのでは？とかそんなことを思いました（未検証。

「ヘッダーの依存関係が適切でないかもしれない」って予想がアタリだとすると何気にやっかいな課題になるかもです。

beru · 2020-01-27T14:26:31Z

機能的な差異が出ないことの確証がとれてからの話になりますが、
フォーマット適用後は「自動フォーマット適用推奨」の流れになると思っています。

というか、CIにチェックスクリプトを組み込む流れになる予想です。
そうなることを含めて、いまんとこフォーマッタ適用支持だったりします。

だって、目で見て指摘するのめんどくさいじゃないですか（色んな意味で。

CIのチェックスクリプトでフォーマッタ適用結果と差分が出た際にPRのレビューワーがどう判断するかは人それぞれかもしれません。ですが、引っ掛かってるから直してちょ的な指摘を誰かがして解消されない限りApproveしない場合それって最早暗黙のルールみたいなものではないかと思います。とはいえ個々のレビューワーの内々の判断基準にまで口出しするのってそれこそどうなの？とか言われたら、はいそうですね、って感じになりそう。

コーディングスタイルにルールは決めないっていう方針みたいのが有った気がしますが結局は、絶対的なものは絶対にない、的な感じで近い内になし崩しになりそうですね。

berryzplus · 2020-01-30T01:05:08Z

この件のownerは @m_tmatma さんなので、実験の結果どうするかの判断は投げる感じです。

コーディングスタイルの策定は、みんなが迷わずにコーディングをするために必要なものです。

通常のプロジェクトではアーキテクチャ策定の一環として行います。大きなプロジェクトを成功させるには、作る前にルールを決めるのが必須です。

既に完成しているサクラエディタで決め直すのは本来的には「変」だと思うんですけどね。

ルール決めないのはルールじゃないはず。

単に決められなかったの後付けで決めないって説明つけただけなので、必要なら新たに決め直したらよいと思います。

サクラエディタを建造物に喩えると、ちょっと豪華な民家風の民宿だと思うんです。

これを、豪華な今風のリゾートホテルに建て替えたいって話が出ています。(普通に考えたら不可能です。

やろうとしてるのはそういう作業だと思っとります。

AppVeyorBot · 2020-01-31T21:32:42Z

✅ Build sakura 1.0.2578 completed (commit 5e3b0cf26b by @m-tmatma)

AppVeyorBot · 2020-02-01T00:09:32Z

✅ Build sakura 1.0.2579 completed (commit 57110deadb by @m-tmatma)

AppVeyorBot · 2020-02-01T10:20:03Z

✅ Build sakura 1.0.2580 completed (commit 3e8257ea10 by @m-tmatma)

berryzplus · 2020-02-02T04:30:50Z

ヘッダをインクルードする順番によって使われる assert の定義が違ってしまっているのでは？とかそんなことを思いました（未検証。

「ヘッダーの依存関係が適切でないかもしれない」って予想がアタリだとすると何気にやっかいな課題になるかもです。

単に行番号( LINE ) がズレる話だったみたいですね。

AppVeyorBot · 2020-02-02T04:46:43Z

✅ Build sakura 1.0.2584 completed (commit d1a8a2b6e4 by @m-tmatma)

berryzplus · 2020-02-02T04:51:10Z

何故、差分が出るのか？って、検証してます？
コメントに差が出るのは仕方ないとして・・・コメントは削ってるっぽいので心当たりがないっす。

この課題に対する原因が以下。

sakura/sakura_core/debug/Debug2.h

Lines 41 to 55 in b3278eb

    
           #define assert(exp) \ 
        
           { \ 
        
           	if(!(exp)){ \ 
        
           		debug_output("!assert: %hs(%d): %hs\n", __FILE__, __LINE__, #exp); \ 
        
           		debug_exit2(__FILE__, __LINE__, #exp); \ 
        
           	} \ 
        
           } 
        
           #define assert_warning(exp) \ 
        
           { \ 
        
           	if(!(exp)){ \ 
        
           		debug_output("!warning: %hs(%d): %hs\n", __FILE__, __LINE__, #exp); \ 
        
           		warning_point(); \ 
        
           	} \ 
        
           }

ソースコードに行番号(__LINE__)を埋め込む記述なので、
オートフォーマットで改行位置が変われば差分が出る、という仕組み。

いったんソースコードに行番号が入らないようにしてる作業の途中・・・。

assert定義を削ってみる　→　ビルドエラー（まぁ、そうなりますな）
assert利用箇所をコメントアウトしてみる　→　ビルドエラー（何故だ！）
assertの定義内容を変えて __LINE__ を埋め込まないようにする（次はコレかな？）

m-tmatma · 2020-02-02T05:09:11Z

説明欄を更新しました。
アセンブリ出力を一致させるために行ったことを書いています。

berryzplus · 2020-02-02T07:57:18Z

PR のデメリット (トレードオフとかあれば)

既存の PR がコンフリクト祭りになる
インデントがタブからスペースに代わる

これってなんでしたっけ？

フォーマッタかけると \t が \x20 になってしまう
\t の代わりに \x20 を使うよう設定したのでそうなる

どっちかだと思いますが、いずれにしろ理由説明が必要だと思います。

理由があるなら「代わる」じゃなくて「変える」ですよね。
理由がないなら変えない方法を模索したいっす。

m-tmatma · 2020-02-02T08:05:04Z

フォーマッタかけると \t が \x20 になってしまう

です。

berryzplus · 2020-02-02T08:10:35Z

•メモリ関係の呼び出しの直前に #line で行番号を固定
◦__malloc_dbg
◦__realloc_dbg
◦__wtempnam_dbg
◦__wcsdup_dbg

これな。
https://docs.microsoft.com/ja-jp/visualstudio/debugger/crt-debug-heap-details?view=vs-2019

msvcのメモリ確保関数には、トレース機能が付いていて、解放漏れが検出されたときにメモリ確保が行われたファイル名＆行番号を報告する仕様になっているわけです。

フォーマッタの適用で行番号がずれると当然そこに差分に出てしまうので、
差分を出さないようにするためには対策する必要があった、と。

berryzplus · 2020-02-02T08:21:11Z

1.フォーマッタかけると \t が \x20 になってしまう

です。

何故だっ！ｗｗｗ

vs2017で普通に新規関数を書くと、関数本体は \t でインデントされてます。

デフォルトのエディタ設定とデフォルトのフォーマッタ設定が矛盾してる？（ＭＳバグか！
おいらの環境のエディタ設定がデフォルトじゃない？（どうやって調べる？

これの実験の話とは別に、どんな設定でフォーマットするのか？を検討せにゃならん気がします。

どっかに標準があればいいけど、たぶんないのでvs2017クリーンインストール時の設定とかに盲目的に追従することになるのかな、と思っています。

m-tmatma · 2020-02-02T08:25:28Z

vs2017で普通に新規関数を書くと、関数本体は \t でインデントされてます。

私の環境でもそうです。
空白でインデントされているコードの直後に改行して
インデントしたらタブが挿入されました。

m-tmatma · 2020-02-02T08:28:25Z

https://clang.llvm.org/docs/ClangFormatStyleOptions.html

で BasedOnStyle として、Microsoft が追加されていたので

"C:\Program Files\LLVM\bin\clang-format.exe"  -dump-config -style=Microsoft > .clang-format

で .clang-format を生成して

"C:\Program Files\LLVM\bin\clang-format.exe" -style=file -i sakura_core\CWriteManager.cpp

というように整形してみましたが、
Visual Studio による整形とも違ってました。

m-tmatma · 2020-02-02T08:31:04Z

2. おいらの環境のエディタ設定がデフォルトじゃない？（どうやって調べる？

.editorconfig をみているのかもと思ったが、削除しても同じだった。

berryzplus · 2020-02-02T10:12:38Z

ん？やってるはずの操作を手元で検証した結果とずれてそうです。

sakura_core/types/CType_Cpp.cpp を vs2017 のエディタで開く
Ctrl + K、Ctrl + D でドキュメント全体をフォーマットする（変更された行が黄色くなる
Ctrl + S で上書き保存する（変更された行が黄緑色になる

この手順の後にサクラエディタで sakura_core/types/CType_Cpp.cpp を開くと、行頭インデントは \t になっていました。Edit.FormatDocument は 2 の手順と等価だと思いますので、3 に相当する何かが足りない感じなのかな？と思いました。

berryzplus · 2020-02-07T01:08:08Z

話の流れを忘れとりました。

一括フォーマット適用後にそれと異なるスタイルのPRがなされたらどうするか？について、「許容で良い」の見解は変わってません。

ただし、コーディングスタイルが他と異なっていたら意図は確認すると思います。

めんどくさいですが、そういうどうでもいいことを含めて「何故そう変えるのか」を明らかにし、第三者視点から変更の妥当性を検証するのがレビューだと思うので。

コード開発をある程度の多人数で行い、かつ、個々のプログラマーの成熟度があまり高くない場合、コーディング規約の策定は必須だと思います。

可能な限り「アフォでも参加できるプロジェクト」としていきたいのでコーディング規約があったほうがいいと思っています。

まとめ
許容するけど指摘はするよ。
規約なしで行く方針だけど、作ったほうが良いと思うよ。

m-tmatma · 2020-02-07T21:20:13Z

ん？やってるはずの操作を手元で検証した結果とずれてそうです。

別の PC でやった場合、インデントはタブになったのですが、
それ以外のところでいっぱい差分が出ました。

何か visual studio 側の設定が違うのか、バージョンが違うのか、何かプラグインが
影響しているのかもしれません。

Visual Studio が勝手にソースコードを整形しても不要な差分が出なくなる。

のところが担保できるのであれば、 clang-format.exe で整形してしまいたいですが。

beru · 2020-02-08T05:56:09Z

Visual Studio の Text Editor > C/C++ > Formatting の設定は人によってはカスタマイズして使う事があると思いますが、設定ファイルか何かを自動で読んでサクラエディタのプロジェクトの場合に決まった設定を使うという事であれば運用しやすいかなと思います。VSで扱うプロジェクトを変える度にウィザードを操作して設定をインポートし直すのは面倒だし出来ればやりたくないです。

beru · 2020-02-08T09:33:03Z

一括フォーマット適用後にそれと異なるスタイルのPRがなされたらどうするか？について、「許容で良い」の見解は変わってません。

ただし、コーディングスタイルが他と異なっていたら意図は確認すると思います。

めんどくさいですが、そういうどうでもいいことを含めて「何故そう変えるのか」を明らかにし、第三者視点から変更の妥当性を検証するのがレビューだと思うので。

コーディングスタイルを揃えた後の話ですが、その後のPRで特に変える必要がないのにコーディングスタイルだけ変えてるような変更が有った場合は、あえてツッコミを入れるのは有りだと思います。ただスタイルを統一している事を関知していない誰かが新規で1000行とかのPRを作成した場合に、コーディングスタイルが既存のものと違うからといって補導 & 査問 & 尋問とかは止した方が良いと思います。

コード開発をある程度の多人数で行い、かつ、個々のプログラマーの成熟度があまり高くない場合、コーディング規約の策定は必須だと思います。

可能な限り「アフォでも参加できるプロジェクト」としていきたいのでコーディング規約があったほうがいいと思っています。

まとめ
許容するけど指摘はするよ。
規約なしで行く方針だけど、作ったほうが良いと思うよ。

コーディング規約を決めた方が良いと思う理由って人によって様々かもしれないですね。

そもそもは @m-tmatma さんが Visual Studio のエディタにペーストした際にコードが勝手に整形されるけどそれで差分が出るのが嫌だから、って事が発端ですよね？

sakura-editor/management-forum#29 (comment)

Visual Studio の設定を変えて、ペースト時に自動的に整形しないようにするのはいかがでしょうか？

これだと、ソースコードを編集したい人すべてに対して、Visual Studio の設定をあらかじめ
設定してください、というルールを導入するということになります。

自分の意見としてはそれが嫌ならVSの設定を変えれば良いじゃないかと言ったら、

差分がいちいち出るのが嫌という個人的な問題への対処方法として設定を変えたらどうか？と聞いたら、それはソースコードを編集したい人すべてに対してルールを導入する事になると言われました。なんか話が噛み合わない気がしますが…。

何かルールを導入するというわけではなく、何も設定せずに visual studio で編集したときに
visual studio が気を利かせて? スタイルを調整することで差分が出てしまうのであらかじめ
そのスタイルにしたいということです。

@m-tmatma さんとしてはコーディング規約を策定したいわけではなくあくまで差分が生じないように特定のスタイルにしたいのかもしれません。なので、ルールを導入するわけではないと表明したのかもです。

ただ今の @berryzplus さんとのコメントの流れだとコーディング規約は策定するという方向に行っているような気がします。

インデント位置とか括弧の前後の半角スペースの有無が揃っていないと気になるのでコーディング規約を導入するのもまぁ良いんじゃないかとも思います。自分好みだと良いですがまぁそうでなくても多少は我慢は出来ます。

ただ統一させる事に腐心するのってどうなのかなぁって気もしちゃいます。今のままじゃ駄目なんですか？みんなの好みも色々だろうし…。

berryzplus · 2020-02-08T12:33:08Z

結局、コーディング規約を策定する「必要があるのか？」というと「ない」と思っています。

コーディング規約が必須なプロジェクトの条件として2つ書きました。

ある程度の多人数でコード開発を行う場合
プログラマーの成熟度があまり高くない場合

サクラエディタのプロジェクトに関して「どないやねん！」と考えた場合、
いずれの条件にもあてはまりません。

なので現状、コーディング規約は不要です。

もちろん、ずっとこのままで良いか？と考えたら違う見方になってきます。

もっとたくさんの人が参加できるようになったほうがたぶん楽しいぞ。
経験の浅い次世代プログラマーが参加できるようにしといたほうが先の心配がないぞ。

現状のプログラミングスタイルに関する合理的な理由の考察。

たぶんこういうことだと思います。

    if( conditionA == true &&
        conditionB == true ){
        // ↑インデントにより条件の開始位置が揃っている

現代基準では、改行位置は短絡ANDの「前」とするのが定石だと思います。（もちろんどちらでも良いですが、書籍のスタイルガイドに明記される指針では行頭派が多い気がします。

短絡ANDや短絡ORの位置を行末とする、な規約が存在するのであれば、合理的なスタイル指針だといえなくもないです。

Visual Studioのエディタ設定を変えて現状の規約（？）に合わせる試み。

無理でした。詳細

現状にあわせてみようとして無理だったから、現状を標準（？）に合わせてしまおうとしてる感じです。

なんかちょっといま、迷走してる感じですけど 😄

berryzplus · 2020-02-15T18:14:36Z

このPRでやってることって、主にデバッグビルドのasm出力が変わることへの対策ですよね・・・。

視点を変えて「フォーマット適用前後の変更なし確認はリリースのasmで行う」としたら、テストコードを適用する必要はなくなるし、挿入したテストコードを確実に除去するための作戦を考える必要もなくなるような。

もちろん、リリースビルドにしたら差分が出ないかというとちょっと違くて、意図的に行番号を挿入している箇所は差分になりますよね。そんなに数は多くないと思うので、そこは個別に確認でよいような気がします。個人的には差分を出さないためにテストコードを入れて戻し忘れるリスクが怖いっす。

まぁそれ以前に「どうやってフォーマットを適用するか？」に課題がある感じ（＝環境によってフォーマット結果が変わってしまう）なので、そこを解決するのが先決ですかね。

m-tmatma · 2020-02-15T21:39:17Z

もちろん、リリースビルドにしたら差分が出ないかというとちょっと違くて、意図的に行番号を挿入している箇所は差分になりますよね。そんなに数は多くないと思うので、そこは個別に確認でよいような気がします。個人的には差分を出さないためにテストコードを入れて戻し忘れるリスクが怖いっす。

今回試行錯誤で試したのでコミットを分けていますが
何をしたらいいのか分かったので、テスト用のコードを
一つのコミットにしたら抜き忘れることはないと
思います。

今回でも、コミット等にログに　debug用と入れているので
区別できると思います

berryzplus · 2020-03-29T04:00:19Z

#1172 (comment) の原因が分かりました。(確定でもないんですが(^^;

1.フォーマッタかけると \t が \x20 になってしまう

です。

何故だっ！ｗｗｗ

clang-format の実行ファイル名は clang-format.exe です。
docs.microsoft にウソ書いてあったので、ウチの環境には入ってないと誤解しとりました。

既定では、Visual Studio は clangformat.exe をバックグラウンドで実行し、ユーザーが入力すると書式設定を適用します。

フルパスは以下です。
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\vcpackages\clang-format.exe

インストールされているバージョンは6.0っぽいです。
clang-formatには現在の設定をダンプするオプションがあるようです。

C:\Users\berryzplus> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\vcpackages\clang-format.exe" -version
clang-format version 6.0.0 (tags/RELEASE_600/final)

C:\Users\berryzplus> cd C:\work\sakura-editor
C:\work\sakura-editor> "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\vcpackages\clang-format.exe" -dump-config
Language:        Cpp
...(省略)
Standard:        Cpp11
TabWidth:        8
UseTab:          Never

なんとなく分かると思うんですが、「UseTab」は「タブを使うか」を設定する項目で、「Never」は「使わない」です。
つまり、タブを空白に変換する設定になっとります。

え？マジで？

と visual studio 2017 の clang-format リリース告知を見たら、なんとなく分かりました。
https://devblogs.microsoft.com/cppblog/clangformat-support-in-visual-studio-2017-15-7-preview-1/

How to get started
If you already have a .clang-format or _clang-format file in your codebase, you will notice Visual Studio uses it for formatting immediately, as soon as you make an edit in your code that would trigger a formatting operation.

設定ファイル置いてね、って書いてあるやん・・・。

というわけで、.clang-format 作るのが次のステップになりそうです。
少なくとも、UseTab=Neverはマズい...orz

berryzplus · 2020-03-29T04:09:41Z

ん？「.clang-format を置く」ってことは、
基本的には「編集or保存したら自動で整形される」にならん？

.clang-format は、既に導入済みの .editor-config と似た感じに動くらしいので、
個人設定の影響を受けることなくフォーマットの統一を図ることができてしまうのでは・・・。

berryzplus · 2020-03-29T06:06:49Z

追加情報(vs2019)

C:\work\sakura-editor\sakura>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin\clang-format.exe" -version
clang-format version 9.0.0 (tags/RELEASE_900/final)

C:\work\sakura-editor\sakura>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin\clang-format.exe" -style=Microsoft -dump-config
---
Language:        Cpp
# BasedOnStyle:  Microsoft
AccessModifierOffset: -2
...(省略)
Standard:        Cpp11
StatementMacros:
  - Q_UNUSED
  - QT_REQUIRE_VERSION
TabWidth:        4
UseTab:          Never

出力全文

C:\work\sakura-editor\sakura>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin\clang-format.exe" -version clang-format version 9.0.0 (tags/RELEASE_900/final) C:\work\sakura-editor\sakura>"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\Llvm\bin\clang-format.exe" -style=Microsoft -dump-config --- Language: Cpp # BasedOnStyle: Microsoft AccessModifierOffset: -2 AlignAfterOpenBracket: Align AlignConsecutiveMacros: false AlignConsecutiveAssignments: false AlignConsecutiveDeclarations: false AlignEscapedNewlines: Right AlignOperands: true AlignTrailingComments: true AllowAllArgumentsOnNextLine: true AllowAllConstructorInitializersOnNextLine: true AllowAllParametersOfDeclarationOnNextLine: true AllowShortBlocksOnASingleLine: false AllowShortCaseLabelsOnASingleLine: false AllowShortFunctionsOnASingleLine: None AllowShortLambdasOnASingleLine: All AllowShortIfStatementsOnASingleLine: Never AllowShortLoopsOnASingleLine: false AlwaysBreakAfterDefinitionReturnType: None AlwaysBreakAfterReturnType: None AlwaysBreakBeforeMultilineStrings: false AlwaysBreakTemplateDeclarations: MultiLine BinPackArguments: true BinPackParameters: true BraceWrapping: AfterCaseLabel: false AfterClass: true AfterControlStatement: true AfterEnum: true AfterFunction: true AfterNamespace: true AfterObjCDeclaration: true AfterStruct: true AfterUnion: false AfterExternBlock: true BeforeCatch: true BeforeElse: true IndentBraces: false SplitEmptyFunction: true SplitEmptyRecord: true SplitEmptyNamespace: true BreakBeforeBinaryOperators: None BreakBeforeBraces: Custom BreakBeforeInheritanceComma: false BreakInheritanceList: BeforeColon BreakBeforeTernaryOperators: true BreakConstructorInitializersBeforeComma: false BreakConstructorInitializers: BeforeColon BreakAfterJavaFieldAnnotations: false BreakStringLiterals: true ColumnLimit: 120 CommentPragmas: '^ IWYU pragma:' CompactNamespaces: false ConstructorInitializerAllOnOneLineOrOnePerLine: false ConstructorInitializerIndentWidth: 4 ContinuationIndentWidth: 4 Cpp11BracedListStyle: true DerivePointerAlignment: false DisableFormat: false ExperimentalAutoDetectBinPacking: false FixNamespaceComments: true ForEachMacros: - foreach - Q_FOREACH - BOOST_FOREACH IncludeBlocks: Preserve IncludeCategories: - Regex: '^"(llvm|llvm-c|clang|clang-c)/' Priority: 2 - Regex: '^(<|"(gtest|gmock|isl|json)/)' Priority: 3 - Regex: '.*' Priority: 1 IncludeIsMainRegex: '(Test)?$' IndentCaseLabels: false IndentPPDirectives: None IndentWidth: 4 IndentWrappedFunctionNames: false JavaScriptQuotes: Leave JavaScriptWrapImports: true KeepEmptyLinesAtTheStartOfBlocks: true MacroBlockBegin: '' MacroBlockEnd: '' MaxEmptyLinesToKeep: 1 NamespaceIndentation: None ObjCBinPackProtocolList: Auto ObjCBlockIndentWidth: 2 ObjCSpaceAfterProperty: false ObjCSpaceBeforeProtocolList: true PenaltyBreakAssignment: 2 PenaltyBreakBeforeFirstCallParameter: 19 PenaltyBreakComment: 300 PenaltyBreakFirstLessLess: 120 PenaltyBreakString: 1000 PenaltyBreakTemplateDeclaration: 10 PenaltyExcessCharacter: 1000000 PenaltyReturnTypeOnItsOwnLine: 1000 PointerAlignment: Right ReflowComments: true SortIncludes: true SortUsingDeclarations: true SpaceAfterCStyleCast: false SpaceAfterLogicalNot: false SpaceAfterTemplateKeyword: true SpaceBeforeAssignmentOperators: true SpaceBeforeCpp11BracedList: false SpaceBeforeCtorInitializerColon: true SpaceBeforeInheritanceColon: true SpaceBeforeParens: ControlStatements SpaceBeforeRangeBasedForLoopColon: true SpaceInEmptyParentheses: false SpacesBeforeTrailingComments: 1 SpacesInAngles: false SpacesInContainerLiterals: true SpacesInCStyleCastParentheses: false SpacesInParentheses: false SpacesInSquareBrackets: false Standard: Cpp11 StatementMacros: - Q_UNUSED - QT_REQUIRE_VERSION TabWidth: 4 UseTab: Never ...

C:\work\sakura-editor\sakura>

-style=Microsoft に対応したのは CLang9 からなんですかね。（最新＝CLang11）
おそらくこれが、visual studioのデフォルト と認識される設定の実態と思われます。

m-tmatma · 2020-09-06T05:04:52Z

#1391 および #1392 を作成したので閉じます。

m-tmatma mentioned this pull request Jan 26, 2020

ソースコードのスタイルに関して sakura-editor/management-forum#29

Open

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from bd3fd40 to d32aacd Compare January 26, 2020 03:27

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from d32aacd to 8464b08 Compare January 26, 2020 06:01

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from 8464b08 to f529bc1 Compare January 26, 2020 10:11

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from f529bc1 to a7aa935 Compare January 26, 2020 10:40

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from a7aa935 to 21546e8 Compare January 31, 2020 21:10

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from 21546e8 to e9ce55e Compare January 31, 2020 23:48

m-tmatma added 3 commits February 2, 2020 08:33

(Debug用) 全構成をビルド

638ca12

(Debug用) アセンブリ出力のオプションでソースを出力しない

3eccb0a

ASM のコメント削除用のスクリプト

68b318a

m-tmatma force-pushed the feature/EditFormatDocument-compare-point2 branch from fb6239f to dc9a97b Compare February 1, 2020 23:36

m-tmatma mentioned this pull request Feb 2, 2020

[WIP] ソースコードの整形の実験 (PR1172 との比較用) #1179

Closed

m-tmatma mentioned this pull request Mar 20, 2020

assert を独立した 1 行で記載する #1217

Merged

berryzplus mentioned this pull request Mar 29, 2020

[WIP] .clang-format を試してみた #1220

Closed

m-tmatma marked this pull request as draft August 20, 2020 13:24

m-tmatma closed this Sep 6, 2020

[WIP] ソースコードの整形の実験 #1172

[WIP] ソースコードの整形の実験 #1172

Conversation

m-tmatma commented Jan 26, 2020 • edited

PR の目的

カテゴリ

PR の背景

PR のメリット

PR のデメリット (トレードオフとかあれば)

注意

ビルド

PR の影響範囲

関連チケット

参考資料

AppVeyorBot commented Jan 26, 2020

beru commented Jan 26, 2020

AppVeyorBot commented Jan 26, 2020

berryzplus commented Jan 26, 2020

AppVeyorBot commented Jan 26, 2020

m-tmatma commented Jan 26, 2020 • edited

AppVeyorBot commented Jan 26, 2020

beru commented Jan 26, 2020

berryzplus commented Jan 27, 2020

m-tmatma commented Jan 27, 2020

m-tmatma commented Jan 27, 2020

m-tmatma commented Jan 27, 2020

berryzplus commented Jan 27, 2020

berryzplus commented Jan 27, 2020

beru commented Jan 27, 2020 • edited

berryzplus commented Jan 30, 2020

AppVeyorBot commented Jan 31, 2020

AppVeyorBot commented Feb 1, 2020

AppVeyorBot commented Feb 1, 2020

berryzplus commented Feb 2, 2020

AppVeyorBot commented Feb 2, 2020

berryzplus commented Feb 2, 2020

m-tmatma commented Feb 2, 2020

berryzplus commented Feb 2, 2020

m-tmatma commented Feb 2, 2020

berryzplus commented Feb 2, 2020

berryzplus commented Feb 2, 2020

m-tmatma commented Feb 2, 2020

m-tmatma commented Feb 2, 2020

m-tmatma commented Feb 2, 2020

berryzplus commented Feb 2, 2020

berryzplus commented Feb 7, 2020

m-tmatma commented Feb 7, 2020

beru commented Feb 8, 2020

beru commented Feb 8, 2020 • edited

berryzplus commented Feb 8, 2020

berryzplus commented Feb 15, 2020

m-tmatma commented Feb 15, 2020

berryzplus commented Mar 29, 2020 • edited

berryzplus commented Mar 29, 2020

berryzplus commented Mar 29, 2020 • edited

m-tmatma commented Sep 6, 2020

m-tmatma commented Jan 26, 2020 •

edited

m-tmatma commented Jan 26, 2020 •

edited

beru commented Jan 27, 2020 •

edited

beru commented Feb 8, 2020 •

edited

berryzplus commented Mar 29, 2020 •

edited

berryzplus commented Mar 29, 2020 •

edited