ちゃんとした C# プログラムを書けるようになる実践的な方法~ Visual Studio を使った 高品質・低コスト・保守性の高い開発慎一 古賀
1、2年前、「技術書を読みながら考えたことを、クローズドなTwitterアカウントで延々つぶやく」という根暗なことを定期的にやっていました。ふと、あれをブログでやるとどんな感じになるんだろうと思ったので、実験的にやってみます。 『Code Reading―オープンソースから学ぶソフトウェア開発技法』の第7章「コーディング標準と規約」を読んで、考えたことや分からないことをダラダラと書きます。本の内容のまとめではありません。 まとめではないといいつつ、7章の冒頭で挙げられている有名な3つのコーディング規約に、一応リンクしておきます。 GNUコーディング標準 http://www.gnu.org/prep/standards/ BSDスタイルガイド FreeBSDのターミナルで「man 9 style」 http://www.freebsd.org/cgi/man.cgi?query=style
AspectJというと、メソッドなどに処理を織り込むAOPのイメージが強いと思いますが、AJDTというeclipseのプラグインを使うと強力なコード検証ツールとして利用できることは意外と知られていないようです。(AJDTはSpring Tool Suiteには最初から内蔵されています。) 実際、 コントローラークラスのメソッド内でフィールドの設定を行う サービス層を経由せずに直接DAOを呼び出している 日付オブジェクトを直接newしている*1 などの箇所をコンパイル時に検証して、警告やエラーとして検出できます。 たとえば、Spring MVCのコントローラークラスのメソッド内でフィールドの設定を行っている箇所を警告として検出するには以下のようなアスペクトを書くだけです。 package sample.mvc; import org.springframework.stereotype.Co
この和訳について¶ この文章は Google JavaScript Style Guide を非公式に和訳したものです. 内容の正確性は保証しません. ライセンスは原文と同じく CC-By 3.0 とします. フィードバックは Issue への登録 , あるいは Kosei Moriyama (@cou929 または cou929 at gmail.com) へ直接お願いします. この和訳のリポジトリは こちら です.
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
皆さん、システム開発において、コーディング規約は利用していますか? プログラムの質を向上させるには、開発者としてのマナーである「コーディング規約」は 欠かせません。 ただ、EclipseといったIDEやJava言語自体の発展もあり、ひと昔前の規約は、 形骸化してしまっていることも多いのではないでしょうか? そこで、当社では、社内で2000年より作成・改版を行ってきたJavaコーディング規約を 公開することにしました。 このコーディング規約は、開発者自身の経験、および、最近のJavaの動向を踏まえ、 現場で本当に役に立つノウハウをまとめたものです。 そのため、Eclipseで自動でフォーマットできるような簡単なスタイルの規約については 記述を省略し、より重要となるコーディングテクニックや考え方について記述しています。 これからJavaを学ぶ新人の方はもちろん、開発者の技術力向上に繋がる内容に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く