敬体(ですます調)と常体(である調)の混在をチェックするtextlintルール。
本文、見出し、箇条書きをそれぞれ独立してチェックし、その中で表記が混在していないかを見つけます。 (本文と見出しの間で表記が混在していても問題ないという意味です)
- 本文(Markdownなら通常の文章部分)
- 見出し(Markdownなら
#) - 箇条書き(Markdownなら
* itemや- item)
npm install textlint-rule-no-mix-dearu-desumasu
Via .textlintrc(Recommended)
{
"rules": {
"no-mix-dearu-desumasu": true
}
}Via CLI
textlint --rule no-mix-dearu-desumasu README.md
それぞれの項目ごとに優先する表記をオプションで設定できます。
- 本文(Body)
- 見出し(Header)
- 箇条書き(List)
デフォルトは ""(空文字)で、多く使われている表記を自動的に優先します。 優先したい表記を "である" または "ですます" で指定します。
{
"rules": {
"no-mix-dearu-desumasu": {
"preferInHeader": "", // "である" or "ですます"
"preferInBody": "ですます",// "である" or "ですます"
"preferInList": "である", // "である" or "ですます"
// 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
"strict": false
}
}
}この設定は、次のような意味となります。
- 見出しは自動的に判定(混在のみのチェック)
- 本文は"ですます"を優先
- 箇条書きは"である"を優先
strict- default:
false - 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
- default:
たとえば、strict:false(デフォルト)では次のような "であったが" という接続的な"である"は無視されます。
次の例では "であったが" は無視されているため、"です"のみが使われているという判定になります。
OK: 昨日はいい天気であったが、今日は雨です。
strict:falseでは次のような文末が "である" や "です" といったものだけを検出します。
そのため、次の文章は "です" と "である" が混在しているのでエラーとなります。
NG: 今日はいい天気である。明日も晴れです。
strict:trueとしていた場合では、以下の文章は "ですが" と "である" が混在している場合もエラーとなります。
(ですがは接続的、であるは文末)
NG: 今日はいい天気ですが、明日は悪天候である。
詳しくはexample/を動かして試してみてください。
$ textlint --rule no-mix-dearu-desumasu README.md -f pretty-error
no-mix-dearu-desumasu: 本文: "である"調 と "ですます"調 が混在
=> "である" がである調
Total:
である : 3
ですます: 3
textlint-rule-no-mix-dearu-desumasu/example/README.md:7:7
v
6.
7. 結果として「である」調と「ですます」調の使われる数をだしたものである。
8.
^
✖ 1 problem (1 error, 0 warnings)
A. 本文、見出し、箇条書き をそれぞれ別々にカウントします。
箇条書き(- リスト)同士の間で混在している場合はエラーとなりますが、
本文と箇条書きでの混在は問題ありません。
- 本文(Markdownなら通常の文章部分)
- 見出し(Markdownなら
#) - 箇条書き(Markdownなら
* itemや- item)
それぞれ、別々に扱っているため、これらの間での混在は問題ありません。
A. strict: trueは誤検知の可能性があるので、デフォルトの判定を緩くするためです。
textlintでは多くのルールはfalse positiveにならないように、デフォルトを緩く設定しています。 厳しく(接続的な"である"なども)検出したい場合は、{ "strict": true } オプションが利用できます。
A. オプションに"strict": trueを追加してください。
2.0
{
"rules": {
"no-mix-dearu-desumasu": {
"preferInHeader": "", // "である" or "ですます"
"preferInBody": "ですます",// "である" or "ですます"
"preferInList": "である" // "である" or "ですます"
}
}
}3.0
{
"rules": {
"no-mix-dearu-desumasu": {
"preferInHeader": "", // "である" or "ですます"
"preferInBody": "ですます",// "である" or "ですます"
"preferInList": "である", // "である" or "ですます"
// 文末以外でも、敬体(ですます調)と常体(である調)を厳しくチェックするかどうか
"strict": true
}
}
}関連Issue
- 接続的な "である" を無視するオプション · Issue #5 · textlint-ja/analyze-desumasu-dearu
- Proposal: デフォルトでは文末の"です/である"のみ検出するように · Issue #13 · textlint-ja/textlint-rule-no-mix-dearu-desumasu
A. 以下のIssueに書き込んで下さい。
- JTF日本語標準スタイルガイド
- 1.1.1 - 1.1.3で同様のルールが扱われています。
- textlint-ja/textlint-rule-preset-JTF-style: JTF日本語標準スタイルガイド for textlint.も参照してください。
このルールを使ってリファクタリングしてみた例です。
-先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけであるため、
+先ほどのgulpタスクの例では、既にモジュール化された処理を`pipe`で繋げただけで、
それぞれの処理がどのように実装されているかはよく分かりませんでした。-BufferはStringと相互変換が可能であるため、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。
+BufferはStringと相互変換が可能なので、多くのgulpプラグインと呼ばれるものは、`gulpPrefixer`と`prefixBuffer`にあたる部分だけを実装しています。-gulpではプラグインが持つ機能は1つ(単機能)であること推奨しています。
+gulpではプラグインが持つ機能は1つ(単機能)とすることを推奨しています。-`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`であるため実際にprototype拡張していることがわかります。
+`jQuery.fn`の実装を見てみると、実態は`jQuery.prototype`なので、prototype拡張していることがわかります。-単純なprototype拡張であると言えるので、利点はJavaScriptのprototypeと同様です。
+単純なprototype拡張なので、利点はJavaScriptのprototypeと同様です。-まだNode.jsで使われているCommonJSやES6 Modulesといったものがなかった時代に作られた仕組みであるため、
+まだNode.jsで使われているCommonJSやES6 Modulesなどがなかった時代に作られた仕組みなので、他にいい代替表現など書き方の指摘を募集しています。
敬体(ですます調)、常体(である調)の判定は以下のライブラリを利用しています。
npm test
- Fork it!
- Create your feature branch:
git checkout -b my-new-feature - Commit your changes:
git commit -am 'Add some feature' - Push to the branch:
git push origin my-new-feature - Submit a pull request :D
MIT
Thanks for RedPen.