suin

あったら便利そうですね！

「実践でこんなときにジェネリックス使うとこんな便利だよ」「わー、すごい」みたいなのがあるといいかもしれない

基準3の5文字ケースバイケースの場合は、Wikipedia、MDN、Deep Dive、Twitterアンケートのどれかを使って客観的に判断するようにしたら、よりシステマティックに決められるようになるだろうと考えました。

技術用語が一般用語かの観点も関わってくる。「エディター」は「エディタ」でも違和感がないが、「カレンダー」は「カレンダ」になると違和感がある。

この基準は「表記警察」を促すためのものではなく、表記ゆれを吸収したいとなったときに、自律的/システマティックに考えられるガイドとして機能させたい。表記ゆれそのものは文章の価値を変えず、読者も気が付かないことが多いので、警察化すると執筆者のストレスになったりとデメリットのほうが大きいため。

@kotsgcp ご回答が遅くってすみません。 まず、この部分は、 ```ts const sample = { 1: "pork",　// キーにブラケットなし [Symbol("thick")]: "thin",　// キーにブラケットあり }; ``` TypeScriptではなく、JavaScriptの文法規則に従う部分だとご理解ください。 質問を言い換えると次のように整理だきるかと思います。 ## JavaScriptの[オブジェクトリテラル]のキーにシンボルの値を使う場合、なぜブランケットで囲むのか？ [オブジェクトリテラル]: https://typescriptbook.jp/reference/values-types-variables/object/object-literal JavaScriptのオブジェクトリテラルでは、キーを動的に指定する場合、ブランケットで囲む必要があります。 たとえば、`"name"`という値が`key`という変数に代入されていたとき、 ```js const key =...

@shota-nukumizu 素敵な提案ありがとうございます。これひとつひとつissueにしてもらえますか？😌

shotaさんが調査してまとめてくれたもの: https://github.com/shota-nukumizu/development-tips/blob/main/typescript/book-ts/semicoron.md

@shota-nukumizu ありがとうございます。コーディング規約といっても様々なトピックがあると思います。 一応、[ESLintでTypeScriptのコーディング規約チェックを自動化しよう](https://typescriptbook.jp/tutorials/eslint#typescript%E3%81%AE%E6%9B%B8%E3%81%8D%E6%96%B9%E3%81%AF%E3%81%95%E3%81%BE%E3%81%96%E3%81%BE)に、コーディング規約に触れるところはあります。 具体的に、コーディング規約について、どんなことを知りたいでしょうか？😌 執筆にあたっては、コーディング規約についての具体的な疑問点を列挙していただいたほうが、対応しやすいと思います！

shotaさんに聞いたらこういうGood・Bad集がほしいとのこと