とりあえず動けばいい、の精神でコードを書ける個人開発とは違い、仕事やオープンソースプロジェクトにおけるコーディングでは、「他人が読むコード」を意識して書く必要があります。 他人が読むのですから、もちろんわかりやすいコードでなくてはなりません。でも、「わかりやすい」とは何でしょう。どうしたら実現できるのでしょう。 この記事では、他人が読む可能性があるコードを書くときに気をつけていた方がいい事項について、いくつか紹介します。 まえがき 私が社会人になって数ヶ月が経ちました。会社では自分でコードを書くのはもちろん、他人の書いたコードをいじるという、今まであまり経験していない作業をすることもあります。 そしてその中で使われている言語にはJavaScriptも含まれます。JavaScriptは平易な言語であり、クライアントサイドでもサーバサイドでも採用できるので、様々な場面で使用されています。 さす

自己紹介 日野澤歓也 (ひのさわよしや) github / qiita は @kt3k 今日はリントの話です JavaScript のリントツールと言えば JSLint / JSHint / ESLint などがありますが 今日紹介するツール Standard という名前のリントツール コマンド名が standard 内部的には ESLint を使っている ESLint おすすめルール集的なものとも言える 特徴1 (リントルール) セミコロンなし 2スペースインデント リントルールは基本的にコンフィグ不可能❗️ プラグイン単位での追加は OK e.g. eslint-plugin-flow eslint-plugin-vue など 特徴2 (コマンド) ファイルの自動検出 standard コマンドを打つとリントすべきファイルをほぼ勝手に探してくれる (↑ 具体的にはこの辺を ignore

はじめに GoogleさんがShellスタイルガイドを共有していたので、いくつか気になった点をピックアップしました。 自分のShellスタイルはかなり我流なので、自省の意味も込めてコメントも併記します。 Googleスタイルガイドの元ネタ （Python/C++/Java/Rとかだけでなくdocumentガイドなど色々あります） https://github.com/google/styleguide Shellスタイルガイド （今回はこちら） http://google.github.io/styleguide/shell.xml 本当は人間がチェックするのではなくcpplintのためXML定義なのかもですが、気にしない気にしない。 （見たところcpplintはc++だけだと思ってます） commitフックでshell系のlint走らせろっていうのが今風なのかもしれませんが、キニシナイキ

はじめに http://qiita.com/raccy/items/bf590d3c10c3f1a2846b を見ていたら、はてブに「理由がないから」ということがよく挙がっていたので、理由をつけてあげたら有益な内容になるかな？と思い、拙いながらも補足を試みようと思います。 【2017 1/3 15:10 追記】 元記事の前提はgulpなどを使ってminifyなども行なえる（もしくは行う目標がある）前提の様子なので、中級者以上がターゲットかなーと思いました。そのつもりで読むととてもいい記事だと思っています。 「最新のJSの書き方を覚えてあとは変換機能に任せればレガシーなJSのキツイところに向き合わなくて済みますよ？」みたいなイメージだとわかりやすいかな？ ==、!= 理由 暗黙の型変換が発生して、別の型の比較が真で扱われてしまう場合があるため。 解説 サンプルコードにも出ていますが言葉足らず

この1ページの質問表は、チームで効果的なフロントエンドガイドラインをつくり一貫性とまとまりのあるコードを共に書けるようにする為の補助ツールである。 HTML HTMLの方針 HTMLを書く上でのチームとしての基本方針は何か？ (例： セマンティックなHTML5マークアップを書く, アクセシビリティ, 等。 これらの 資料 を 参照) HTML Tools HTML プリプロセッサーを使用しているか？ (例： HAML, Jade, など) テンプレートエンジンを使用しているか？ (Mustache, Handlebars, など) バックエンドの構成はフロントエンドに影響するか？ (例： WordPress はマークアップのクラスにwp-paginateを加える) もしあれば, そうしたルールをについてさらに説明できるか？ HTML 記述のスタイル スペースかタブか？ コメントルールはどう

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

この翻訳について Airbnb React/JSX Style Guideの和訳です。 間違っていたり分かりにくい箇所があれば、ご指摘いただけると幸いです。 Airbnb React/JSX スタイルガイド このスタイルガイドは現在一般的に使用されている標準に基いていますが、場合によってはいくつかの慣例（async/awaitやstatic class fields）が含まれていたり禁止されていたりします。現在、このガイドにはステージ3より前のものは含まれておらず非推奨です。 目次 基本的なルール クラス vs React.createClass vs ステートレス ミックスイン 命名規則 宣言 アラインメント 引用符 空白 引数 参照 括弧 タグ メソッド 順序 isMounted 基本的なルール Reactコンポーネントは1ファイルに1つだけにしてください。 ただし、1ファイルに複数の

ESLintのようなconfigでPostCSSプラグインとして動くstylelint。 唐揚げチャーハンのような「美味いものと美味いもの組み合わせたら絶対おいしいじゃん！」みたいなプロダクトが実際とても良かったので色々利点を記載。 導入についての手順などはすでに記事があったので、そちらへリンクしたい CSSのLintをstylelintにする ESLintっぽくて良い所 javascriptのLinterとしてスタンダードになってきたESLintに非常に良く似て作られているので、一度そちらを導入していればstylelintの導入はおそらくすんなり出来る。 また、ESLintの持っていた良い所をそのまま持ってきたような良さがある。 config周りがESLintにすごく近いので覚えることが少なめ 肝となるstylelintのconfigは、だいたいこんな感じで、ESLintにかなり近く作ら

(訳注：2015/10/31、いただいた翻訳フィードバックを元に記事を修正いたしました。) (訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を再修正いたしました。) 訳：　プロジェクトが長引くほど、私のGitのコミットメッセージは情報が薄くなっていく。 イントロダクション | 7つのルール | ヒント イントロダクション：なぜ良いコミットメッセージを書くことが重要か Gitのリボジトリのログをランダムに閲覧すると、ひどいコミットメッセージを目にすることがあります。例として、私が昔書いたSpringにコミットした これらのgem を見てみましょう。 $ git log --oneline -5 --author cbeams --before "Fri Mar 26 2009" e5f4b49 Re-adding ConfigurationPostProcessorTest

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

※こちらは2015/9/25日の古い記事です。（ESLint v1.5.1 released 22 September 2015） 現時点(2019/9/25)ではESLint v6.4.0です。 最新のドキュメントを読みに行くことを強くオススメします。 (近いうち新たに加筆してこちらに更新する予定です) こんにちは。森田と申します。芸人をしています。今回は ESLintのエラールール。日本語「ざっくりしたの」ないのか、と思ってぐぐしても なさそうなので書きました。 ※使い方はこちら ※ここに載っているのが「ESlintのルール全て」ではありません。 他にこういうのあります。 ESLintのエラールール。日本語ざっくり解説[可能性あるエラー編] ESLintのエラールール。日本語ざっくり解説[ベストプラクティス編] ESLintのエラールール。日本語ざっくり解説[ES6編] ※いろいろなオ

1. send, deliver, dispatch, announce, distribute, route send : (命令・依頼などによって)行かせる、送る deliver : 配達する; 引き渡す，明け渡す; 手渡す dispatch : 〈軍隊・特使などを〉〔…へ〕急派する，特派する announce : 人に〕〈…を〉知らせる，発表する distribute : 〈ものを〉〔…に〕分配する route : 貨物などを〉〔…のルートで〕発送する 2. find, search, extract, locate, recover find : (努力して)見つけ出す search : (何かを見つけようとして注意深くまたは徹底的に)捜す extract : 〈エキスなどを〉〔…から〕抽出する locate : 〈…の〉位置を突き止める recover : 〔廃物などから〕〈有用

広告事業部の鈴木達矢です。コーディングをしてると変数やメソッド名の付け方に悩むことって多々ありますよね。逆にコードを読んでいると単語の選択がこれでいいのかなという時や、動詞の活用形が間違っていてよく意味がわからない、時に潔く日本語の変数名になっていることも見かけます。でもプログラミング言語の単語が英語をベースにしていますし、Railsを使っている場合は日本語が規約（Convention）に合わなかったりします(複数形が無いなど)。それから動詞の活用形が違っていると主語（動作の主体）が変わってしまい、意味が変わってしまいます。その結果コードの可読性が落ち混乱を招きやすくなります。 いくつかの基本的な法則だけおさえておけばコーディング中に可読性の高い単語の選択ができるようになります。今回はそれを目的に、英語の扱いに都度時間を費やしてしまうような方に向けていくつかの法則をご紹介します。*1 変数

本文書は、プログラミング言語向けのスタイルガイドに向けたスタイルガイドである。 本文書へのフィードバックはQiita上のコメントにて受け付ける。 構造 対象を明確にする そのスタイルガイドがどのような状況のどのような対象に向けたスタイルガイドであるか規定すること。 状況や対象は広すぎてはならない。 理由: 対象はスタイルガイド記述者には自明かもしれないが、似て非なる言語に誤用されたり、特定分野のアプリケーション向けスタイルガイドが他分野のアプリケーションを理不尽に拘束したりすることがある。これを防ぐべきである。 良い例: 「本文書はRuby on Railsアプリケーション向けのスタイルガイドである」 「本スタイルガイドはX社におけるRubyプロジェクトに適用すべきスタイルを規定する」 悪い例: (何も書かない) 「本文書はX社におけるすべての開発に適用される ... 述語メソッドや述語関

大規模なプロジェクト、長期に渡るプロジェクト、複数のメンバーが関わるプロジェクト、そして明日の自分も一年後の自分が見ても分かる、メンテナンス性に優れ、一貫性のあるCSSを書くのに役立つガイドラインやスタイルガイドを紹介します。

stylefmt is a tool that automatically formats CSS according to stylelint rules. stylefmt'd code is: easier to write : never worry about minor formatting concerns while hacking away. easier to read : when all code looks the same you need not mentally convert others' formatting style into something you can understand. easier to maintain : mechanical changes to the source don't cause unrelated change