JavaScript Standard Styleのススメ - Qiita
みなさんは、JavaScriptのコードを書くときに文字列は何で囲みますか？シングルクォート？ダブルクォート？ インデントに使用する文字はスペース？それともタブ？ JavaScript Standard Styleは、そのように千差万別なコーディングスタイルを統一するためのスタイルガイドの一つです。1 JavaScript Standard Styleのルール JavaScript Standard Styleには、次のようなルールがあります。 インデントはスペース2個 文字列はシングルクォートで囲む 未使用の変数は禁止 文末のセミコロンは禁止 キーワードの後にスペースを入れる 関数名の後にスペースを入れる 値の比較に==ではなく===を使用 ただしobj == nullはnull || undefinedをチェックするために許容される 常にNode.jsのerr引数をハンドル ファイルの
PHP CS Fixer v2 でもっと快適PHPライフ - FLOG SPLASH
2014年に書いた PHP CS Fixer の記事 が今でも読まれているのですが、2016年末にリリースされた PHP CS Fixer v2.0 で後方互換のない変更が多く入っており情報が古くなっているため、改めて v2 について書いてみようと思います。なお現時点での最新版は v2.1.2 となります。 fivestar.hatenablog.com PHP CS Fixer とは PHP CS Fixer は PHP コードをコーディング規約 (CS = Coding Standards) に沿って補正してくれるライブラリです。歴史を辿ると、元々は Symfony のプロジェクトリードの fabpot 氏が作成したもので、 PSR-½ 、あるいは Symfony のコーディング規約 に沿ってコードを補正する機能が実装されています。 github.com チームでコードを書くときはコー
小〜中規模サイトのフロントエンド・コーディング規約 CSS・JavaScript編 - Qiita
2021/3/16 初めて記事を書いてから３年以上経過してしまったので、 内容を見直ししました。 関係者が10名以下の小〜中規模案件の開発・保守が多い弊社のCSS・JavaScript規約（にしたい）です。 長くなってしまったコーディング規約もようやく最後です。 ↓関連 環境構成編 HTML編 CSS、JavaScript は数年で書き方が変わってしまうので、 定期的に規約の見直しができると理想ですね。 小〜中規模サイトのフロントエンド・コーディング規約 CSS編 ディレクトリ構成 CSSに関するファイルの一般的な例を示します。 ルート ├ src ... 作業ディレクトリ │ ├ scss │ │ ├ lib ... 外部ライブラリなど │ │ ├ sprite ... spritesmith などで生成したファイル │ │ ├ foundation (base) ... 変数や mix
ES6時代のコーディングスタイルを考える - Qiita
ここではコーディングスタイルを考える上で、ES6（ECMAScript2015)の以下の特徴に注目して考察するものです。 変数宣言は、constを基本とする クラス宣言文や関数宣言文はブロックスコープ 文字列では、テンプレートリテラルを活用する ジェネレータのために、複数の構文が拡張された また、以下の基準を採用していることを特に触れておきます。 ES5コードの混在、ES5時代のスタイルとの互換性は取らない ES6 modulesが存在しない状況で適用可能なスタイルを取る 視認性を犠牲にコーディング時のミスの影響を隠蔽するスタイル(ヨーダ記法など)は取らない 局所視認性より、全体視認性での高さを重視する 微妙に違うものを区別しやすいスタイルにする 同じものは同じスタイルを取る 一覧しやすくコンパクトに書ける方を採用する 変数宣言は、constを基本とする ES6では再代入を認めないcons
セミコロンは省略？人気スタイルガイドに学ぶJavaScriptのコーディング規則
インデントにタブとスペースのどちらを使うのがいい？ JavaScriptにセミコロンは付けるべき？ JavaScript Standard Styleを使えばそんな論争にけりがつくかもしれません。 最近、注目を集めている@ferossのJavaScriptスタイルガイド、JavaScript Standard Styleを紹介します。チーム内での開発が円滑になり、プログラミングがより楽しくなります。 JavaScriptスタイルガイドのコーディング規約は、タブとスペースのどちらが良いかといった不毛な議論を無くし、コードに一貫性を持たせてくれます。JSLintやJSHint、ESLintといったLinterで使用できる多くのスタイルガイドのうちの1つです。 もしLinterが分からなければ、SitePointの記事『A Comparison of JavaScript Linting Too
システム屋さんがうれしいJava8対応のコーディング規約を公開します！！ | フューチャー技術ブログ
はじめにこんにちは。星です。 弊社では、お客様の基幹システム構築をする際、Java言語を採用することが多いのですが、2015年4月末にJava 7のサポート切れになったことを受けて、昨年よりJava 8で開発をしています。 弊社でもそれなりの規模の案件になると、社員やパートナーの皆様を合わせて、数百人が同時に開発することも珍しくありませんので、私の所属する技術部隊でコーディング規約をはじめとして、開発をするにあたってのガイドラインの整備やEclipse等の開発環境の整備などのタスクを実施して、標準化とクオリティの担保を推進しています。 さて、Java 8においては、Java 7において実装見送りとなったStream APIやラムダ式といった大きな機能追加がありました。とはいえ、これらの機能を使ったとして、性能的に大丈夫なのかとか、どういったコーディングスタイルが良いのか？ など、エンタープ
俺的Androidアプリ開発の基本方針 ver 2016.Q3 - Qiita
前提 @eaglesakura が務めているTopgate社は受託案件が多いので、この方針が絶対ではない。受注元によっては好き放題できるし、受注元によっては条件が厳しくなる。 また、弊社のAndroidアプリ開発は1人～数人で行われることが多い。そのため、この方針は更に大規模な開発では通用しない可能性があることも承知している。 その辺りは 以前の記事 でも書いたとおり。 ここに書いた方針はその時々の状況（公式ツールやSupport Library、流行り廃り）によって変化する。が、こういう構成になったのはその時時の理由があるわけなので、明文化することで後々「なぜこういう構成にしなければならなかったのか」ということを思い出せるようにもしておきたい。 環境整備 ソースコード管理 制限が無いのであれば、githubで管理する。githubのissueはRedmineに比べると機能的に不十分である
[翻訳] Airbnb React/JSX Style Guide - Qiita
この翻訳について Airbnb React/JSX Style Guideの和訳です。 間違っていたり分かりにくい箇所があれば、ご指摘いただけると幸いです。 Airbnb React/JSX スタイルガイド このスタイルガイドは現在一般的に使用されている標準に基いていますが、場合によってはいくつかの慣例（async/awaitやstatic class fields）が含まれていたり禁止されていたりします。現在、このガイドにはステージ3より前のものは含まれておらず非推奨です。 目次 基本的なルール クラス vs React.createClass vs ステートレス ミックスイン 命名規則 宣言 アラインメント 引用符 空白 引数 参照 括弧 タグ メソッド 順序 isMounted 基本的なルール Reactコンポーネントは1ファイルに1つだけにしてください。 ただし、1ファイルに複数の
![[翻訳] Airbnb React/JSX Style Guide - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/3f9c1a13a2d921a4c00c7e4138f2cab3d619a2b9/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fqiita-user-contents.imgix.net%252Fhttps%25253A%25252F%25252Fcdn.qiita.com%25252Fassets%25252Fpublic%25252Farticle-ogp-background-afbab5eb44e0b055cce1258705637a91.png%253Fixlib%253Drb-4.0.0%2526w%253D1200%2526blend64%253DaHR0cHM6Ly9xaWl0YS11c2VyLXByb2ZpbGUtaW1hZ2VzLmltZ2l4Lm5ldC9odHRwcyUzQSUyRiUyRnFpaXRhLWltYWdlLXN0b3JlLnMzLmFwLW5vcnRoZWFzdC0xLmFtYXpvbmF3cy5jb20lMkYwJTJGNTQ4MTAlMkZwcm9maWxlLWltYWdlcyUyRjE2NDkzMDU5NzQ_aXhsaWI9cmItNC4wLjAmYXI9MSUzQTEmZml0PWNyb3AmbWFzaz1lbGxpcHNlJmZtPXBuZzMyJnM9OTcxNTJmOTAxYzY4OTUwZmE2NTRjNDcxZDA3MmYzNDI%2526blend-x%253D120%2526blend-y%253D467%2526blend-w%253D82%2526blend-h%253D82%2526blend-mode%253Dnormal%2526s%253D197c29633cfc4106f69f23fd161148cb%3Fixlib%3Drb-4.0.0%26w%3D1200%26fm%3Djpg%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk2MCZoPTMyNCZ0eHQ9JTVCJUU3JUJGJUJCJUU4JUE4JUIzJTVEJTIwQWlyYm5iJTIwUmVhY3QlMkZKU1glMjBTdHlsZSUyMEd1aWRlJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMxRTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmdHh0LXBhZD0wJnM9OGUzZmJjNDJmZTI1MmJkMjU5ZjRiOTc3NzkyMDBiNDU%26mark-x%3D120%26mark-y%3D112%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTgzOCZoPTU4JnR4dD0lNDB5YW1hZGFzaHkmdHh0LWNvbG9yPSUyMzFFMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtcGFkPTAmcz0wYjFhYTE5YTA2NWZkZDczNWQ1NTdmNGYxYmFiZDM0ZQ%26blend-x%3D242%26blend-y%3D480%26blend-w%3D838%26blend-h%3D46%26blend-fit%3Dcrop%26blend-crop%3Dleft%252Cbottom%26blend-mode%3Dnormal%26s%3D039d2c724a02268a1427af1a035e6a56)
「Advanced Swift」のSwiftコーディング規約 - Qiita
以下は書籍「Advanced Swift」のSwiftコーディング規約の部分を翻訳したものです。原文はオンラインプレビューで公開されています。 Advanced Swift - Swift Style Guide この本を書くとき、そして私たちのプロジェクトでSwiftのコードを書くとき、以下のルールに従うようにしています。 可読性が最も重要です。これには簡潔性が助けになります。 関数には常にドキュメントとしてのコメントをつけましょう。ジェネリクスを使うものは特に。 型は大文字で始め（UpperCaseLetters）、関数と変数は小文字で始めます（lowerCaseLetters ）。 型推論を使いましょう。型が明らかなのに明示的に書くことは可読性を損ないます。 曖昧さがある場合や規約を定義する場合は型推論を使わないようにしましょう。（例えばfuncが明示的な戻り値の型を持つのはこれが理
やさしいPHPコーディング規約の導入・完全版 - コネヒト開発者ブログ
はじめに こんにちは、社内でコーディング規約おじさんと呼ばれ始めて久しい高野(@fortkle)です！ ここ2ヶ月間ほどに渡って通常の開発業務とは別に社内のアプリケーションにコーディング規約を導入する試みをしており、PHP7 Casual Talks や PHP BLT などのPHP関連の勉強会で都度共有してきました。 今回はそれらをまとめ、共有したいと思います。興味のある方の参考になれば幸いです。 開発効率を阻害するもの 弊社が運営している ママリjp、ママリQといったサービスが順調に成長していっている中、その成長を支える開発チームの人数も少しずつ拡大しています。今後もこの流れは続くと思いますが、エンジニアたるものそういった場合でも「コードの質」は落とさずに成長させたいものです。 弊社では非常に丁寧にコードレビューを実施していますが、質の高いコードを維持し続けるためにはコードレビューをよ
JavaScript(ES2015)でvarやletを使う必要はほぼ無い - id:anatooのブログ
ES2015でvarやletを使う場面はほとんど無いので、まずconstを使う。constだとダメな場合にはletを使う。 背景 ES2015では、変数を宣言するための文法としてconstとletが導入された。 const foo = 'foo'; let bar = 'bar'; constは再代入できない変数を宣言できる。letは再代入できる変数を宣言できる。 const foo = 'foo'; foo = 'hoge'; // ERROR let bar = 'bar'; bar = 'hoge'; // OK あれ、じゃあvarとletは同じなの？っていうとそうではなく、letやconstはvarとは違って、関数スコープよりも細かなブロック単位のスコープを提供する。例えばconstやletを使うと、if文やfor文などのブロック中でのみ有効な変数を宣言できる。 で、プロジェクトに
Swiftコーディング規約とコードスニペット
こんにちは。スマートデバイス開発チームの韮澤（にらさわ）です。 スマートフォンアプリの開発や開発標準の策定、技術推進などを行っています。 私の得意分野はiOS開発なのですが、iOSといえばSwiftの勢いが凄まじいですね。 私は先日try! Swiftカンファレンスに参加し、その盛り上がりを肌で感じてきたところです。 Objective-CからSwiftへ これまでiOS開発に使われてきたObjective-Cはその特殊な記法から、学習コストが高く開発を始めるための精神的な障壁が若干高めだったかと思います。 しかしSwiftの出現により、プログラミング未経験者はもとよりweb系エンジニアにとっても参入障壁がグッと下がった印象があり、社内でも「SwiftならiOSアプリを書いても良いかも」という意見が聞かれます。 そんな高まりを見せるSwiftの波に乗っていこう！ということでリクルートライフ
PSR-2に準拠した PHP コードを書いてみて気づいたこと | バシャログ。
現在ではロガーのインターフェイスに関する規約を定める PSR-3、PSR-0にとってかわる PSR-4、HTTP メッセージの取り扱いを定める PSR-7が追加されています。また、PSR-4の追加に伴って PSR-0は非推奨となりました。 PSR-3～7の概要については次の記事が参考になります。 PSR-3 Logger Interfaceの話: Architect Note PSR-4 Improved Autoloadingについて調べてみたメモ | kanonjiのブログ PHP - Psr7を使ってみた（というか不変オブジェクトを初めて使った感想） - Qiita さて、冒頭にも書いたとおり、ある長く続く開発プロジェクトで PSR-2をコーディング規約として採用することになりました。「採用する」というのは、これまで口約束や慣習で成り立ってきたものを明文化されたものに置き換えるという
大規模なJavaScriptアプリケーションを書く際に参考にしたいコーディング規約まとめ
JavaScriptは割と自由な言語で、行末にセミコロンがなくとも動作したり、varによる変数宣言をしなくとも使えたりします。とはいえ、動くから良いという訳ではありません。意図しない動作を防ぐため、さらに多人数での開発になればコードの品質を維持するためにもコーディング規約に沿った書き方が求められます。 他のプログラミング言語と同様、JavaScriptにおいてもコーディング規約が幾つか存在します。どれを取り入れるかは対象のアプリの性質、プロジェクトの特性やチームメンバーのスキルなどによりますが、参考になることは間違いないでしょう。必要に応じてカスタマイズするなどして、上手に取り入れてみてください。 Google JavaScript Style Guide Google製のJavaScriptスタイルガイドです。和訳版がこちらにあります。執筆時において、和訳版はバージョン2.72、本家は2
頑健なJavaプログラムの書き方
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 ＜アレスネットをご契約のお客様へ＞ 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
AndroidStudioのInspectionでコードチェックを楽にしてみた。 - Qiita
前置き チームでAndroid開発していて、コーディング規約作りました。 コードチェックはそれを指標としてやってもらっています。 ただ、最近、コードチェックがコーディング規約を守っているか監視する作業みたいな状態になってしまいました・・・。 コードチェックってクラスの設計だったり、メソッド名のわかりやすさだったり、そういう人間にしか出来ないことをチェックすべきで、メンバー変数がmから始まっていないとか。ifのネストの数が多すぎるとかそういうのは機械的なチェックで行いたくなりました。 そこで、AndroidStudioのInspectionを使って、開発中にセルフコードチェックさせようと考え、Inspectionの調査をし始めました。 AndroidStudioのInspectionでコードチェック楽にしようと思ったのだけど、項目多すぎwすで読み始めて半日以上たってる。まだ半分以上ある・・・
PHPのコーディングスタイルをPHP_CodeSnifferで修正する - Qiita
PHP_CodeSnifferはPHPのコーディングスタイルをチェックするツールとして有名ですが、現在開発中の2.0系ではチェックだけでなく修正もできるようです。 Fixing Errors Automatically · squizlabs/PHP_CodeSniffer Wiki インストール 2.0系ではpharも提供されているので、 https://github.com/squizlabs/PHP_CodeSniffer/releases からphpcs.pharとphpcbf.pharをダウンロードしましょう。 $ cat test.php <?php if($a==2) echo $a; else echo '3'; $ php phpcs.phar --standard=PSR2 test.php FILE: C:\Users\ishida\src\test.php ----
Android StudioでのコーディングにAndroidStyle.xmlを適用する - Islands in the byte stream (legacy)
curl -L https://raw.githubusercontent.com/android/platform_development/master/ide/intellij/codestyles/AndroidStyle.xml > ~/Library/Preferences/AndroidStudioPreview/codestyles/AndroidStyle.xml これでAndroidStyleを使えるようになる。XMLのインデントがAndroid Studio標準より深かったり、コードの幅が狭かったりして個人的にはそんなに好きなスタイルではないものの、まあこれも時代の趨勢かと思って使うことにした。
10年くらいJavaScriptを書いて思ったこと。 - Qiita
HTML内にjsを書くな。 jsDocを書け。 構文エラーのわからないエディタを使うな。 言語に足りない部分はツールで補え。 Chrome基準で作ると後で速度差に苦しむ。 1ファイルに数百行も書くな。 GruntやRequierJSを使ってモジュール化しろ。 描画に関するチューニングは後からできない。作り直しならできる。 $(function(){}) で全部囲むのはやめろ。 グローバルおじさんは無名関数で囲んで叩け。 半端な覚悟でsetTimeoutを使うな。 動的なページに組み込むより先に静的なHTMLで動くようにしろ。 自分が直せない怪しいライブラリは使うな。 どうせブラウザによって挙動違うのでECMAの仕様とか自己満足。 ネイティブアプリに勝とうとする時間を他のことに使え。 慣性スクロールが欲しいならMacを使え。 Flashのほうが簡単ならFlashでやれ。 Netscapeは死
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【保存版】Rubyスタイルガイド（日本語・解説付き）総もくじ｜TechRacho by BPS株式会社
