1人でよいコードを書く - 鳩舎
1人でよいコードを書くのは、3人でよいコードを書くことの3倍難しい。悪いコードを書くときに説得する人間が 1/3 でよいので、つまり自分に向かって『まぁいいじゃん今回は』と言えば事が済む。続けているといつの間にか引き返せないところまできていて、適当に書いた個人プロジェクトは設計的破綻を起こし、コーディング規約もなにもあったもんじゃないという破滅が待っている。 ということで、1人でよいコードを書くために。今回は Rails プロダクトを1人で書くとして。 rubocop コーディング規約と、あまりに長すぎるメソッドやあまりに長いクラス定義などを見つけてくれる。全てに従うと厳しすぎて死ぬので、適宜各チェッカを無効にするのがよい。 僕はこんな感じの設定で使っている。 AllCops: Includes: - Rakefile - Gemfile - config.ru Excludes: - b
TypeScript0.9alphaをNode+Gruntで使うよ
Swift is the best programming language you should learn and make your dream app easily. Swift programming is a powerful yet easy-to-learn coding language created by Apple. It's frequently used for developing iOS and macOS applications, as well as tvOS and watchOS apps. While you can use other languages to create Apple apps, Swift is the preferred language, and it's recommended because its code is
Perl における一般的なコーディング規約について - tokuhirom's blog
http://perldoc.perl.org/perlstyle.htmlhttp://perldoc.jp/docs/perl/5.8.0/perlstyle.podperlstyle.pod にのっているものが公式のスタイルガイドです(Larry 風)。 Larry has his reasons for each of these things, but he doesn't claim that everyone else's mind works the same as his does. このへんが Perl らしさ、というかそういうかんじですね。 Perl Best Practice にのっている Damian style もありますが、これはだいぶ癖がつよいです。 日本では「miyagawa さんのスタイルにあわせておけば DIS られる心配はない」方式のコーディングスタ
コーディング標準は役に立つのか | スラド Slashdotに聞け
私がこれまで勤めた職場はすべて、「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。しかし、アルゴリズムをレビューせずにスペースの使い方を指摘するような人のがいるせいで、コードレビューのために数百時間を無駄にしてきた。実際のところ、このようなコーディング標準を適用することで生産性が上がることを裏付ける資料や研究があるのだろうか。そうでないとしたら、なぜこれらが必要なのだろう。いまどき、決められたコーディング標準を自動的にツールが適用してくれてもよさそうなものだ。
コーディング規約をまとめてみた (Ruby編) - bojovs::blog
色々なところで見かけるコーディング規約を見て意識はしているのですが、 その時の気分で書き方を変えてしまうことが多々あったので、自戒を込めてコーディング規約をまとめてみました。 「なぜこの規約が存在するか」を明確にするために、できる限り理由も併記しています。 ただかなり主観的な部分があるので、あまり意味がないかもしれません…。 「この記事のこの規約は気に入らない。」と思うことがきっとあると思います。 その時はコメント欄などに理由も合わせて書いてくれると嬉しいです。 この記事ではRubyのコーディング規約をまとめています。 近いうちにRailsとCoffeeScriptのコーディング規約もまとめるつもりです。 Rubyのコーディング規約は以下のページを参考にまとめました。 https://github.com/styleguide/ruby https://github.com/bbatsov
JavaScriptのいろいろなコーディングルールをまとめてみた
JavaScriptの書き方はJavaScript自体がある程度自由なためいろいろな書き方ができますが、一貫性を持って書いた方がバグなども発生しにくくなるため、コーディングルールを定めておくのはよいことだと思います(特に複数人の開発の場合) 有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました JavaScript style guide – MDC Docs Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。 多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。 jscsにこのコーディングルールをチェックするプリセットが用意されています。 Google JavaScript Style Guide Google JavaScript Style Guide 和訳 — Goo
いろいろな言語のコーディング規約，スタイルガイドのリスト — TRIVIAL TECHNOLOGIES 2.0
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 みんなのブロックチェーンは，ブロックチェーンの入門書。暗号やハッシュなどを含め，基礎からブロックチェーンの仕組みを学べる書籍です。 いろんな方に「新しい技術を学ぶことの楽しさ」を感じ取ってくれたら著者として嬉しいです:-)。お金は技術的にどのように定義されるのか。 みんなのIoTは，モノのインターネットと呼ばれるIoTの入門書です。IoTの基本について，読者に寄り添って優しく解説しました。裏テーマは一番とっつきやすいPython入門書。サポートページはこちら みんなのPython 第四版は，より分かりやすい入門書を目指し，機械学習やデータサイエンスの章も追加して第三版を大幅に書き換えました。Python 3.6にも華
Google JavaScript Style Guide 和訳 — Google JavaScript Style Guide 和訳 v0.1 documentation
この和訳について¶ この文章は Google JavaScript Style Guide を非公式に和訳したものです. 内容の正確性は保証しません. ライセンスは原文と同じく CC-By 3.0 とします. フィードバックは Issue への登録 , あるいは Kosei Moriyama (@cou929 または cou929 at gmail.com) へ直接お願いします. この和訳のリポジトリは こちら です.
いまさら聞けない「変数の命名規則」 - 基本へ帰ろう
変数の命名規則って名前がついているのですね・・・というのをさっき知ったので・・ほんといまさら聞けない感じです・・ｗ アッパーキャメルケース (UCC)、またはパスカルケース(PascalCase)（Pascal記法） キャメルケース - Wikipedia 複合語の先頭を、大文字で書き始める。 例 ： CamelCase ローワーキャメルケース (LCC)、または単にキャメルケース キャメルケース - Wikipedia 複合語の先頭を、小文字で書き始める。 例 ： camelCase アプリケーションハンガリアン（ハンガリアン記法） ハンガリアン記法 - Wikipedia アプリケーション ハンガリアンは、間違えたコードを間違えて見えるようにする記法である。 たとえば、論理座標にRelative Positionのrp、絶対座標にAbsolute Positionのapというプレフィッ
Google Python スタイルガイド
概要¶ これは Google Python Style Guide Revision 2.29 を日本語に訳したものです。 本家ガイドは CC-By 3.0 ライセンス の基で公開されています。また、本ガイドも同ライセンスを継承します。 本家ガイドの著者は以下の通りです。 Amit Patel Antoine Picard Eugene Jhong Jeremy Hylton Matt Smart Mike Shields また、本ガイドの翻訳者は以下の通りです。 Kosei Kitahara 本ガイドに誤植、誤訳があった場合は issue で教えてください。 その他本ガイドに関する問い合わせは、サイト最下部に記載のメールアドレスか @Surgo にお願いします。 はじめに¶ Python は Google で使われている主要なスクリプト言語です。 このスタイルガイドは Python によ
頑健なJavaプログラムの書き方
日頃より、アレスネットをご愛顧いただきまして誠にありがとうございます。 「ホームページサービス」のサービス提供は2016年1月31日をもちまして終了させていただきました。 これまで長らくご利用いただき、誠にありがとうございました。 今後も、皆様によりよいサービスをご提供させていただけるよう、サービス品質向上に努めて参りますので、何卒、ご理解いただけますようお願 い申し上げます。 ＜アレスネットをご契約のお客様へ＞ 後継サービスとして「userwebサービス」を提供させていただいております。 詳しくは、以下のリンクをご参照ください。 ▼「userwebサービス」のご案内 http://www.ejworks.info/userhp/alles/index.html 今後ともアレスネットをご愛顧いただけますようお願い申し上げます。 株式会社イージェーワークス アレスネット カスタマーサポート
バグを生まないコーディング法、10個の規則でソフト開発を効率化(1/3) ― EE Times Japan
ソフトウエア開発にはバグがつきものだ。ただし、バグの発生を最小限に食い止める方法がある。コーディング規則を適用してコードを記述することだ。バグが発生してからそれを発見し、修正するという通常の開発手順に比べて、簡単に、しかもコストをかけずにバグをつぶせる。 ここでは、ZigBeeを利用したセキュリティ・システムから医療機器にわたる筆者の組み込みソフトウエア開発の経験から得た、バグをなるべく発生させないコーディング規則を紹介する。 なぜコーディング規則が必要か コーディング規則は、ソフトウエア開発者に対して、コードを記述する上での規則をまとめたものである。英語のライティング教本として著名な「The Elements of Style」（William Strunk Jr.、E. B. White著）の、プログラミング言語版のようなものだ。 組み込みソフトウエアにも、きれいで、正しく、簡
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ページを開く
