Q&A
＞ if(condition) {
＞ statements;
＞ }
は、Oracle？のコーディング標準規約から、そのまま拾ってきて、
切り貼りしたものです。
ということは、Oracleは、あてにならないということですね。
Java Docも、Oracleでは、Java Doc独自の@キーワードを一切使わずに、
コメントだけにしていますし。
if文の書き方承知しました。これで、また規約の材料が揃った。
ちなみに、elseは、下記が正解とのことです。
} else {
追記：2015/07/28 17:16
Google Java Style
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
のコーディング規約が、すばらしい！！
ごく一般？で、見やすい。
（また、一般的と書くと、会社により違うとか言われますが、一般的です）
私は、２箇所ほど、書き方を直せば、全く同じコーディングになるので、
採用決定です。
これで、私も、世間と同じ記述になれそうです。
よそに見られても恥ずかしくない、ソースに。
※元々、私の書き方は、品質重視と後継者の見易さ重視だったのが、幸いしました。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
追記：2015/07/28 14:12
本件はあきらめました。全員が否定されている感じなので、無理と判断。
結局、標準なんてなくて、
・変数にプリフィックスをつけるのが一番まちがいなくわかりやすいとか、
・クラスのメンバーの頭には、m_ を付けるとみやすいとか。
・クラス名は、Class～ではじめるとか。
・ファイル名は、クラス名と同じにするとか。
会社毎に、色々、規約があるみたいですが、上記で行きます。
※しばらく、この質問サイトを空けておきます。
これがよいというのをお持ちの方がいれば、おしえてください。
eclipsで、JSPとJAVAをコーディングしています。
下記、コーディング規約についてご意見、ご指摘ください。
世間一般で、これが世の中の標準です。
といえるコーディング規約を求めています。
私の求めている「標準」とは、
現在主流で、見易さ重視＝バグ率低減＝後継者の負担軽減を
目標としています。
※コーディング規約の標準といっても、
企業や人により、バラバラですが、
尚、大手企業のマニュアルをほぼすべて参照し、
参考サイトも可能な限り参照した結果、
独自路線の企業やサイトは、無視し、
あくまでも、一般的に、これだろう？とう私の判断で
まとめたものです。
※私自身、今の書き方をかなり否定されていますが、
日本の標準で（企業それぞれ、人それぞれ、自由ですが、そんな独自路線は無視）
コードを書きたいのです。
※見るも無残な、逆に、手間がかかり読みにくくしている、大手の企業もありました。
=================================
■コメント
私の、「Java Docの書き方」参照。
■ファイル
・クラス名と同じ。
・１ファイル、１クラス。
・先頭大文字．あとは区切りを大文字．アンダーバーを使わない。
■クラス
・先頭文字は大文字で、単語毎に先頭の文字を大文字で接続したもの。
例）FileAccess
・Classという単語は、つけない。・・・個人的には、最後か先頭につけたい。
■抽象クラス
・抽象クラス名は、，Abstract から始まりサブクラス名を連想させる名前を付ける。
■定数
・大文字をアンダーバーででつないだもの。
例）MAX_INDEX_COUNT
■メソッド
・変数の型を示すプリフィックス（プレフィックス）は、使わない。
・名詞に含まれる単語は省略しない。
・動詞で表す単語から始める。
例）public void readText(); ・・・ Java 標準に準拠。
・最初小文字で，あとは区切りを大文字。
例）insertCarType
■属性の取得メソッド
・頭に小文字で、処理を示し、続けて、単語を先頭大文字で記述。
・名詞に含まれる単語は省略しない。
・int getCarType() // JavaBeans でプロパティとして扱える(推奨)
・boolean isEnabled() // JavaBeans でプロパティとして扱える(推奨)
・void setCarType(int carType) // JavaBeans でプロパティとして扱える(推奨)
・変数の型を示すプリフィックス（プレフィックス）は、入れない。
■ファイル
・エンコーディングをUTF-8固定とする。
■桁数
・最大100文字。
■内部クラス
・使用禁止。
■例外クラス
・"Exception"を接尾に付ける。
class TextException extends Exception
■属性を取得・設定するメソッドgetter/setter の命名規則
・public void setAttribute(int attribute) {} Java 標準に準拠。
・public int getAttribute() {} Java 標準に準拠。
・public void setVisible(boolean visible) {} Java 標準に準拠。
・public boolean isVisible() {} Java 標準に準拠。
■処理のネスト
・1メソッド内で、最大 3 階層まで。
■ループ変数
・i, j, kなど一文字変数を用いない。
■インデント
・タブを使用。
■ソースコード
・本体部部分は、try～catchの中に書く。
例）
try {
本文
} catch (SQLException expected) {
例外対応
}
catch (Exception expected) {
例外対応
}
finaly {
対応
}
■if文は、1行でも、大かっこでくくる。
if(condition) {
statements;
}
参考：
Oracleの場合、
■クラス、関数のコメントには、Java Docのキーを一切使わない。
/*
- Classname
- Version information
- Date
- Copyright notice
*/
■文中のコメントは、
・/* Handle the condition. */を使い、// コメント を使わない。
・変数定義のコメントには、 // コメント を使う
以上
回答9件
0
世間一般で、これが世の中の標準です。
といえるコーディング規約を求めています。
Google Java Style
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
上のコーディング規約が「（事実上の）標準」なのかは
議論もあるでしょうが、有名な規約ではあるでしょう。
一般的に、これだろう？とう私の判断で まとめたものです。
質問者様に根本的な誤解が、ふたつあると思います。
ひとつ目は、参考元の規約がいくら大手だろうと有名だろうと、
もし個人の判断でまとめて（部分的に変更して）しまうなら、
それは個人の「独自規約」であって、世間の「標準規約」ではありません。
規約は足して2で割ったらまったく別のものになります。
日本の標準で（企業それぞれ、人それぞれ、自由ですが、そんな独自路線は無視）
コードを書きたいのです。
規約は企業によってバラバラなのが実態なので、
標準を求めるお気持ちは分からなくもありません。
しかし、ふたつ目として、コーディング規約というのは、
ひとつの企業や開発チームの中で統一されていることが、
重要なことなのです。世間一般の標準であることよりも。
会社に属して仕事をする場合は基本的に、
その会社なりチームなりが定めた規約を
そのまま受け入れるしかないと思います。
ひとりで「この規約が世界標準だ！」といっても、まず受け入れられないと思います。
もちろん、質問者様が開発チームのリーダーなどになったときに自ら採用するか、
もしくは提案や説得をしてチームに採用してもらうか、公開して世の中に流行らせるか、
あるいは個人開発者になって好きなように書くか、といった可能性もありますが。
投稿2015/07/28 01:22
総合スコア5592
0
私は基本的には、Javaを作ったSun Microsystems社が発表したルールを基本とすべきだと思います。
Code Conventions for the Java Programming Language: Contents
特に命名ルールの
・変数名・メソッド名はローワーキャメルケース
・クラス名はアッパーキャメルケース
・定数名は大文字のスネークケース
など、今では絶対的とも言えるこれらのルールはここで確立されたといっても過言ではないでしょう。多くのルールが根源的にはこのSunのルールを独自に変更しているといえます。
あとは自分の好きなように、独自に追加・変更をしていけばいいと思います。
しかし
■ループ変数 ・i, j, kなど一文字変数を用いない。
これはいくらなんでもありえないでしょう。こんな変なルールを使ってる企業があったのですか？あったとしても絶対にまねしないほうがいいルールでしょう。
・変数にプリフィックスをつけるのが一番まちがいなくわかりやすいとか、
・クラスのメンバーの頭には、m_ を付けるとみやすいとか。
・クラス名は、Class～ではじめるとか。
それはハンガリアン記法といわれるスタイルで、昔VBとかで使われていました。Javaでそれをやると素人だと思われます。Java以外の言語が長かった人や古い体質の会社だとそういうルールの場合もありますが、やめたほうがいいでしょう。
あとSunのルールの8章、空白はよく読んだほうがいいと思います。
キーワードのあとに空白を入れるのは、Javaに限らず他の言語でも広く共通した標準ルールです。
if (condition) { // ○ if(condition) { // ×
投稿2015/07/28 07:07
総合スコア902
「私は基本的には、Javaを作ったSun Microsystems社が発表したルールを基本とすべきだと思います」、何度か見ていますが、どうみても、普通じゃないです。
Java Docも書かなかったり、書き方が超特殊だったり(ecilpsでエラーがでる)。
私は、Javaを作っているはしっていますが、ここの会社の書き方は、
一般には、受け入れられないと感じています。
※まだ全部みていませんが。
>Oracle？のコーディング標準規約から、そのまま拾ってきて、切り貼りしたものです。
あなたの言う「Oracle？のコーディング標準規約」が何を指すのが具体的には分かりませんが、おそらくは実際にはOracleと関係ないものをあなたが「Oracleだ」と誤認しているだけではないかと思います。そしてあなたが「すばらしい」と言い出した「Google Java Style」の4.6.2でも同じことが書いてあります。このルールはJavaでは常識ですし、他の言語でも取り入れられていることが多いです。
> 書き方が超特殊だったり(ecilpsでエラーがでる)。
あなたが何を根拠に「超特殊」と判断してしまったのか分かりませんし、あなたが使うとなぜエラーになるのかもよく分かりません。普通に使えばエラーにはならないはずです。単にJavaのコードではない部分までコピーしてしまっているだけではないでしょうか？
そして実際には、Sunのスタイルはあなたが「すばらしい」と言い出した「Google Java Style」と全般的にほぼ同じ内容です。「超特殊」であるはずがありませんよ。
> Java Docも書かなかったり、
まず、ちゃんと読んで理解しましょうとしかいえませんが…。3章に書いてあるのはファイルコメントです。Java Docのコメントに関しては「5.2 Documentation Comments」を読みましょう。
0
会社の人には言っても仕方がないかも知れませんが、
Javaの標準と会社のルールとは分けて考えてください。
Javaのプロダクトを多く手掛けている、
旧SunやOracle、Google、IBM各社あたりが挙げているコーディング規約の共通点は、
ほぼJavaの業界標準と言っても過言ではないと私は思います。
なので、
結局、標準なんてなくて、
というのは違うかな。
標準はあるけど、その会社では採用していない、というだけかと。
採用するしないは自由です。
変数にプリフィックスをつけるのが一番まちがいなくわかりやすいとか、
クラスのメンバーの頭には、m_ を付けるとみやすいとか。
JavaやJSPプログラムの変数名のプリフィックスは、つけない時代？(13325)｜teratailにも書きましたが、Javaではプリフィックスをつける習慣は元々ない認識です。
すべてのフィールドにgetter,setterを持たせた方がまだJava標準に近いかも知れません。
クラス名は、Class～ではじめるとか
ほとんどがクラスなのになぜClassをつける必要があるのでしょう。
interfaceやenumだけつけるならまだ分かりますが。
つけないのが普通なのは、標準ライブラリーのJavadocを見れば一目瞭然です。
ファイル名は、クラス名と同じにする
publicクラスに限れば、これはコーディング規約ではなく言語の規約です。
私の係っているシステムは古臭いやり方ではありますが、その割にコーディング規約は業界標準に準拠していますよ。
投稿2015/07/28 06:01
総合スコア9390
なるほど、私がこうやる！！と書いて正解でした。
やっぱり、規約があるんじゃないですか？
全員ではないですが、会社で決められたものや、リーダーが決めたもので統一すれば、それでよい！！ との回答が多かったのですが、
私が、あえて、変な書き方で行く！！ と宣言すると、その書き方は、違う！！と
ご指摘がいただけました。
ということは、やはり、標準っぽい規約っぽいものがあるから、
私の書き方をしてきできたんだと思います。
このご回答を導き出したかったのです。これで、４，５個の書き方が決まりました。
というより、クラス名のつけた方、変数名のつけ方、など、こうやって、
みなさんのご指摘やご意見をひきだしていければ、おのずと、
よりよい、一般的なものに絞られると、予測しました。
MioAsakuraさんの過去の質問をいくつか見ていたので、このような回答とさせていただきました。
参考になったのでしたら良かったです。
ちなみに、一般論の範囲では、LLmanさんの方針に概ね同意です。
私が書いているのも事実上の標準（デファクト・スタンダード）のことを言っています。
蛇足になりますが、ちょっとだけ補足。
ネーミングルールは、さらに突き詰めると、
たとえばプリフィックスを付けないと分からないようなコードは避けるべき、という方針につながります。
ここまで行くと、コーディングルールだけでは語り尽くせないので、Javaの良書を読んでみることをおすすめします。
(1冊だけ挙げるならEffective Javaですが、初心者の方にはすこし難しいです。）
ありがとうございます。勉強や、調査が好きなので、その本は、ちょっと立ち見してみてみます。
0
ひとことでいうとどこのでもいいから有りモノをそのまま採用することをおすすめします。
私のコーディング規約の考えかた
- 独自ルールであっても規約が無いより統一された書き方があったほうが可読性は上がる
- 独自ルールや一般的でないルールは、途中で入った人にとってはしばらくは可読性が低い
- 一般的なルールの方が、新人にとってもなじみやすく他でも応用がし易い
- 言語仕様の変化などで、無用となったルールでも制定した意図が不明であれば、変更できないことがある
- 特定の記法の利用を制限すべきではない。それはコードレビューで都度議論すべき内容
- 規約は、可読性を上げることにより、生産性やミスを減らすこと。あるべき論をすると生産性が落ちる
以上から、次の方法をおすすめします。
- 独自で作るのは諦め、有名で、メンテが継続しているオープンな規約を採用する
- バージョンアップに追随すること
- 独自な要件で設定する規約には、制定した理由と経緯を明らかにすること
- 定期的なメンテ
投稿2015/07/28 04:40
総合スコア2883
とてもよいお考えの方です。賛成するものばかりで、勉強にもなります。
当然作るときの、バグ発生率低減などもありますが、
後継人がすぐに、パッと見で、違和感がないことがとても大切だと思います。
＝一般的で、標準的な記述方法。
そうですね。規約の効果はいろいろありますが、可読性の全体最適がもたらすものだと考えています。
余談ですが、overrideや継承に関する方針などは、可読性とは関係ないので規約の外にするべきと考えています。こういうのはアーキテクチャ設計でやるべきだと思う。
0
JavaDocの時と同じような回答ですが、Java本体の規約がとりあえずの標準のようなものだと思います。
個人的にはですが、eclipse使っているならば、CheckStyle導入してみてはいかがでしょうか？
デフォルトでSunの規約だったがついてきた気がします。（うろ覚えですが）
自分の場合、そこからプロジェクトに応じて増減を定義して導入した事が多かったです
投稿2015/07/28 01:50
総合スコア148
ありがとうございます。さっそく、CheckStyleを使ってみました。
Java Doc自体の存在が、まず違反で全部引っかかってしまいました。
コーディング標準化は、むずかしい。。。
CheckStyleのルールは変更できるので、設定ファイルのXMLファイルを使いやすいように編集して、チーム内で共有するといいと思います。
最初は大変ですけど、設定ファイルさえ作り込んでしまえば楽だと思います。
0
※コーディング規約の標準といっても、
企業や人により、バラバラですが、
仰る通り企業によってバラバラです。
私自身出向で他企業に行くこともありましたが、その会社のコーディング規約を見て、それに則って開発をしていました。
MioAsakura様が何を求めているかがイマイチ分からないのでこれ以上は申し上げられませんが、とりあえず企業にお勤めであればその企業のコーディング規約を皆で決めた方がよいでしょう。
投稿2015/07/27 23:59
総合スコア634
世間一般で、これが世の中の標準です。
といえるコーディング規約を求めています。
標準なんてものがあったらおそらく皆こぞって使うでしょうね…。
経験則ですが、コーディング規約を細かく決めるより、ソースコードの中にしっかりコメントを残すことの方が大事かと思います。
「ここはこういう処理をしているんだよ」ということがコメントから読み取れれば、多少規約から外れていても意味は分かりますので。
私のコードは大抵コメントまみれです(笑)
コメントは、丁寧に書いています。
コーディングは、大半がエラー対応処理、次にコメント、最後に本筋のコードとなる量です。
0
ベストアンサー
Google Java Style
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
のコーディング規約が、すばらしい！！
できまったので、解決とします。
投稿2015/07/30 09:48
退会済みユーザー
総合スコア0
だったらLLManさんをベストアンサーとしてください。
紹介したの彼だし・・・
0
設定より規約という概念があります。
ruby あたりで発生した概念だったと思いますが、java でも採用している場合があります。
設定は環境に左右されるので、其れなりの工夫が必要ですが、私も概ね賛成で、割と積極的に採用している環境です。
但し、採用しているフレームワークが、この概念を採用している場合、独自の規約と不整合を起こす場合があります。
seasar2 、とくにsastuts あたりではクラス名などにこの概念が適用されています。
こういったこともありますので、ケースバイケースで考える必要があると思います。
投稿2015/07/28 06:55
総合スコア209
そうですね、ケースバイケース使い安いいい言葉です。
今回は、Javaなので、Javaのケースのコーディング標準（＝世間一般に出しても、すぐ読め、なんだこの書き方は？と言われない、恥ずかしくない書き方）を知りたいです。
設定より規約という概念は、恥ずかしいとか人間的なものではなくて、システムも規約に従って振る舞うという、積極的なアプローチです。
sastruts ではActionというsuffixがクラス名にある場合は、Actionとして振る舞いますし、アノテーションとしてのルールもあります。
人間もシステムも、規約をルールとして等しく解釈します。
このため、フレームワークが只の部品の集まりではなく、厳密なものとして振る舞います。
規約そって作らなければ、正しく動かないので、自然と粒の揃った資材が揃いますし、後々の改修でも、規約は守られることになります。
一枚の紙っぺらではなく、仕掛けとして実現するものなので、工夫は必要ですが、強力なものですよ。
0
私も過去にコーディング規約について調べた経験があります。
標準の定義はやはり難しいです。
例えばISOのように国際基準があれば別ですがコーディング規約には確定したものは見つかりませんでした。
そのため多くの企業が独自にコーディング規約を作成されている理由だと思います。
また恐らくにはなりますが、JSPという単語が出てくるということはWEBサービス系の開発をされる方なのだと思います。
そこではいろいろなフレームワークやライブラリを採用することになり、そのフレームワークに沿ってコードを書くと良くあるコーディング規約通りにならない場合も多々あると思います。
コーディング規約の話とは少し逸れてしまいますが、極端な話になるとコメントなども全て英語で書くことになってしまいますし、場合によっては命名規則もローマ字表記は禁止などとなってくると【見易さ重視】が成立しなくなってしまいます。
気持ちはわかりますが、多くのものから各メンバーにあった規約があってある一定の期間がたった時に見直すことを繰り返すことになるのではないでしょうか。
また極端な独自規約を追加しない限りは問題ないと思います。
求められている回答にはなりませんでしたが、参考になれば幸いです。
投稿2015/07/28 01:59
総合スコア1336
ということは、時流に乗って、その言語毎に、一般的なものを使うと、無難ということですね。
はい、私はそう思います。
全てにおいて、適度なバランスを維持出来れば良いのですが規約が多すぎると開発効率が低下して、自由にさせれば保守出来なくなりますし。
大変だと思いますが、あまり思い詰めずに楽しんで下さい。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
退会済みユーザー
2015/07/28 04:33
2015/07/28 06:05 編集
退会済みユーザー
2015/07/28 08:03
退会済みユーザー
2015/07/28 08:14