アカウント名:
パスワード:
>「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。じゃ、読みましょう。適用しましょう。
前提となるドキュメントを読んでいないようなのに、レビューしてもしょうがありません。あなたの時間はたしかに無駄になりますが、レビューした場合あなた以外の人が無駄になる可能性があります。
私はEclipse派ですが、自動生成する際のコーディングスタイルを設定できます。自動生成できない部分に関しては、標準化する際に議論を行い、できるだけ自動化する、または採算が合わないようなら標準化適用外にしてます。
#標準化って生産性よりも、保守性をあげてるんじゃないの?
そういえば、Eclipseのスタイル設定では設定できないスタイルをわざわざ設定してきた意地の悪い発注元があったなあ。ケチをつけてコーディング品質が低いとアヤをかけて、工数単価を事後に値切ったり、仕様変更の追加工数をロハにしようとしたりするひどい発注元でした。
個人的には、識別子の命名規則以外は、レビュー前にindentコマンドで一括整形でいいのではないかと思ってます。
その通りですね.理由なく標準化を守らないのであれば,それはレビューに対する障害でしょう.
標準化されてないコード箇所があれば,そこは「怪しいコード」である可能性が高く,「ここについてフォーカスしてくれ」という指定でもなければ,レビュー時に最も力を入れるべき箇所です.
また, 標準化を無視するのであれば,その理由をレビュー時に明確にすればいいだけです.それは「この標準は生産性を下げる」と問題提起する機会にもなりますし.
同じく、EclipseのプラグインでCheckStyleも使ってます。自動的にチェックしてくれますよね。
Java以外でも使えたような?(言語によるけど)
もし社内独特のコーディング規約が多すぎると反発おきて守ってくれない人多くなるかもしれませんね。
キャメルが規約となっている中で、アンダースコアばっかり使うソースは読みにくいので、そろえるのはある程度意味ありますね。システムハンガリアン+単語の区切りがアンダースコアのソースとかやる気失せる。
eclipseのフォーマッターとfindbugs/checkstyleのルールを開発者全員に配布してた仕事場はコーディング楽だったな。フォーマッターとcheckstyleがコンフリクトして警告が消えなかったりしたのはご愛嬌。(それ以外はダメダメだったので、すでに存在していない組織になってしまったが。)
すべてのクラス名やメソッド名や変数名が英数字3桁+連番であることをツールが自動的にチェックしてくれるから何も問題ないよね!
むしろ、そんな名前こそチェックツールで楽勝ですよ!
保守性も上がりますし、ルールが明確なら地味に生産性も上がります。変に命名で拘って悩む時間が減りますから。(趣味プログラミングだとよく自分も悩む)
あと経験上ですが、明記されたコーディング標準を守らない人は、仕様も守りません。私が関わったプロジェクトの多くは、コーディング標準から明確に外れたものはレビュー実施さえしてもらえない門前払いの扱いです。
# そもそも、基本的なチェックが自動化されて一発で分かりますが
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
コーディング標準はツールが自動的に適用してくれます。 (スコア:5, 参考になる)
>「キャメルケースを使うか、アンダースコアで区切るか」「中かっこの配置」「タブを使うか、スペースを使うか」といったコーディングスタイルのドキュメントが用意されていた。
じゃ、読みましょう。適用しましょう。
前提となるドキュメントを読んでいないようなのに、レビューしてもしょうがありません。
あなたの時間はたしかに無駄になりますが、レビューした場合あなた以外の人が無駄になる可能性があります。
私はEclipse派ですが、自動生成する際のコーディングスタイルを設定できます。
自動生成できない部分に関しては、標準化する際に議論を行い、できるだけ自動化する、または採算が合わないようなら標準化適用外にしてます。
#標準化って生産性よりも、保守性をあげてるんじゃないの?
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:3, 参考になる)
そういえば、Eclipseのスタイル設定では設定できないスタイルをわざわざ設定してきた意地の悪い発注元があったなあ。ケチをつけてコーディング品質が低いとアヤをかけて、工数単価を事後に値切ったり、仕様変更の追加工数をロハにしようとしたりするひどい発注元でした。
個人的には、識別子の命名規則以外は、レビュー前にindentコマンドで一括整形でいいのではないかと思ってます。
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:2)
その通りですね.
理由なく標準化を守らないのであれば,
それはレビューに対する障害でしょう.
標準化されてないコード箇所があれば,
そこは「怪しいコード」である可能性が高く,
「ここについてフォーカスしてくれ」という指定でもなければ,
レビュー時に最も力を入れるべき箇所です.
また, 標準化を無視するのであれば,
その理由をレビュー時に明確にすればいいだけです.
それは「この標準は生産性を下げる」と問題提起する機会にもなりますし.
Re:コーディング標準はツールが自動的に適用してくれます。 (スコア:2)
同じく、EclipseのプラグインでCheckStyleも使ってます。
自動的にチェックしてくれますよね。
Java以外でも使えたような?(言語によるけど)
もし社内独特のコーディング規約が多すぎると
反発おきて守ってくれない人多くなるかもしれませんね。
キャメルが規約となっている中で、アンダースコアばっかり使うソースは読みにくいので、そろえるのはある程度意味ありますね。
システムハンガリアン+単語の区切りがアンダースコアのソースとかやる気失せる。
Re: (スコア:0)
eclipseのフォーマッターとfindbugs/checkstyleのルールを開発者全員に配布してた仕事場はコーディング楽だったな。
フォーマッターとcheckstyleがコンフリクトして警告が消えなかったりしたのはご愛嬌。
(それ以外はダメダメだったので、すでに存在していない組織になってしまったが。)
Re: (スコア:0)
すべてのクラス名やメソッド名や変数名が英数字3桁+連番であることをツールが自動的にチェックしてくれるから何も問題ないよね!
Re: (スコア:0)
むしろ、そんな名前こそチェックツールで楽勝ですよ!
Re: (スコア:0)
保守性も上がりますし、ルールが明確なら地味に生産性も上がります。
変に命名で拘って悩む時間が減りますから。(趣味プログラミングだとよく自分も悩む)
あと経験上ですが、明記されたコーディング標準を守らない人は、仕様も守りません。
私が関わったプロジェクトの多くは、コーディング標準から明確に外れたものはレビュー実施さえ
してもらえない門前払いの扱いです。
# そもそも、基本的なチェックが自動化されて一発で分かりますが