Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

はじめに http://qiita.com/raccy/items/bf590d3c10c3f1a2846b を見ていたら、はてブに「理由がないから」ということがよく挙がっていたので、理由をつけてあげたら有益な内容になるかな?と思い、拙いながらも補足を試みようと思います。 【2017 1/3 15:10 追記】 元記事の前提はgulpなどを使ってminifyなども行なえる(もしくは行う目標がある)前提の様子なので、中級者以上がターゲットかなーと思いました。そのつもりで読むととてもいい記事だと思っています。 「最新のJSの書き方を覚えてあとは変換機能に任せればレガシーなJSのキツイところに向き合わなくて済みますよ?」みたいなイメージだとわかりやすいかな? ==、!= 理由 暗黙の型変換が発生して、別の型の比較が真で扱われてしまう場合があるため。 解説 サンプルコードにも出ていますが言葉足らず
JavaScriptは大変難しい言語です。Rubyの難易度を2、Cの難易度を5、C++の難易度を8にすると、JavaScriptの難易度は12ぐらいあると思います。このコーディングガイドはそんなJavaScriptの深みに嵌まらないようにするためのJavaScriptの書き方を規定したものです。初級者1のための物ですので、わかってやっている人に好きにやってください。 このコーディングガイドは絶対に従わなければならないものではありません。私は一切強制はしませんし、初級者が従わなければならないという義務もありません。採用するしないはみなさんの自由です。 禁止編 JavaScriptには安易に使用してはいけない機能があります。下記の機能は、**それぞれの機能を使っても良い、または、使うべきであるという理由を説明できない限り、**使用してはいけません。 ==、!= ==と!=を使用してはいけません
アンチパターンなので、見出しの内容はすべてバッドノウハウです。 前に書いたやつ PHPのモダンな開発環境を紹介する - Qiita PHP - Functoolsを作った - Qiita PHPのlist()はタプル展開のための機能 - Qiita 関係ないけどこれも: シェル、ターミナル、コンソール、コマンドライン 追記: 本文中でとりあげた「怖い話」について、ちゃんと説明しました PHP - namespaceとBOMに何の関係があるのさ - Qiita ファイルの最後に?>を書く PHPコードは<?phpで始まり?>で締める。それがPHPの常識(キリッ ……そんなことはもう綺麗さっぱり忘れよう。PHPはテンプレートエンジンではあるが、Webアプリケーションを書く上では、もはやテンプレートエンジンとしての機能は求められなくなりつつある。 不要な?>を書いてはいけない理由は明確で、<?p
はじめに 本文書はSQLのスタイルガイドです。 PythonやRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? Angular.jsのアドベントカレンダー6日目です。(遅れてすみません汗) 今日は泥臭い?感じの話になります。 この記事は言及している人達の記事やスタイルガイドのまとめという感じなのですが、これからディレクトリ構成を考える初学者の方や,ディレクトリ構成に悩んでるかたの参考になれば幸いです Angular.jsのディレクトリ構成パターン紹介と、利用して感じた考察などのことを書きます。 はじめに LIG主催のAngular.js勉強会 #ng-curry にて、登壇したときの発表内容をまとめようと思っていたのですが、今回のAdvent C
JavaScriptは移り変わりの早い言語です。 もう1年以上経っていますし、記事のメンテもちゃんとできていないので、消し線を入れることにしました。 参考程度のために記事は一応残しますが、より新しい情報を読まれることをお勧めいたします。 はじめに --- 最近では JavaScript の実行環境はブラウザに限りません。(node.js, Web Workers) また、旧来のような <script> 経由でのロードもとうに古くなっています。今は CommonJS スタイルで、require を用いたモジュールのロードを行なうことがより良いとされています。 ですから、次のようなことは改める必要があります。 ~~- var YourModule = {}; などとして、外部から YourModule.hoge(); などと呼び出す書き方 this === window だと思うこと~~ 今回
会社やクライアント側で特にコーディングガイドラインが決めれてなかったり、フリーランスだけど結構好き勝手にコーディングしている、なんて時に1つの指針にできるようなコーディングのガイドラインを作ってみました。 また、Compass+SCSS記法を使用する場合はBEM(MindBEMding)を使った方が良いとは思うけど、複数人などのチームで初めて導入する時は少し敷居が高い気がするので、命名規則に関してはOOCSS、略語はMCSSの思想に基づくこととします。 前提 上記で書いたように本来はBEMるのがベストだけどあくまでBEMらない時に使うガイドラインです。 記述に関して結構当たり前としているところはすっ飛ばします。(CSSでプロパティとバリューの間は空ける、とか) 思想だけじゃ足りないルールはプロジェクトファイルにREADEME.mdなどにルールを記載しておくと良いと思います。 言わずもがな既
htmlspecialchars(); // 単語の間に区切りがない str_split(); // 単語の間に区切りがある 上記はいずれも標準関数ですが、決定的な違いがあります。 それは、 単語の間を アンダースコア( _ )で区切っているかどうかです。 我々は、この統一感のなさを真似するべきではないでしょう。 単語の区切りは、しっかりとルールに則って付けるべきです。 我々は、 単語間の区切りをどうやって表現するかを取り決め、それに沿ってコーディングする事が必要です。 キャメルケース・スネークケース・パスカルケース 単語の区切りを表現する方法として、代表的な3パターンを挙げます。 キャメルケース (camel case) 例 : htmlSpecialChars 複合語をひと綴りで表現し、次の単語の始まりを大文字で表す表現法です。 スネークケース(snake case) 例 : html
結論 いきなり結論 利用しているフレームワークの規約がないなら、 PSR-2(日本語) に従っておけば、間違いない! あとは、コマンドラインなり、エディタで自動整形する PHPコードをコマンドで自動整形! Condig Standards Fixer と PHP_CodeSniffer - Qiita 日本語なら以下がお勧め! PHPのコーディング規約 PSR-0、PSR-1、PSR-2、PSR-3とは | 9ensanのLifeHack 以下、コーディング規約とツールまとめ 目的 個人向け: PHPの開発をする場合、どのコーディング規約に従うべきか? をサクッと知りたい チーム向け: チームでどれを使うか? を決めるための参考に 教育: この規約でやって!と一言で教えるための参考URL PHPコーディング規約の種類 PEARコーディング規約 や Zend Codig Starndard
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く