489
325

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

株式会社ACCESSAdvent Calendar 2018

Day 7

VSCode に Code Spell Checker を導入して typo と戦う

Last updated at Posted at 2018-12-07

【2024/12/10 追記】そして6年後どうなった?という記事も書いています。


この記事は ACCESS Advent Calendar 2018、7日目の記事です。

こんばんは! @diescake です。

突然ですが、皆さん! typo してますか!?

今年も一度はコードレビューで typo を指摘されたのではないでしょうか?
また、苦虫を噛み潰したような苦悶の表情で typo を指摘したのではないでしょうか?
自分自身もそれなりの typo をこの世に産み落とし、多くの人を不幸のどん底に陥れました。

レビューの網を掻い潜った typo 達一行は master の奥深くに潜み、
数多の親・家族・友人を浄化したエンジニアに対して復讐の炎を滾らせ、虎視眈々と production へデプロイされるチャンスを狙っているのであった…

typo の定義

先に断っておくと、ここでいう typo とは、クラス・関数・変数名、文言などのスペルミスを指していて、
多くの場合、動作には影響がなく、コンパイルや Linter(ESLint/TSLint など) で検出できないタイプミスを意図しています。
(勿論、runtime に評価される string で typo した場合はバグになると思いますが、動作確認時に気づくでしょう。いや頼む、気づいてくれ。)

非コンパイル言語であれば Linter の導入は当然であって、
それでも紛れ込んでしまう typo をどうしたものか、という話ですね。

また、対象言語は英語のみで、日本語は対象外としています。

なぜ typo はよくないか?

スペルミスは害がある。
普通にバグの原因になるし、バグはなくともコードを読むときに脳に負荷をかける。

そして一部の言語(Ruby, JavaScriptあたり)は、正確に治すのは難しく、スペルミスを直したつもりが直しきれずにバグになってしまうこともある
(以前にAndroid StudioでJavaのリファクタリングしたときはかなり正確に、しかもコメント内まで修正が入っていた。言語によっては安全に直せるケースもある)。

そういう要素はプログラマのやる気を削ぎ、プロジェクト離脱や退職に繋がる。

スペルミスの多いコードを持つプロジェクトにありがちなこと」より引用

去年のへーしゃアドカレの記事で、どす黒い想いを綺麗に言語化されていましたので引用しましたが、まさにその通りだと感じます。
typo はワールドマップの毒沼のようなもので、コード上で見かける度にメンタルにダメージを追うのが辛いところです。

Code Spell Checker

これは何?

よし!typo はしないぞ!今日から俺は!と誓ったところで、所詮人間には限界があり信用出来ないので、
エディターに、適当なスペルチェッカー入れてみるか、と試してみたところ、それなりに良い感じに使えて目的が達成できたのでご紹介します。

  • Code Spell Checker
    https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker

  • VSCode の extension でリアルタイムにスペルチェックを行ってくれます。
    今日(2018/12/7)時点で 1,384,481 installs と圧倒的で、評価も高く、VSCode ではデファクトスタンダードです。(紹介する意味

  • ソースコード専用のスペルチェッカー
    ソースコードに対してスペルチェックを行うことを前提として作られているため、camelCase, snake_case, kebab-case などなど、
    各種複合語の記述方法を判断し、単語単位に分解して評価してくれます。
    「redApple? よっしゃ typo やな!!」みたいな、ムノーなことにはならないということですね。

  • 拡張子から判断した言語に対する予約語もサポート
    TypeScript, JavaScript 類しか検証していませんが、ファイルの拡張子から言語判定して、
    対象内外のスイッチや、追加データ?のインストールなどできるようです。(未検証)

導入方法

  • 公式サイトを確認して貰えればと思いますが、特に変わったことはなく、
    いつものように VSCode の Extension メニューから Code Spell Checker と検索して、インストールすれば完了です。
  • 大量に同じアイコンが並んでビビりますが、英語以外の言語がプラグインとして提供されているようですね。

使ってみる

公式サイトの画像を直リン。 Lint 類と同様で typo と思しき word にグリーンの波線(デフォルト)で指摘されます。

指摘結果は Lint と同様に「問題」 のウィンドウに表示されます。
通常この「問題」ウィンドウは常にチェックしていると思いますので見落としにくいです。

キーワードのホワイトリストへの登録

スペルチェッカーはどうしても false positive な運用となるため、
特有の固有名詞や、辞書に記載されていない単語など、誤検知が発生するため、都度ホワイトリストへ登録が必要となります。

この登録自体面倒くさいものではありますが、
Code Spell Checker では、キー操作のみで比較的単語を登録しやすく、共有する仕組みもあるため便利です。

具体的には下記のような手順になります。

  1. 誤検知のワードを発見!!
  2. カーソルをキーワードの上へ移動
  3. shift + command + p でコマンドパレットを開く
  4. Add Word to Global Dictionary を選択して
  5. 既にキーワードがデフォルト値として入力されているので問題なければ

手順として書くと長く見えますが、実際にはコマンドパレットのコマンドは記憶されるので、
キーワードの上に移動したら shift + cmd + p で終わりです。

ezgif-4-767c57d32451.gif

上記 gif では frameborderdevtoolchange をホワイトリストに追加し、hiden を修正しています。

スペルチェッカーを利用する以上、キーワードをホワイトリストへ登録する作業は避けられませんが、
マウス操作や、コマンド入力は基本的に不要なので、少し慣れれば億劫にならず継続的にメンテできると思います。

また、Add Word to Global Dictionary で登録したキーワードは setting.json に書き込まれますので、
Setting Sync を利用している場合は含めて backup, sync されます。

Add Word to Workspace Dictionary で登録したキーワードは、.vscode/setting.json に保存されるため、
リポジトリで管理、共有することが可能で、チーム開発で便利に使えると思います。

推奨設定

なぜか一部の日本語を typo と誤検知しますので、ignore list に追加しましょう。

setting.json
// "cSpell.language": "en",
"cSpell.ignoreRegExpList": ["[0-9A-Za-zぁ-んァ-ヶ亜-熙纊-黑]+"],

注意点

あまりないとは思いますが、関数、変数名全てに独自の命名規則を採用していたり、case や delimiter で単語をわけない場合、
ホワイトリストへの登録がとてつもなく面倒なので、あまり向かないかもしれません。

それと、Unix 的な慣習で、英単語を積極的に省略していくスタイルや、ハンガリアン記法に対しても、あまり向いていないかもしれません。(未検証)

Examples
const myDogName = 'pomeranian'; // OK
const my_dog_name = 'pomeranian'; // OK
const MyDog_name = 'pomeranian'; // OK

const mydogname = 'pomeranian'; // Unknown word "mydogname"
const mydog_name = 'pomeranian'; // Unknown word "mydog"

JavaScript の event 名は慣習上 case や delimiter で分けないので、
独自のイベントを実装した際はホワイトリストへ登録する必要があります。

examples
window.addEventListener('devtoolschange', (e) => { // Unknown word "devtoolschange"
  if (!e.detail.open) {
    return; // when close
  }

  clearBody();
  document.body.appendChild(createMeteorElement());
});

まとめ

というわけで、Code Spell Checker はいいぞ!、という紹介でした。

個人差はありますが、typo は誰でもやってしまうものだと思います。
しかし、こういったヒューマンエラーに対して、ヒューマン的解決方法を適用しても費用対効果は低いので、
ツールに頼って快適に是正していきたいところですね。

ちなみに、GitHub PR の Suggested change 機能はマジ便利ですね。
コードレビューで typo 指摘する際に打って付けだと思いますので、遭遇した際にはぜひ使ってみてください。

それでは、明日は @ikeyasu さんです。お楽しみに!

動作検証環境

  • MacBook Pro (15-inch, 2016)
    • macOS Mojave 10.14
  • Visual Studio Code 1.29.1
    • Vim 0.16.13
    • Code Spell Checker 1.6.10
  • JavaScript, TypeScript, JSON, YAML, CSS, altCSS 色々

参考

489
325
3

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
489
325

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?