名前のつけ方More Pragmatic Patterns of Ruby on Rails at Kansai Ruby Kaigi #02Yasuko Ohba
Programming Rules
Table of Contents Author: EPK/NP Klas Eriksson, EUA/SU M Williams, J Armstrong Document: EPK/NP 95:035 Program Development Using Erlang - Programming Rules and Conventions 1 Purpose 2 Structure and Erlang Terminology 3 SW Engineering Principles 3.1 Export as few functions as possible from a module 3.2 Try to reduce intermodule dependencies 3.3 Put commonly used code into libraries 3.4 Isolate "tri
LoveRubyNet Wiki: RubyCodingStyle
2005-05-14 15:48:46 +0900 (1238d); rev 16 青木が使っている Ruby のコーディングスタイルです。 インデント インデントは 2。 インデントがでかすぎると end が離れて美しくない。 {....} のインデントだけを 4 にしてみた時期もあったが、 やっぱり全部 2 にしたほうが単純だし統一感がある。 またタブは一切信用せずに全部スペースにする。 ※ 有名な Ruby hacker の前田修吾氏はかつてインデントを「3」にしていた。 この理由について青木は if true while true unless false return 1 end end end のように end がピッタリそろうのが素敵かなあ、 と評したのだが、実際の理由は全然違ったようだ。 → [ruby-list:18603] ※※ 素敵という言葉は江戸時代にできたそうだ。
コーディング規約をまとめてみた (Ruby編) - bojovs::blog
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
Ruby Patterns from GitHub's Codebase
There are a few specific things we’ve done at GitHub to help our maintainability and reliability of our Ruby apps. Focusing on improving documentation, optimizing the first-run experience, splitting out our API as Sinatra apps, and being careful about how we ship impacting infrastructure changes has helped us out dramatically. Slides
変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -
この記事は、Cagdas Basarane 氏のブログ、 CodeBuild から 2012年2月20日の記事 "15 Best Practices of Variable & Method Naming" を翻訳したものです。 原文URL http://codebuild.blogspot.com/2012/02/15-best-practices-of-variable-method.html 十分短く十分長い変数名をスコープごとに使用する。一般的に、ループカウンタには1文字、条件やループ変数には1単語、メソッドには1-2単語、クラスには2-3単語、グローバル変数には3-4単語を使用する。 具体的な(specific)名前を使用する。例えば、"value"、"equals"、"data"といった変数名はいかなる場合も有効ではない。 意味のある(meaningful)名前を使用する。変数
AJDTを使って規約違反のコードを検出する方法 - 達人プログラマーを目指して
AspectJというと、メソッドなどに処理を織り込むAOPのイメージが強いと思いますが、AJDTというeclipseのプラグインを使うと強力なコード検証ツールとして利用できることは意外と知られていないようです。（AJDTはSpring Tool Suiteには最初から内蔵されています。） 実際、 コントローラークラスのメソッド内でフィールドの設定を行う サービス層を経由せずに直接DAOを呼び出している 日付オブジェクトを直接newしている*1 などの箇所をコンパイル時に検証して、警告やエラーとして検出できます。 たとえば、Spring MVCのコントローラークラスのメソッド内でフィールドの設定を行っている箇所を警告として検出するには以下のようなアスペクトを書くだけです。 package sample.mvc; import org.springframework.stereotype.Co
いろいろな言語のコーディング規約，スタイルガイドのリスト — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 みんなのブロックチェーンは，ブロックチェーンの入門書。暗号やハッシュなどを含め，基礎からブロックチェーンの仕組みを学べる書籍です。 いろんな方に「新しい技術を学ぶことの楽しさ」を感じ取ってくれたら著者として嬉しいです:-)。お金は技術的にどのように定義されるのか。 みんなのIoTは，モノのインターネットと呼ばれるIoTの入門書です。IoTの基本について，読者に寄り添って優しく解説しました。裏テーマは一番とっつきやすいPython入門書。サポートページはこちら みんなのPython 第四版は，より分かりやすい入門書を目指し，機械学習やデータサイエンスの章も追加して第三版を大幅に書き換えました。Python 3.6にも華
Javaコーディング規約／WEBワークショップ Acroquest Technology 株式会社
皆さん、システム開発において、コーディング規約は利用していますか？ プログラムの質を向上させるには、開発者としてのマナーである「コーディング規約」は 欠かせません。 ただ、EclipseといったIDEやJava言語自体の発展もあり、ひと昔前の規約は、 形骸化してしまっていることも多いのではないでしょうか？ そこで、当社では、社内で2000年より作成・改版を行ってきたJavaコーディング規約を 公開することにしました。 このコーディング規約は、開発者自身の経験、および、最近のJavaの動向を踏まえ、 現場で本当に役に立つノウハウをまとめたものです。 そのため、Eclipseで自動でフォーマットできるような簡単なスタイルの規約については 記述を省略し、より重要となるコーディングテクニックや考え方について記述しています。 これからJavaを学ぶ新人の方はもちろん、開発者の技術力向上に繋がる内容に
Debian JP Project - Debian JP 文書作成の指針 - 表記
[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ next ] Debian JP 文書作成の指針 Chapter 2 - 表記 2.1 英数字、記号の表記 英数字や記号に関する規則は以下の通り。 英数字は原則として半角にする。 例: Ｄｅｂｉａｎ -> Debian 記号類は原則として半角にする。 例: （） -> () 句点は「.」を使わず「。」を使う。 読点は「,」を使わず「、」を使う。 英字アルファベットと日本語が並んだ場合、半角スペースを空ける。 例: 「日本語と English が並んでいる」 英字アルファベットと句読点が並んだ場合はスペースを空けない。 例: 「一方 Debian、Red Hat、Slackware などの」 英字アルファベットとカギカッコが並んだ場合はスペースを空けない。 例: 「本来『Debian』という名称は」
GNU Coding Standards - GNU Project - Free Software Foundation
Free Software Foundation last updated July 08, 2021 This manual (standards) is available in the following formats: HTML (368K bytes) - entirely on one web page. HTML - with one web page per node. HTML compressed (88K gzipped characters) - entirely on one web page. HTML compressed (108K gzipped tar file) - with one web page per node. Info document (76K bytes gzipped tar file). ASCII text (232K byte
GitHub - google/styleguide: Style guides for Google-originated open-source projects
Every major open-source project has its own style guide: a set of conventions (sometimes arbitrary) about how to write code for that project. It is much easier to understand a large codebase when all the code in it is in a consistent style. “Style” covers a lot of ground, from “use camelCase for variable names” to “never use global variables” to “never use exceptions.” This project (google/stylegu
Linux カーネル コーディング規約
Linux カーネル コーディング規約 [プレインテキスト版] 原著作者: Linus Torvalds <torvalds at osdl dot org> 翻訳者: Ken Iwamoto <iwamoto dot kn at ncos dot nec dot co dot jp> Toshikazu Nakayama <nakayama dot ts at ncos dot nec dot co dot jp> Nobuo Yoshida <yoshida dot nb at ncos dot nec dot co dot jp> バージョン: 2.6.24 翻訳日時: 2008/03/26 ================================== これは、 linux-2.6.24/Documentation/CodingStyle の和訳 です。 翻訳団体： JF
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Contributor Agreement - Phusion
Primer
Pythonコーディング規約