SQL、書いてますか？ こと大規模データ処理の分野においてはSQLはもはや標準インターフェイスであり、 分析やらバッチやらに関わっている皆様は日々大量のSQLクエリーを生産していることと思います。 そこでちょっと気になるのが、 SQLのコーディングスタイルってどうするのが一般的なんだっけ……？ という点です。 イマドキはSQLなんてO/R mapperに吐かせることが多いからなのか、 それともコードを広い範囲で共有することがそもそもないからか、 SQLのコーディングスタイルについて見聞きすることは他のプログラミング言語に比べるとだいぶ少なく、 いまいち決定版と言えるスタイルがないなと感じています。 そんなわけで本日は、SQLのコーディングスタイルについての意識を活発化させるべく、 クックパッドでわたし（青木）が使っているコーディングスタイルから特徴的な点を紹介したいと思います。 特に、分析
CSSコーディング・スタイル
「こういうスタイルがCSSを記述する時に便利だよ！ コンセンサス(つづりは知らない)も取れるし！」とかいう建設的な意見はまるでないんですが、CSSを書く時の自分ルールは結構あるのでまとめがてらエントリにする。もちろんhxxk.jpのCSS の記述ルール記事のまとめというエントリを見たから書く気になったんだけど。 とりあえずスタイル指定を取っ払う 各ブラウザ間でのデフォルトの状態での差異を考えると頭が痛くなってくるので、手始めに取っ払って勝負。 フォント・ファミリの指定は別ファイル 見出しはこのフォントで本文はこのフォントといったように、フォント・ファミリの指定はいろいろな要素にまとめて指定することが多いので、まとめて別ファイルに。 様々なところで使うスタイルはhiddenやwrapperなどというクラスでまとめる CSS側でこの要素ではclear: both;とかいうのでも良いのだけど、こ
これはRuby Advent Calendar 2018の4日目の記事になります。昨日はpink_bangbiさんのあなたのしらない Refinements の世界でした。 一行まとめ Rubyのコミュニティ共有コーディングスタイルを目論むStandard gemをJustin Searlsが作っているので、意見があれば議論に参加しましょう！ Rubyのコーディングスタイルについて Rubyには公式のコーディングスタイルが決められていません。また公式のフォーマッターもありません。Ruby作者のまつもとさんは、コーディングスタイルについて、積極的には統一ルールを打ち出そうとはしていないようです。 まつもとさんの考えていることと、コーディング規約＆オートフォーマッタの現状についてはSiderのインタビューに詳しいです。ちょっと長いですが引用します。 まつもと : コーディング規約を決めてくれな
iOS4からBlockが導入されました。利用目的としてはDelegateパターンと大差ないと思っていますが、処理記述が呼び出し元で記述できることで可読性が高くなります。 また、コールバック時に利用されるperformedSelectorが非常に使いづらく複数の引数となった場合などを考慮してNSDictionaryで定義したりInvocationを使う必要がったりと面倒な点が多々ありました。 今回は、CoreFoundationにカテゴリで組み込まれたBlockを活用したBlocksKitフレームワークを紹介したいと思います。かなり便利なため、今後のコーディングスタイルを変えてしまうほどのインパクトがあると個人的には思っています。 BlocksKit https://github.com/zwaldowski/BlocksKit BlocksKitはBSD, MITライセンスの元で利用可能で
Java エンジニアチームが始めやすい Scala コーディングスタイル #ichigayageek
English version is here: http://www.slideshare.net/seratch/jjug-ccc-2014springeng http://www.java-users.jp/?page_id=1048#R2-4
コーディングスタイルの常識をぶち壊せ
CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。
ここではコーディングスタイルを考える上で、ES6（ECMAScript2015)の以下の特徴に注目して考察するものです。 変数宣言は、constを基本とする クラス宣言文や関数宣言文はブロックスコープ 文字列では、テンプレートリテラルを活用する ジェネレータのために、複数の構文が拡張された また、以下の基準を採用していることを特に触れておきます。 ES5コードの混在、ES5時代のスタイルとの互換性は取らない ES6 modulesが存在しない状況で適用可能なスタイルを取る 視認性を犠牲にコーディング時のミスの影響を隠蔽するスタイル(ヨーダ記法など)は取らない 局所視認性より、全体視認性での高さを重視する 微妙に違うものを区別しやすいスタイルにする 同じものは同じスタイルを取る 一覧しやすくコンパクトに書ける方を採用する 変数宣言は、constを基本とする ES6では再代入を認めないcons
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー PythonにはPEP8という公式のコーディングスタイルがあります。このスタイルに従うことで，Pythonの思想「誰にとっても明確な手法が，一つだけあることが好ましい（There should be one-- and preferably only one -- obvious way to do it)」に沿った，見やすいコードを書くことが出来ます。 読んでみると分かるのですが，変数や関数，クラスなどの命名規則から，どこに空白を入れろとか改行を入れろとか，かなり細かく記述があります。それぞれの規則にはちゃんと理由があって，出来る限り守った方がコードが見やすくなるのは確かなのですが，
こういう記事が上がって http://bulkserver.jp/blog/2014/08/07/php-code/それへの反応 http://b.hatena.ne.jp/entry/bulkserver.jp/blog/2014/08/07/php-code/https://twitter.com/search?q=http%3A%2F%2Fbulkserver.jp%2Fblog%2F2014%2F08%2F07%2Fphp-code%2F記事の最初のカッコの省略だけど、世界的に評価されて広く使われてるようなプロジェクトのコードを見ると、案外{}が省略されていたりしてそんなことは気にしてない。(たとえばlinux, apache, postgresql, mysql, chromium, netbeeans, eclipse, llvm, jruby, android) で「こんなコ
RjpWiki はオープンソースの統計解析システム R に関する情報交換を目的とした Wiki です2013-10-19 Ｑ＆Ａ (初級者コース)/15 Google の R コーディングスタイル 2013-10-18 R掲示板 2013-10-17 Rでデータマイニング R史 Python で R 2013-10-16 R本リスト RとHTML5 2013-10-14 Shiny 2013-10-13 R のインストール 2013-10-11 追加パッケージをなんでもかんでも追加する 2013-10-10 Rで複雑系 2013-10-06 The MakeR Way 2013-10-05 R でエンタメ R で３Dプリンター出力 2013-09-29 RExcel 2013-09-27 Rシラバス R と Big Data 処理 2013-09-26 トップ頁へのコメント リンク集 20
Eclipse用C言語コーディングスタイルチェックプラグイン『KariyaSiesta』をリリースしました - みずぴー日記
伊東まで開発合宿に行って、みんなでC言語のコーディングスタイルチェッカーを作ってました。 => KariyaSiesta | C 言語向けのコーディングチェッカ 配布サイトも作りました。 ルールを簡単にカスタマイズできるようになってるので、みんな使うといいでゲソ。 特徴 Eclipseのプラグインとして使える Eclipseプラグインとして実装されているので、IDEで使えます。 もちろんCDTとも組合せることができます。 簡単イントール 更新サイトから簡単にインストールできます。 もちろん自動アップデートにも対応してます。 XPathでルールで書ける ルールはXPathで書くことができます。 例えば『whileの内でbreakを使ってはいけない』というルールは以下のようになります。 こまかい書き方はマニュアルを参考にしてください。 //Stmt[@sort="While" and .//k
Ruby のコーディングスタイル
$Id: codingstyle.rd,v 1.6 2003/06/18 23:03:32 aamine Exp $ 今日 (1999/02/01)、Linux 2.2.1 のソースをダウンロードしてきた ついでに始めてドキュメント群を読んでみたのだが、そこに CodingStyle なんて文書があった。Linux の作者の Linus 氏が Linux カーネルを 書く時のコーディングスタイルについて書いているのだが、これが なかなかおもしろい。さっそくまねをして、Ruby におけるコーディ ングスタイルについて書いてみようと思う。 とは言っても筆者はヒトのコーディングスタイルをどうこう言えるほど 偉くはないし、これを読む人に「ソースコードはこのように書け」と 言うつもりもない。この文書はあくまで「おれはこうじゃなきゃやだ！」 という自己主張である。 インデント インデントは基本的に 2
Perl::Critic - Critique Perl source code for best-practices. - metacpan.orgをコーディングスタイルを統一するために使っています。 （実際には字面としてのコーディングスタイル（コードレイアウト？）はPerl::Tidy - metacpan.orgが担当しているわけですけども、ここでは「use strictを入れる」「PODを付ける」なども含めてコーディングスタイルと言ってます） コーディングスタイルに唯一絶対的に正しいなんてものはないわけで（だから宗教論争にもなるわけで）、機械的に統一することで揉め事はなくなります。 しかしその時に.perlcriticrcなんかを使ってコーディングスタイルをデフォルトから変更してしまうと元も子もありません。 .perlcriticrcに何を設定するかで揉めますし、例えその時に揉めな
CSS Styleguide CSSにはスコープという概念が存在しないのでコードを指定する順番を管理してカスケーディングを意図した通りにおこなわせる必要があります。また、インデントや命名規則など好みや考え方が異なることも多いです。 スタイルガイドは知識を共有することで認識のズレをできるだけ無くし、制作をする上での約束事を決めることだろうと考えています。以下のガイドラインはCSSとSass（scss記法）を扱う上でベターだと考えていることをドキュメントとしてまとめたものです。 このガイドラインは2015年11月15日公開（2016年1月14日に改定）されたもので、最新のガイドラインはGitHubで公開しています。 css-styleguide | GitHub manabuyasuda はじめに このスタイルガイドはCSSを扱う上でベターだと思われる方法をまとめたものです。必ずしも正しいもの
一般的なスタイルとシンタックス 以下のページではCodeIgniterを開発する際に守っているコーディングルールについて記述します。 目次 ファイルフォーマット PHPの囲みタグ クラス名、メソッド名 変数名 コメント 定数 TRUE、FALSE、NULL 論理演算子 返り値の比較、型のキャスト デバッグコード タブ／スペース 互換性 クラス名とファイル名を共通にする データベーステーブル名 1ファイル1クラス タブ／スペース 改行コード インデント カッコの前後のスペース コントロールパネル内のローカライズされたテキスト プライベートメソッド、プライベート変数 PHPエラー PHP短縮開始タグ 1行1ステートメント 文字列 SQL文 メソッド（関数）の引数のデフォルト値 タグパラメーターの上書き ファイルフォーマット ファイルはUnicode (UTF-8) エンコーディングで保存します
この記事は、PowerShell Advent Calendar 2017 3日目の記事です。 qiita.com 新しい言語を触るときに気になるのが、その言語はどのように書くことを意図しているのかです。私が触ってきた言語の多くは「その言語の考えの基本」となるものを持っており、コーディングガイドライン上でもそれを明示していることが多いように思います。 PowerShell はどうなのでしょうか? 今回はPowerShell ではどのようなコーディングスタイル (本記事ではコーディング規則も同じ意味で用います)で書くといいのかを考えてみたいと思います。 思いのほか記事内容がながくなってしまったので、結論だけ見たい方は まとめ をどうぞ ※ 決してこの記事の内容が絶対正しいと思っていません。みなさんが書いていく中でどうすればいいのか、と思ったときの良いヒントになることを願っています。 軽い記事
今回は JavaScript のコーディング規約の情報収集をしたかったのだが、別の言語のものもいくつか見つかったのでメモしておく。 Java Script Coding Standard JavaScript style guide - MDC (Mozilla) フレームワーク / ライブラリ系の開発者向けガイド UI Developer Guide - jQuery JavaScript Library (シンプル) Dojo Style Guide | The Dojo Toolkit (Java を参考に) StyleGuide - MochiKit - Trac (Python の PEP8, PEP7 を参考に)[翻訳]MochiKit - スタイルガイド ライブラリ系の規約について、それぞれ解説しているページがあった。 JavaScriptのコーディングスタイル -- ありえ
奇麗なコードは可読性も高く、バグも減りますよね。 JavaScriptは下手に書くとものすごくスパゲティなコードになりやすい言語ではないでしょうか。ただでさえコールバックを使うのでネストしやすく、さらに処理が非同期だったりするとカオスになりがちです。 そんなJavaScriptのコードも機械的にチェックすれば問題点が洗い出されて可読性が高くなるかも知れません。そのためのチェックツールがjscsです。 インストールはnpmを使って行います。インストールが終われば次のようなヘルプが出せるようになります。 $ jscs --help Usage: jscs [options] <file ...> Options: -h, --help output usage information -V, --version output the version number -c, --config [p
PythonにはPEP8 (日本語訳)という 公式のコーディングスタイルあります。 どうせならちゃんとコーディングスタイルに沿った綺麗なコードが書きたいですよね。 ということでvimでPythonコードがPEP8に従っているか自動的にチェック、修正するようにします。 PEP8のチェック PEP8に従っているかチェックするにはpep8という、そのままの名前のツールを使います。 pep8 - Python style guide checker おまけとしてpyflakesという、文法チェックや未使用なimportや変数を教えてくれる便利なツールも入れときます。 pyflakes - passive checker of Python programs インストールはpipで。 ちなみに、pep8とpyflakesを合体したような、flake8というツールもあります。 flake8 - the
去る9月5日に開催されたオープンソース系開発者向けカンファレンス「ITpro Challenge! 2008」（主催：日経BP、「XDev 2008」と同時開催）は大変興味深く、素晴らしい講演会になった。日本を代表するような4人の独創的な開発者が、「プログラマの挑戦が世界を変える、ハッカーの流儀がメインストリームになる」というテーマに沿って、自らのプログラマーとして歩んできた道やプログラミングスタイルを、ざっくばらんに語ったのである。 世界を変えるプログラマーとして話者に選ばれたのは、モバゲータウンを作った川崎修平さん、仏ネクセディ社CTOの奥地秀則さん、米シックス・アパートの宮川達彦さん、Winnyの作者として知られる金子勇さん。いずれ劣らぬ挑戦者ばかりである。しかしそれゆえに属人性も大変高そうにも思える彼らの“流儀”の中に、私たち凡人でも何か真似できるようなことはあるだろうか。襟を正し
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をダウンロードしましょう。 $ curl -LO https://github.com/squizlabs/PHP_CodeSniffer/releases/download/2.0.0RC1/phpcs.phar $ curl -LO https://github.com/squizlabs/PH
随時更新中です。ご了承ください。 書いた人に重大な欠陥があるため、言語仕様と合わないなど多いです。絶賛フィックス中…… 現在までの問題点一覧 __(アンダーバー2つ) C++ではすべて予約語。 Cでもリンク時に異常が出る可能性あり？ コーディングスタイル、それは全プログラマを宗教戦争へと貶める魔の言葉のひとつである。（他にはスクリプト言語宗教戦争、エディタ宗教戦争などがある） 基本方針 伝説を信じない。 真実を受け入れる。 言語特有の伝統的な作法がある場合、そちらを優先する。 その作法が伝説に由来するものならば、訂正する。 業務でコードを書くプログラマ、つまりある程度の範囲でコードを他者（あるいは他社）と共有する必要があるプログラマとしてまとめる。 そもそも個人のコーディングスタイルなど、誰も興味が無い。自由に書けばいい。本当に個人のものならば。 そのため、ある程度強制を感じさせる口調で書
ここんとこ、年末にだす Cocoa勉強会の会誌「Cocoa Life Vol.3」のレビューをひたすらやってるわけだけど、Growl の記事のチェックでプロジェクトの Trac を検索していたいら、Growl coding standards ってのを見つけた。 で、なんとなく調べたくなったので、Cocoa のコーディングスタイルについて書かれたものを探してみた。 Coding Guidelines for Cocoa 本家 Apple による ADC ドキュメント。見た目上の話でなく、名前づけのルールの話がほとんど。その多くは Cocoa では常識となっている話なので「そうですね」とうなずくばかり。 だけれど、"Tips and Techniques for Framework Developers"は、フレームワークの実装デザインの話でおもしろい。 WebKit Coding Styl
ep.54 UIT Playbook - これが私たちのコーディングスタイル | UIT INSIDE
@spring_raining が @potato4d @jaycompsci @T28_tatsuyaに、現在 UIT で策定中のコーディングスタイルについて聞いてみました。 自己紹介 @jaytype UIT フロントエンドエンジニア LINE NEWS のフロントエンド開発を担当 @T28_tatsuya UIT フロントエンドエンジニア LINE Survey, ショップカードを担当 UIT Playbookについて プロジェクトの概要 コーディングガイドラインを決めるまでの背景 元々コーディングガイドラインがあったが、長年メンテされておらず最近はほとんど守られていない状態だった UIT Playbookが定めるコーディングスタイル UIT Playbookはまだ始まったばかりだが、ルールの策定や整備はどのような手順で進めているか？ 基本はGitHubのPull Requestベー
GoogleではJavaScriptは特定のコーディングスタイルで統一されるようにClosure Linterという専用のスクリプトを使用しているそうです。 Google JavaScript Style Guide(Google JavaScript Style Guide 和訳)という規則に従ってjsのコードは書かれていて、その規則に沿っているかを確認するgjslintとその規則に合うように修正するfixjsstyleからなるスクリプトです。 インストール方法 How to Use Closure Linter – Closure Linter – Google Code pythonで書かれているのでeasy_installを使ってインストールします。 まずはPythonをインストールしてなかったらインストールして、次にeasy_installコマンドを使うためにsetuptools
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
このドキュメントは Mozilla コードベースで使われる基本スタイルとパターンを説明するためのものです。 新しいコードはこれらの標準に沿うよう試みるべきです。それは、既存のコード同様にメンテナンスが楽になるためです。 もちろん、どのルールにも例外はあります。しかし、にもかかわらずルールを知ることは重要なのです！ これは、新しく Mozilla コードベースへ向かっている、コードをレビューされるプロセスにある人へ特化して向けられています。 レビューを受ける前に、このドキュメントを読み通して、あなたのコードがここで推奨されている内容に沿っていることを確認してください。 命名とコードのフォーマット The following norms should be followed for new code, and for Tower of Babel code that needs cleanup
PEP 8とは PEP（Python Enhancement Proposal）とは、Pythonの新機能に関する仕様やその背景を、Pythonコミュニティーに対して提供する文書のことだ。これまでに数多くのPEPが発行されているが、その中でPEP 8は「Style Guide for Python Code」と銘打ち、Pythonコードを記述する際の決めごとを定めたものとなっている。 Pythonは誰が書いても同じようなコードとなりやすいように作られた言語だが、そうはいってもコードの書き方そのものが言語仕様上でガチガチに定められているわけではない。例えば、if文を例に取れば、同じコードでも次のような書き方ができる。 if節の本体を改行なしで書くこともできるし、空白文字はある程度自由にコード中に含めることもできる。どんな書き方をするかは、プログラマーに一任されている。だが、これでは誰の目にも
VC++/MFC [MS] INFO: Microsoft Foundation Class Library Development Guidelines
はじめに 自分なりのコーディング規約をまとめておき，見返すときに使用する．順番など意識せず適当に書いているのでまとまり感はない． 参考文献 以下を参考に作成いたしました．書籍類は，中級者向けかも．少なくとも初心者向けではないと思います． 書籍 リーダブルコード： 読みやすいコードとは何か? 伝わりやすいコードとは何かをまとめた良書．O'Reilly，amazon Effective C++： 古いと言われることもあるが，C++ のデファクトスタンダードともいわれる良書．いろいろなテクニックや考え方が載っている． amazon C++ Coding Standards―101のルール、ガイドライン、ベストプラクティス：Effective C++ と似たような面が多いがやっぱり参考になる． CODE COMPLETE [上・下]：設計から実装まで幅広い範囲で様々な考え方が記載されている．完読し
概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: Why We Argue: Style — Sandi Metz 原文公開日: 2017/06/01 著者: Sandi Metz -- 名著『オブジェクト指向設計実践ガイド』の著者です。 本記事は私のChainline Newsletterで最初に公開いたしました。 私は長年の間、コードのことで議論になるのはなぜなのか、そして決定的に食い違う意見を建設的な方向に転換する方法はないものかと模索してきました。 私の見解は、非常に特異な文脈の中から生まれました。私は、ありとあらゆる業種の企業に出向き、数日間に渡るオブジェクト指向設計の講義を年に10回から12回は繰り返しています。私は部外者ではありますが、そうした場所で数日間を過ごすだけでも企業の裏舞台の一端を垣間見られます。 そのときに気づいたのですが、ある場所では誰もがおおむね幸せ
kyanny のブログ : perltidy で Best Practice なコーディングスタイルを身につける
2006年09月22日19:15 カテゴリ perltidy で Best Practice なコーディングスタイルを身につける 最近、 :q と q: を押し間違えるのにうんざりして vim から emacs に鞍替えしたのですが、 perltidy-region というのを見つけて、せっかく Perl Best Practices も持っていることだし、これを期に perltidy なスタイルを身につけよう！ということで導入してみました。 導入といっても、開発マシンは Fedora Core 5 なので、 yum install perltidy で一発。 .perltidyrc は PBP に載っていたお手本をそのまま使っています。 使っているのですが、 cperl-mode のインデントと微妙にスタイルが違うのでちょっと戸惑っていたり。まだコード丸ごと perltidy という感じ
みなさんも独自のコーディングスタイルをお持ちだと思います。ifの後のスペースはどうするとか、switchとcaseは同じインデントにするとかしないとか。。。この手の議論は昔からされているようで、結局、宗教戦争の域に達してしまうようです。当然、それぞれのスタイルで色々な利点があるので仕方がないんですが。 現実問題、汎用ライブラリとか仕事でコーディングする場合、ある一定のコーディングスタイルに合わせておいた方が自分以外の開発メンバーがコードを読む場合に負担が軽くなります。とは言っても、メンバー全体でなかなか遵守できないのが実際なのではないか、と思います。 JavaではCheckstyleがそれに相当しますが、PHPではphpCodeBeautifierというツールがあります。2004/11/08時点での最新版はバージョン0.8で、Windowsのexe形式のみ用意されているようです。UNIX/
CSS Nite LP39「Coder's High 2015：コーディングスタイルの理想と現実」のフォローアップを公開します｜CSS Nite公式サイト
ベストセッション20192019年、CSS Niteでは49回の関連イベントを通して123セッションが行われました。その中からベスト・セッション＋αを選びました。 2010年から2019年のベスト・セッションCSS Niteベスト・セッション2019CSS Niteベスト・セッション2018CSS Niteベスト・セッション2017CSS Niteベスト・セッション2016CSS Niteベスト・セッション2015CSS Niteベスト・セッション2013CSS Niteベスト・セッション2012CSS Niteベスト・セッション20112010年のベスト20セッション CSS Niteについて CSS Nite（シーエスエス・ナイト）は、Web制作に関わる方のためのセミナーイベント。2005年10月にスタートし、2017年10月で丸12年。 これまでに、600回を超える関連イベントを通し
シェルスクリプトのコーディングスタイルについて調べ物をしたので、その情報源の一覧と今の感想のメモを書いてみます。 最もよく参照されているのではないかと思われるシェルスクリプトのコーディングスタイル。 UNIX & Linux コマンド・シェルスクリプト リファレンス > シェルスクリプト Tips 【参考情報】このページにリンクを張って、項目をサマリしているページ。 上記のページの最初には「ここに書かれている内容は、あくまで筆者の好みでありほぼ完全に主観」と書かれていますが、この内容は規約としてどこでも採用すべき内容だと思います。また定数には大文字の変数名を使うというガイドラインですが、自分で書く場合、環境変数も大文字変数に加えます。 好みがあるとすれば、インデントの幅ぐらいでしょうか？ ここではインデント幅は半角スペース2つが推奨されていますが、個人的には半角スペース4の方が好みです。
ライフスタイル／コーディングスタイル、四者四様の“流儀”からなにを学ぶか？ ITpro Challenge！レポート（後編）：CodeZinei
しかし、この日演台に立ったほかの3人には、川崎さんなら「モバゲータウン」、奥地さんは「GRUB2」、金子さんはもちろん「Winny」とそれぞれ“代表作”があるのに対して、宮川さんの代表作となると、実はこの原稿を書きながら少し悩んだところなのだ。 宮川さんが現職の前にCTOを務めていたときにライブドアが「liveddorブログ」がスタートしているが、その開発には1行も携わっていないという。それでは、宮川さんをこれほどまでに知らしめているものはなんだろう[*]、ということを考えながら講演に聞き入った。 [*]この日の講演では語られなかったマルチアグリゲーター「Plagger」という斬新なツールもあるが、それだけではあまりに通好みにおもえる。 宮川さんは、Moveble Typeが普及しはじめたばかりのころに「Bulkfeeds」というブログ検索サイトをいち早く立ち上げ、『教科書には載らないニッ
• PSR-1は高度な技術的相互運用性を目的としたコーディング標準 • PSR-2/→PSR-12はプロジェクト内での認知的摩擦を軽減するためのスタイルガイド • PSR-12はPER Coding Styleに進化した PSRとは何か PSRが何ではないかについて下記の記事にまとめたので、あとでゆっくり読んでください。 というか↑の記事にだいたい書いたので、この記事はコーディングスタイルに絞った内容ということになります。 重要な部分だけ抜萃して再掲しましょう。 PSRを管理するのはPHP-FIG (The PHP Framework Interoperability Group、PHPフレームワーク相互運用グループ)です。この組織はPHPのフレームワーク・CMS・ツールなどの開発者の寄合所帯です。 Frequently Asked Questions - PHP-FIGの内容をざっくり訳
コーディングスタイル - Zend Framework PHP 標準コーディング規約 - Zend Framework
Caution: The documentation you are viewing is for an older version of Zend Framework. You can find the documentation of the current version at: https://docs.zendframework.com/ コーディングスタイル - Zend Framework PHP 標準コーディング規約
Scheme:コーディングスタイル
koguroさんのとこで出た話題 コーディングスタイルifのbegin括弧の位置let式if式関数定義関数のサイズ編集環境括弧を書くタイミングemacsのキーバインディング括弧挿入のキーバインド全体的なコメントはこちら コーディングスタイル みなさんどんな風に Scheme のソースを書かれているのでしょうか。 他の人のソースを参考にしているのですが、どこかに明文化されたものがあるとうれしいです。(C みたいに K&R とか whitesmith とかいろいろ流派があるのでしょうか) とりあえず、バリエーションが出る要素を上げていってみましょ。Shiro 関連：Lisp:コメント ifのbegin もしC言語でif (...) { を if (...) (begin と書けといわれたらうんざりするでしょう。 C言語のswitch文にbreak;を書いているような気分になります。(gemma
前の記事のコメントで npmのコーディングスタイル を紹介されて、ちょっと読んでみたら面白かったので翻訳してみました。 なお、かなり意訳している部分やそもそも上手く理解できなかった部分もあります。 以下、本文。 npmは面白いコーディングスタイルです。（原文: npm's "funny" coding style） 説明 npmのコーディングスタイルはちょっと変わっています。それは異なる理由から変えられてるのではなく、故意的に見かけの混乱を減少させバグを明確にするという、製作に優しいスタイルになっているというわけです。 もしあなたがnpmにコードを送ろうとしているなら（応援します）、あなたはこのnpmスタイルに適合するようにコーディングするべきです。 Note: npmjs.orgのパッケージまで一々チェックしているわけではありません。 一行の長さ 一行は80文字短くなるようにしてください
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
分析SQLのコーディングスタイル - クックパッド開発者ブログ
Rubyコーディングスタイルの現状とStandard gemのご紹介 - Qiita
iOSコーディングスタイルを変えてしまうBlocksKitの紹介 - 中継地点
ES6時代のコーディングスタイルを考える - Qiita
Pythonのコーディングスタイル(PEP8)をコマンドでチェック — TRIVIAL TECHNOLOGIES 2.0
コーディングスタイル論争「カッコを省略するな」が出るたびに思う事
Google の R コーディングスタイル - RjpWiki
holidays-l開発ブログ - Perl::Criticでコーディングスタイルを統一
CSSとSassのコーディングスタイルガイドを作ってみた - Qiita
PHPコーディングスタイル : CodeIgniter ユーザガイド 日本語版
PowerShell のコーディングスタイル - tech.guitarrapc.cóm
[J] JavaScript のコーディング規約 (コーディングスタイル) - Jamz (Tech)
jscs·奇麗なコードを書こう。JavaScriptコーディングスタイルチェッカー MOONGIFT
vimでpythonのコーディングスタイルを自動でチェック&自動修正する - blog.ton-up.net
ライフスタイル／コーディングスタイル、四者四様の“流儀”からなにを学ぶか？ ITpro Challenge！レポート（前編）
PHPのコーディングスタイルをPHP_CodeSnifferで修正する - Qiita
コーディングスタイルまとめ
Cocoa のコーディングスタイル - きりかノート
GoogleのJavaScriptコーディングスタイルチェッカー「Closure Linter」
JavaScriptのコーディングスタイル 2.0 — ありえるえりあ
Mozilla コーディングスタイルガイド - Mozilla | MDN
［Python入門］Pythonコーディングスタイルガイド
コーディングスタイル関連リンク集 - yaminabebugyou @Wiki
C++ コーディングスタイルメモ - Qiita
コーディングスタイルで社内が揉める理由（翻訳）｜TechRacho by BPS株式会社
phpCodeBeautifier - コーディングスタイルを統一する - Do You PHP?
シェルスクリプトのコーディングスタイル・コーディング規約について考えてみる - 双六工場日誌
PSRとコーディングスタイルの関係、そしてPERへ - Qiita
npmのコーディングスタイルを翻訳してみた - Qiita