みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー プログラミング言語(C#，VB，PHP，C/C++，Python，Java，Ruby，JavaScript，Objective-C)やHTMLのコーディングスタンダードを集めたリストを発見しました。日本語訳があるものはできるかぎり探し出して，括弧のなかに併記して補ってあります。微妙に古いのが混じってるかな。Rubyは日本発のコーディング規約がある気がする(まつもとさんの日記を見つけた)。 元記事にPerlのスタイルガイドがなかったんだけど，モダンなPerlスタイルガイドがあったら教えて欲しいです:-)。 PythonにはPEP8というコーディングスタイルガイドがあってよく読まれることは
インデントがあまり深いソースコードは何ともしがたいが、同時にワンライナーにこだわり過ぎるのも問題だ。そのため、多人数で行うプロジェクトや、オープンソース・ソフトウェアのプロジェクトではソースコードのフォーマットが定義されている場合が多い。 うーん、これは読みづらい。問題があっても分かりづらそうだ。 だが慣れるまではインデントの数や改行の入れ方などで間違えてしまうことが多いかもしれない。そうした時に便利なのがソースコードを整形してくれるソフトウェアだ。Webであればサーバサイドのプログラミング言語の他にもCSSやHTML、JavaScriptなど多数の技術が関わってくる。そのような時にはUniversalIndentGUIが便利だ。 今回紹介するオープンソース・ソフトウェアはUniversalIndentGUI、多数の言語に対応したソースコードフォーマッターだ。 UniversalInden
はじめに 「Ruby on Rails: ファイルアップロード機能を作る」の書き直し。変更点は以下の通り。 rails2.2 を使う。 ファイルをデータベースに保存せずにフォルダに入れることにした。 ファイルサイズの上限設定など、validation をわりとまじめにすることにした。 保存に関する作業をモデルに記述することにした。 正直、file_column とか paperclip とか使った方がいいと思うけど、まあ自分で書いたほうが何かと勉強になるので。 環境 Ruby version 1.8.6 (universal-darwin9.0) RubyGems version 1.3.1 Rails version 2.2.2 Active Record version 2.2.2 Action Pack version 2.2.2 Active Resource version 2.
コードリーディングを始めよう Railsコードリーディング～scaffoldのその先へ～（1） 優れたプログラマはコードを書くのと同じくらい、読みこなす。優れたコードを読むことで自身のスキルも上達するのだ
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
趣旨 自動テストは重要だ。この主張に真っ向から異を唱えるひとは多くないだろう。 だが実際には、テストを書くのはいささか面倒だ。特にコントローラのテスト(functional test) に苦手意識を持っている人は多いのではないか。post やら get やらいろんなメソッドが前触れもなく出てくるコントローラのテストは、モデルのテスト(unit test) に比べると「ワケわからん」感が強い。そこで今日は、functional test の仕組みについてしつこく探究してみる。仕組みを理解しないと、コントローラのテストは書きづらいと思うからだ。 functional test の例 簡単なブログエンジンを作るとしよう。 Entry(ブログ記事) というモデルを考えて、それを CRUD するコントローラとビューの足場（scaffold) を作る。 % rails -d sqlite3 blog_
Benjy Weinberger Craig Silverstein Gregory Eitzmann Mark Mentovai Tashana Landray This style guide contains many details that are initially hidden from view. They are marked by the triangle icon, which you see here on your left. Click it now. You should see "Hooray" appear below. Hooray! Now you know you can expand points to get more details. Alternatively, there's an "expand all" at the top o
「Java News.jp（Javaに関する最新ニュース）」の安藤幸央氏が、CoolなプログラミングのためのノウハウやTIPS、筆者の経験などを「Rundown」（駆け足の要点説明）でお届けします。（編集部） プログラミングと検索エンジンは切っても切れない プログラミングと検索エンジンの関係は切っても切り離せないものです。プログラミングに役立つドキュメントやノウハウを探したり、参考になるサンプルプログラムを見つけ出せます。 さらにバグの回避方法を見つけたり、エラーメッセージを検索エンジンで探して、解決方法が見つかることも多いでしょう。良質のソースコードから、的確なアルゴリズムや、思いもしなかったようなコード例を見いだすのも新たな楽しみです。 さて、ここではプログラミングの際に便利に利用できるソースコード専用の検索エンジンをいくつか紹介しましょう。ソースコード専用の検索エンジンを利用した検索
例外ってなに? プログラムを書いていると、try ... catch を書くのがめんどうになったことはありませんか。 たとえば、リスト 1 はファイルを読み込んで単に標準出力に出力を行うプログラムです。これを javac でコンパイルすると、図 1 のようにコンパイルエラーが起きて、コンパイルできません。そこで、「しょうがない、try ... catch を書くか」といって、リスト 2 のように書いたとします。「これでコンパイルはできたから OK」と済ませていませんか。 これでは例外から得ることのできるさまざまな有用な情報を捨ててしまっています。それだけでなく、想定していた動作を行うことができないかもしれません。 逆にいえば、例外を有効に使いこなせるようになれば、プログラムの堅牢性を高めることができ、また保守性も向上させることが可能です。そんな例外の基本から例外を使いこなす
2007年01月19日 俺的コーディングルール SQL編 プロジェクトのコーディングルールがこうでなければいけないとか、他人に強制するわけではないが、自分自身で一貫性の無いコードを書くのは気持ち悪いので、オレオレルールを決めてたりする。大抵は デ・ファクト的なルールに沿う形で書くことが多いのだが、SQL や PL/SQL に関してはなかなかデファクトと呼べるものがないので(あるのか?)、メモ的に書きとめておく。 原則キーワード小文字オブジェクト名大文字カンマは後ろインデントは半角スペースで 2一つの SQL 文でキーワード毎にインデントしない(副問合せ除く) まず、1.2. に付いてなのだが、昔は「キーワード＝大文字」という意味不明な先入観で大文字で書いていた。ただ、それだと PL/SQL のキーワードも大文字、オブジェクト名も大文字で結局ほとんど大文字になってしまうのと、Shift 押す
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
