他人に読んでもらうJavaScriptコードを書くために
とりあえず動けばいい、の精神でコードを書ける個人開発とは違い、仕事やオープンソースプロジェクトにおけるコーディングでは、「他人が読むコード」を意識して書く必要があります。 他人が読むのですから、もちろんわかりやすいコードでなくてはなりません。でも、「わかりやすい」とは何でしょう。どうしたら実現できるのでしょう。 この記事では、他人が読む可能性があるコードを書くときに気をつけていた方がいい事項について、いくつか紹介します。 まえがき 私が社会人になって数ヶ月が経ちました。会社では自分でコードを書くのはもちろん、他人の書いたコードをいじるという、今まであまり経験していない作業をすることもあります。 そしてその中で使われている言語にはJavaScriptも含まれます。JavaScriptは平易な言語であり、クライアントサイドでもサーバサイドでも採用できるので、様々な場面で使用されています。 さす
JS Standard Style - Qiita
自己紹介 日野澤歓也 (ひのさわよしや) 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
「JavaScript初級者のためのコーディングガイド」に補足を試みる - Qiita
はじめに http://qiita.com/raccy/items/bf590d3c10c3f1a2846b を見ていたら、はてブに「理由がないから」ということがよく挙がっていたので、理由をつけてあげたら有益な内容になるかな？と思い、拙いながらも補足を試みようと思います。 【2017 1/3 15:10 追記】 元記事の前提はgulpなどを使ってminifyなども行なえる（もしくは行う目標がある）前提の様子なので、中級者以上がターゲットかなーと思いました。そのつもりで読むととてもいい記事だと思っています。 「最新のJSの書き方を覚えてあとは変換機能に任せればレガシーなJSのキツイところに向き合わなくて済みますよ？」みたいなイメージだとわかりやすいかな？ ==、!= 理由 暗黙の型変換が発生して、別の型の比較が真で扱われてしまう場合があるため。 解説 サンプルコードにも出ていますが言葉足らず
ここがすごいぞ！ stylelint！ - Qiita
ESLintのようなconfigでPostCSSプラグインとして動くstylelint。 唐揚げチャーハンのような「美味いものと美味いもの組み合わせたら絶対おいしいじゃん！」みたいなプロダクトが実際とても良かったので色々利点を記載。 導入についての手順などはすでに記事があったので、そちらへリンクしたい CSSのLintをstylelintにする ESLintっぽくて良い所 javascriptのLinterとしてスタンダードになってきたESLintに非常に良く似て作られているので、一度そちらを導入していればstylelintの導入はおそらくすんなり出来る。 また、ESLintの持っていた良い所をそのまま持ってきたような良さがある。 config周りがESLintにすごく近いので覚えることが少なめ 肝となるstylelintのconfigは、だいたいこんな感じで、ESLintにかなり近く作ら
ESLintのエラールール。日本語ざっくり解説[スタイル編] - Qiita
※こちらは2015/9/25日の古い記事です。（ESLint v1.5.1 released 22 September 2015） 現時点(2019/9/25)ではESLint v6.4.0です。 最新のドキュメントを読みに行くことを強くオススメします。 (近いうち新たに加筆してこちらに更新する予定です) こんにちは。森田と申します。芸人をしています。今回は ESLintのエラールール。日本語「ざっくりしたの」ないのか、と思ってぐぐしても なさそうなので書きました。 ※使い方はこちら ※ここに載っているのが「ESlintのルール全て」ではありません。 他にこういうのあります。 ESLintのエラールール。日本語ざっくり解説[可能性あるエラー編] ESLintのエラールール。日本語ざっくり解説[ベストプラクティス編] ESLintのエラールール。日本語ざっくり解説[ES6編] ※いろいろなオ
![ESLintのエラールール。日本語ざっくり解説[スタイル編] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/4b4d6173780fcd40abce0e833d9416da9a17e5e7/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9RVNMaW50JUUzJTgxJUFFJUUzJTgyJUE4JUUzJTgzJUE5JUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgzJUJDJUUzJTgzJUFCJUUzJTgwJTgyJUU2JTk3JUE1JUU2JTlDJUFDJUU4JUFBJTlFJUUzJTgxJTk2JUUzJTgxJUEzJUUzJTgxJThGJUUzJTgyJThBJUU4JUE3JUEzJUU4JUFBJUFDJTVCJUUzJTgyJUI5JUUzJTgyJUJGJUUzJTgyJUE0JUUzJTgzJUFCJUU3JUI3JUE4JTVEJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0yOTFjOWEwNjJhM2FmNjE5NzkyZGExYjBhODNhYTQ2NQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBNLUlTTyZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTM2JnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnM9ZDdmYWEyZjViNWRmODU3ZDUzYmY5ZDRiNzQyMDA0MTE%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D12e0e7357ebe3cbb4d70da002fe0f99a)
Promiseに関するパターンや命名規則 - Qiita
やや自己流含む。 getXxx/fetchXxx getXxxは同期、fetchXxxはPromiseということにしている。とくに非同期の取得系はfetchということに決め打ってる。 GETリクエストであることを明示したいときにややこしいという問題はあるが、そのケースは少なく、JS内で同期/非同期を明示したいことの方が多い。 例: 非同期の副作用系はput/post/sync/send/uploadとかそのあたりを適当に使う。 Promise( (done, reject) => {..}) 恐らく仕様的に正しいワードは fulfill, reject なのだが、fulfillはタイプ数が妙に多いのと、llが多くタイポしやすく、またタイポが発見しづらいので、自分は慣習的にdoneを使っている。 追記: fulfillよりもresolveの方が仕様に沿ってるっぽいhttp://people.
JavaScriptのスタイルガイドまとめ(おすすめ4選) - Qiita
はじめに スタイルガイド自体は各々のルールでかなりの数が存在しますが、 下記のおすすめ4選を押さえておけば問題ないと思います。 おすすめ４選 Google JavaScript Style Guide Googleによる、最も代表的なスタイルガイドです。 時間のない方は、これだけにでも目を通しておく事をおすすめします。 JavaScriptのBad Partsについても述べられています。 英語：https://google.github.io/styleguide/javascriptguide.xml 日本語：http://www38.atwiki.jp/aias-jsstyleguide2/pages/1.html Closure Linterを使用することで、チームでの統一がしやすくなります。 グーグル製JavaScript文法チェッカー jQuery JavaScript Styl
JavaScript MVC Style Guide
Over the years I've come up with a few rules for MVC web apps that have served me well and kept large codebases from descending into chaos. While the terminology may differ, these rules should hold true for most client-side MVC frameworks such as Backbone and Ember. Some frameworks have different naming MVC conventions, and slightly different takes on separating concerns. In this document, control
jQuery Coding Standards & Best Practices
All variables that are used to store/cache jQuery objects should have a name prefixed with a $. Always cache your jQuery selector returned objects in variables for reuse. var $myDiv = $("#myDiv"); $myDiv.click(function(){...}); Use camel case for naming variables. Use ID selector whenever possible. It is faster because they are handled using document.getElementById(). When using class selectors, d
angularjs-style-guide/README-ja-jp.md at master · mgechev/angularjs-style-guide
このスタイルガイドの目的はAngularJSアプリケーションのベストプラクティスとスタイルガイドラインを提供することです。 これらのベストプラクティスは以下から集めたものです： AngularJSソースコード 私が読んだコードや文章 私の経験 注意1： このスタイルガイドは草稿であり、その主な目的はコミュニティ駆動にすることです。足りない部分を補うことはコミュニティ全体から大きな賞賛を受けることになります。 注意2： 翻訳版のガイドラインを読み始める前に、それが最新の状態であるか確認しましょう。英語版のAngularJSスタイルガイドが最新版となります。 当ガイドラインは、JavaScript開発のガイドラインではありません。JavaScript開発のガイドラインはこちらで見つけることができます： Google JavaScript スタイルガイド Mozilla JavaScript ス
Closure Linter | Google for Developers
Closure Linter のサポートを終了 JavaScript の構文は進化し続けており、ES2015 以降では、Closure Linter を最新の状態に保つことがますます困難になっています。スタッフ割り当てがなくなり、メンテナンスが行われなくなり、非推奨となります。Google のほとんどのプロジェクトは、新しい linter に移行されました。 Closure ツールを使用しているチームは、代わりに Closure Compiler ベースの新しい linter を使用することをおすすめします。これを行うには、--jscomp_warning=lintChecks をコンパイラに渡すか、スタンドアロン リンター バイナリをビルドします。詳細については、Closure Compiler の wiki をご覧ください。このページの残りの情報は、引き続き Closure Linte
Backbone Patterns
Backbone Patterns Building apps with Backbone.js Here, I try to document the good practices that our team has learned along the way building Backbone applications. This document assumes that you already have some knowledge of Backbone.js, jQuery, and of course, JavaScript itself. Table of contents Model patterns Bootstrapping data View patterns Inline templates JST templates Partials Animation buf
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - standard/standard: 🌟 JavaScript Style Guide, with linter & automatic code fixer
GitHub - bendc/frontend-guidelines: Some HTML, CSS and JS best practices.
GitHub - airbnb/javascript: JavaScript Style Guide
GitHub - jscs-dev/node-jscs: :arrow_heading_up: JavaScript Code Style checker (unmaintained)
Primer
Internet Explorer デベロッパー センター