(SampleDTO)testTableDAO.getPrimaryKey(dataDto.getId(),dataDto.getSubId(),dataDto.getStartDate(),dataDetailDto.getLineNo());この長文について「1文が長過ぎるので読みやすくしてくれ」と言われた場合の、あまり好ましくない変更事例は以下になります。dataDetailDto.getLineNo());次も好ましくありません。変数を増やす事で、バグの温床を築いているようなものです。(SampleDTO)testTableDAO.getPrimaryKey(id,subId,startDate,lineNo);プログラムの流れを考慮するなら、こう書くのが望ましいでしょう。);極端に長い場合を除き、1列で記述できるものは半角スペースを利用して1列で記述します。getPrimaryKeyのパラメータが知りたい場合は、F2キーを押して、Eclipseの機能から参照して確かめます。このためにJavadocは必須です。細かいパラメータを並べるのは、数行のプログラムならOKですが、実際にそのような機会はあまり無く、全体を流して読めるこの記述方法が重宝されるのです。タコブネ開発者ブログ上記の要求と解法を簡単に記述すると「引数が多すぎて概要の分かりづらい部分をコメントを利用する事によって解決する(読みやすくする)」と言う事になろうかと思います.バグの温床となるコメントさて,上記の一連の記述の問題点は,「無駄な変数を増やす事によるバグを警戒している割に,無駄なコメントを増やす事によるバグには無頓着である」と言う点です.プログラミングにおけるコメント論にも様々な議論がありますが,コメントを書く際に注意すべき点の一つに,実際のコードを修正した際にコメントの修正を忘れる事によって発生するコードとコメントの不一致,所謂「嘘のコメント」を(できるだけ)なくそうと言うものがあります.よく「コメントをきちんと書け」ということを言われます。そのためか、初心者の書いたソースを見ると、必要以上に大量のコメントが書かれていることがあります。確かに全くコメントのないプログラムには読みにくいものが多いのは確かですが、何でもかんでもコメントをつけるのも同じく間違っています。余分なコメントは、プログラムとコメントの不一致、いわゆる「嘘のコメント」の原因になります。要するに「必要十分」なコメントを書くことが大切なのです。職業としてのプログラミング私は人の書いたコードを読むとき、普通はコメントが書いてあってもそれは見ない。中には、ひどいコードもあり、コメントを見ないと理解不能と言うコードもあるが、それでもコメントは見ないで理解しようとする。コメントを信じたばかりに、ひどい目にあった経験が何度もあるからだ。コメントはプログラマが書く物で、プログラマの文章能力は人による差が激しい。修正変更が繰り返されたようなコードは、たいていはコメントとコードが不一致になっている、またやっている内容を理解する時、コメントを読むよりコードを読むほうが早いことが多いと言うことも多い。ソフトウェアを開発しています。0.5.5βこのブログのこれまでとこれから注目記事スターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。