Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
コードを整えよう
Search
akatsuki1910
June 27, 2023
0
8
コードを整えよう
akatsuki1910
June 27, 2023
Tweet
Share
More Decks by akatsuki1910
See All by akatsuki1910
後輩に伝えたいこと
akatsuki1910
0
2
難解(かもしれない)言語
akatsuki1910
1
27
Reactのチュートリアルをしよう3
akatsuki1910
0
13
クソドメインを取ろう
akatsuki1910
0
26
Reactのチュートリアルをしよう2
akatsuki1910
0
13
HTMLとCSSとコンポーネント
akatsuki1910
0
17
Reactのチュートリアルをしよう
akatsuki1910
0
15
そのコレクション合ってる?
akatsuki1910
0
17
第3回 TypeScriptを使おう
akatsuki1910
0
10
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
65
11k
Fireside Chat
paigeccino
32
3k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Scaling GitHub
holman
458
140k
Designing Experiences People Love
moore
138
23k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
27
1.9k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
800
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
131
33k
Visualization
eitanlees
144
15k
Transcript
コードを整えよう らり
コードを整えるとは? 人が書いたコードって、他の人が見たら見にくい ↓ なので、コードの書き方やコーディングルールをある程度統一させよう
どうやって整える? • ESlint ◦ コードを実行する前に明らかなバグを見つけたり、括弧やスペースの使い方などのスタイルを統一 • Stylelint ◦ cssのためのlinter •
Prettier ◦ コードのフォーマットを統一する
linterとformatterの違いって何? • linterはコードの品質を守るためのもの • formatterはコードの整形を行うためのもの なので、lintとformatは別々に行う必要がある 一般的にはlinterを通して品質を担保したあと、整形を行う https://prettier.io/docs/en/integrating-with-linters.html
ESlintってなあに? コードの一貫性を高め、バグを回避することを目的としたもの 過去に似たようなものとして、JSLintやJSHintがあったが、ここでは省略
ESlintの利点 • 変な書き方によるバグも回避される • ルールが決まるため、共同開発でそれぞれの個性が出にくいため読みやすい • 上記理由により、改修も簡単 • 自分でルールを追加できるため、きまりが作りやすい •
typescriptとの連携も出来るため、型による間違いも見つけれる • ドキュメントがめちゃめちゃ丁寧
ESlintの欠点 • JSのバージョンが上がったらルールを見直す必要がある ◦ 年に1回程度なので、そこまで気にしなくていい • ルールの数が尋常じゃないぐらい多いからいちいち見てられない ◦ とりあえず”eslint:recommended”を入れておけば問題ない ◦
最近はフレームワークの構築時に一緒に入っている • ルールが厳しいと、よしなになコードが書けない ◦ 一般的なルールは、大体その書き方は良いとされていないものを防ぐ目的なので、それでひっかか る方が悪い ◦ recommendedしかいれてないのにひっかかるのであればなおさら
ESlintをどうやって入れる? 公式の入門ページがあるので、そちらをご覧ください https://eslint.org/docs/latest/use/getting-started
ESlintでどんなことができるの?
ESlintでどんなことができるの? これは、スター・ウォーズのキャラクター、ヨーダの 話し方と同じように、「赤が色と等しい場合」と解釈 されるため、ヨーダ条件と呼ばれます。オペランド を配置する他の方法と比較してください。 これが書かれているものだけ、 --fixで修正され る
ESlintでどんなことができるの? if(color == “red”)だと、color = “red”って書いてもエラーがでない でも、if(”red” == color)だと、”red” =
colorって書いた時にエラーがでるよね だから普段からそういう書き方にしようぜ(意訳) ちなみに、no-cond-assignっていうルールでカッコ内の代入を止めれます
他には? • require-await ◦ 非同期な関数を呼び出す際、 awaitをちゃんと付けてないと怒られる • eqeqeq ◦ ==を許さない(===にする)
• no-console ◦ console.xxxを許さない • @typescript-eslint/no-explicit-any ◦ anyを許さない • import/order ◦ importの順番をソートしてくれる (アルファベット順とか ) コード以外にもファイル名の付け方から 1ファイル当たりの行数も指定できる
Stylelintってなあに? linterのcss版 利点と欠点は大体ESlintと同じ 最近ではフレームワークの標準インストールで入ってくる
Stylelintのデカい欠点 css-in-jsに対応しなくなった 色んな書き方があるため、追いきれないことが原因らしい We've also deprecated the postcss-css-in-js custom syntax.
It was not possible to maintain a monolithic custom syntax that attempted to support every CSS-in-JS library and syntax, as there are so many of them and each with variations in syntax. https://stylelint.io/migration-guide/to-15/
Stylelintをどうやって入れる? 公式の入門ページがあるので、そちらをご覧ください https://stylelint.io/user-guide/get-started
Stylelintでどんなことができるの?
Stylelintでどんなことができるの?
Stylelintでどんなことができるの?
他には? • block-no-empty ◦ セレクタ指定内にプロパティがない場合にエラー • color-no-invalid-hex ◦ 16進数があっているかチェック •
declaration-block-no-duplicate-properties ◦ プロパティが重複している場合エラー • no-duplicate-at-import-rules ◦ importで読み込むファイルが同じだとエラー • unit-disallowed-list ◦ 許可しない単位を指定 ◦ svhとかまだ使えないので、何も知らずに使うことを予め止めれる CSSでやりがちなミスは基本的に全部これで解決できる
linterの注意点 linterはコードの品質を守るための手段の1つであり、コードを実行するまえに色んな ルールを元に、コードのチェックを行うものである なので、修正を行うものではない なんでもかんでも--fixをつければ直る訳ではない linterでエラーが出て、--fixを付ければ直せるものは直す 直らないものは手動で修正する必要がある
Prettierってなあに? コードの整形を行うためのもの Community Pluginsを入れればJS以外にも整形を行うことが出来る
Prettierの利点 • コードフォーマットを統一できる • フォーマットが決まっているので、人に書き方の差分が生まれたりしない
Prettierの欠点 • push前にPrettierがかかっているかが分からない ◦ huskyで修正は出来るが、 pushした人が書いていない書き方になるので、ちょっと違和感がある • ESlintと干渉する設定がいくつかある ◦ 最近はほぼ気にしなくてよくなった
Prettierをどうやって入れる? 公式の入門ページがあるので、そちらをご覧ください https://prettier.io/docs/en/install.html
Prettierでどんなことができるの? 公式の設定一覧ページがあるので、そちらをご覧ください https://prettier.io/docs/en/options.html
Prettierでどんなことができるの? • セミコロンを付けるか否か • シングルクオーテーションとダブルクオーテーション • インデントをタブかスペースか • インデントの数 •
折り返しの文字数
Prettierでどんなことができるの? • 行末の改行コード ◦ 最近ではあまり気にされないが、未だに根付いている問題 ◦ 開発環境やエディタ、 gitの設定によりいくらでも変更される 行末の改行コードを開発環境側で統一するのはとても大変なため、そもそものコード側 で統一した方が楽
他には? • @prettier/plugin-pug ◦ pugの整形を行う ◦ divを使わない等 なんかコードの見た目整えたいな~は大体なんとかなる
linterやformatterを入れていない人へ 自分が必ずミスのない、読みやすいコードが書けるという自信があるのであれば入れて いなくても問題ない(必ず強制されるものではないため) ただ、人は完璧ではないため、機械的に修正や整形、品質を担保してくれるなら入れ得 でしかなため、初期設定のままでも入れておいた方がいい 入れてくれ~たのむ~
他にすること • スタイルガイドを読む ◦ 色んな所が出している ◦ スタイルガイドは、ある思想に基づいて作られているため、破綻しにくい ◦ 書いてあることは、ほぼ linterとformatterで設定できる
• 他のOSSのコードを覗く ◦ 大体ESlintが入っているため、どんな設定がよく使われているかわかる
スタイルガイド googleが出しているスタイルガイド https://google.github.io/styleguide/jsguide.html MDNが出しているガイドライン https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Writing_style_g uide/Code_style_guide/JavaScript
スタイルガイド Airbnbが出しているスタイルガイド https://mitsuruog.github.io/javascript-style-guide/ node.jsが出しているスタイルガイド http://popkirby.github.io/contents/nodeguide/style.html
課題 • これは絶対入れておくべきだろうという設定を探してくる • 実際に入れた時につまづいた知見