Q&A
>底無し沼です。
ここの表現難しいですね。
線引きというか。
「現場のコードレビューで指摘を受けない」ものを目指すか
「競技プログラミングのように最大効率を追い求めた」ものを目指すか
「初心者でも読みやすく無駄のない」ものを目指すか
「自己満足」で終わらせるか
コードを提示、提出する相手によっても違ってきますね。
だから「きれい」「はやい」「うまい」という個人的感覚に依存しすぎるワードは嫌われる傾向にあります。
本とネットだけでJavaを少し学んできた初心者です。
プログラムを合計4000行ほど書いたときに、いつも思うのですが、これまでのプログラムが
このような仕組みで良かったのかな
とか、
このクラスの分け方で良かったのかな
とか、
このアルゴリズムで良かったのかな
とか思ってしまいます。そうして、こっちの方がいいかも、と根こそぎ変更して結局バグやエラーがなくちゃんと動くけれども、クラスが相互依存になっていたりと汚いプログラムになってしまいます。
良いコードが書けるようなアドバイスや、正しいコードを閲覧できるようなサイトが御座いましたら、ご提示いただけると幸いです。
回答10件
0
まず基本ですが、「リーダブルコード」を読むことをおすすめします。
リーダブルコード――より良いコードを書くためのシンプルで実践的なテクニック
https://www.oreilly.co.jp/books/9784873115658/
また、クラス設計については、「デザインパターン」を学ぶと良いと思います。
「java デザインパターン」で検索すれば、たくさん解説サイトが見つかります。
オープンソースのコードであれば、GitHub で公開されていますので、自分の知っているライブラリのコードを読んで参考にするのも良いですし、自分の書いたコードを他の人にレビューしてもらうのも良いと思います。
他の人の書いたコードを読んで、良いところを自分のコードに取り入れるというのを繰り返していけば、徐々に良くなっていくと思います。
投稿2019/11/18 23:16
総合スコア6500
0
ベストアンサー
きれいなコードをかけるようになるにはどうすればいいですか
むしろ、「綺麗なコードを書きたい！！」と思えること自体、素晴らしいことだと思います。
文法あっているけど、汚いコードの定義とは何か、
個人的には
- 「非効率」のコード
- インデント グチャグチャ
- 無駄に改行しない・改行しすぎ
だと思っています。
まずは、自分の書きたいコードが書きたいように書けてから美しさ・綺麗さというものを追求していけば良いと思います。
意外と、自分なりのコードの美しさ・綺麗さを求めていくなら底無し沼です。
頑張ってください。
投稿2019/11/19 01:18
編集2019/11/19 02:39
総合スコア10429
表現を修正しました。
あ、ごめんなさい。不適当とか不適切というわけじゃなく、「やろうと思えばいくらでもどこまでもできる」というのを伝えたいのは分かるのでそれはそれで良くて、「決めるのは誰か」という話になったときにこの質問者はどう判断するんだろうというところですね。
いえ、m.ts10806さんのご指摘を元に再度読み直したところ、自分が伝えたいことを的確に伝えられないような気がしたので修正しました。
ご指摘ありがとうございます。
業務でプログラミングやってきて長いですが「読みやすいコードだな」と思うことはあっても「きれいだな」「美しい」という感覚にはならないですよね…。
なんというか「汚い」はあるので、「汚いと思わない」＝「きれい」ってことでいいのかな
個人的にはインデントさえ揃っていれば「綺麗なコード」です。
ただ、「美しいコード」は効率等の概念も含めて考えています。
ただ、ここら辺は主観的なものが大きいと思うので「個々の解釈による」というのが正しいですね
ですね。
雑談ぽくなってしまいますが、
注意しなきゃいけないのは「キレイだ！」と感じたコードだけ真似しても自分の身にはつかないということですね。
意図や考え方、考慮し尽くされたロジックまで理解できないと意味がない。要件によって使い分けも必要。そういった意味でも「底無し沼」ですね。
コードの見た目ばかり追求してちゃんと要件満たしてなきゃ使う人からすると単なるバグですしね。
上のコメントに「いいね」つけたいです。
気持ちだけ受け取っておきます-人-
雑談に便乗させてもらいますが、「きれいなコード」って、往々にして単なる「結果」なのだと思うのですよね。きれいなコードを書くことを目的にするのではなく、過程を大事にしていると結果的にきれいなコードになる。
それが1番重要ですよね
プログラミングは自分だけでやっているので、まずは、「自分が理解できる」を「キレイなコード」として書いていこうと思いました。今まで、大げさに言えば、世界中の人が理解できるコードを目指していて、ずっと思い悩んできましたが、それは、そんなに重要ではないのだと気が付きました。（良いことであるのには変わりないと思いますが）たくさんの、コメントをしていただき、ありがとうございました。
重要です。三か月後の自分は他人ですから。
わかりました。明日、１週間後、１ヶ月後の自分が、変わるように頑張ってみます。
それも大切ですが、私の言った意味は、自分のコードを三か月後に見ると、他人の書いた物と何らかわりないということです。「本当にこれ自分が書いたのか？」と思うこともしばしばですから、「自分にさえわかればいいや」というのでは失敗します。
既にご自分で結論を得ているので良いと思いますが、「大げさに言えば、世界中の人が理解できるコード」も実際はあり得ないので、重要でないということには同意です。実装コードの背景にある様々な理論が高度であれば万人に理解することはもちろん無理ですし、初心者にとってと、その言語に精通したベテランにとっての簡単／理解できるコードは違います。例えばデザインパターンを知っている人にとってはそれを適用したコードは理解するに簡単なものですが、知らない人にとっては難解となります。
carnage0216 さんが見てもわかるコードを書く必要はありませんが、第三者の目を意識して書くことは不可欠です。その時に自分が知っていることを三か月後にも知っている保証などありません。そのコードしか書かないなら話は別ですが。
質問したり、もっと調べたりして、新しい書き方、考え方などを取り入れていこうと思います。
0
いきなり長文コードをキレイに書くのはどんな熟練者でも無理です。
しかし、先にロジックを机上で考えたり、部品を先に作っておくなどの工夫により整理されたコードを書くことはできます。
思うがまま書いていき結果的に4000行になってしまうことと
おおよそ4000行になるであろうと想定してから書き始めるのでは
コードの整理具合ですとか見栄えは大きく変わってきます。
作文だったり大掃除と考え方は似てます。
ゴールを意識して作業できているかどうかですね。
それなりに経験のいる作業なので、いきなり全てやろうとしなくて良いです。
今のコードを幾つかグループに分類してリファクタリングしていくと
見えてくることもあるでしょう。
それにひとつのことを実現するための手段はひとつではないので
「絶対的に正しいコード」は存在しません。
要件通り動くのが「正しいコード」です。
単に短くなればいいというわけではなく「できる範囲で過不足なくしっかり書くこと」が大事です。
追記-----
「コツ」の話をすると「数週間、数ヶ月経って読んだときに直さなくても良いと感じる」のが
「いいコード」と言えるかもしれません。
そこに対してあえてリファクタリングを施していくのも技術力の向上には役に立ちます。
(ので、「美しい」とか「キレイ」とかを追求するのはまた違うベクトルの話なのかなと思ってます)
投稿2019/11/18 22:52
編集2019/11/19 02:52総合スコア80850
回答いただきありがとうございました。
まずは、要件通りに動く「正しいコード」を中心に書いていこうと思います。それから何回もコードを書いて（一つのアプリケーションを書くのを一回として）経験で学んでいこうと思いました。
リファクタリングについてですが、やろうと思っても復習みたいなもので、つい後回しになってしまいます。どれくらいの頻度でリファクタリングをすると良いでしょうか。現在は、一通り完成したらしようと思っています。
「正しいコード」と表現を続けてしまうと残るのは「正しいコード」だけとなってしまうので、あくまで「きちんと動くコード」を主眼に置いてください。
>一つのアプリケーションを書くのを一回として
どれくらいの頻度でリファクタリングをすると良いでしょうか。現在は、一通り完成したらしようと思っています。
はじめから「アプリケーション」とするより、「部品単位」にしてはどうでしょうか。
ターゲットが大きければ大きいほど面倒になって後回しにしてしまいます。
アプリケーションも基本は部品の集合体です。
もちろんコード全体に整合性や統一性は必要ですが、現場では何人もが部品をつくって組み合わせるので、画面単位、機能単位でどうしても個々の質に差は出てきます。
部品、機能単位で見た方が忘れずできますよ。それぞれの部品の見直しが終われば全体も見通しやすくなるので、はかどりやすくなります。
0
気になるコードを差し支えない範囲で質問に提示できると改善案が出てくるのでは？
とりあえず、コーディング・ルール
Google Java Style Guide
Javaコーディング規約 Future Enterprise Coding Standards
Java コーディング標準 オブジェクト倶楽部
Javaコーディング規約 qiita
辺りを参考にしてみては？
投稿2019/11/18 22:18
編集2019/11/18 22:41
総合スコア16415
0
きれいなコードを書くにはきれいなアルゴリズムとか、論理構造が必要です。
コードは論理構造をプログラム言語で表現したものですから、コードだけを旨く書こうとしても無理です。
対象をきれいな論理構造に分析する。それが一番重要。
その後で、プログラム言語に用意されている機能をうまく使う、でしょうか。
投稿2019/11/19 01:58
総合スコア711
0
きれいなコードをかけるようになるにはどうすればいいですか
質問にある「きれい」って言葉が曖昧すぎだと思います。
「clean」なのか「beautiful」なのかで回答は大きく変わります。
いずれも先人の知恵に学ぶべきものですが、学ぶ方向性は大きく変わります。
「beautiful」なのであれば、数学や言語の仕様に関して学ぶ必要があります。
「clean」なのであれば、「リーダブルコード」「デザインパターン」かと。
例えば以下のコード
ruby
11.upto(100){|n|puts'FizzBuzz 2'[i=n**4%-15,i+13]||n}
めちゃくちゃ技巧的と思いますが、メンテナンス性が良いとは思いません。
多分、質問自体は「clean」を目指しているのではないかと思いますが、タグに「アルゴリズム」が入っているあたり、「beautiful」が混じっているように感じます。
ごっちゃになった状態では先に進めないので目指す先を整理したほうが良いです。
参考に Clean Code のエッセンスを貼っておきます。
https://qiita.com/kyammy/items/63db981d35886ee5806f
ビューティフルコードは混乱させるので紹介しません(有名なビューティフルコードは混じってますｗ)
投稿2019/11/20 22:37
退会済みユーザー
総合スコア0
回答ありがとうございます。
同じキレイでも、「clean」と「beautiful」があったりと、捉え方がたくさんあるのは気づきませんでした。しかし、cleanとbeautifulの違いがイマイチわかりません。
clean・・・全体的に読みやすく、修正しやすい(可読的)
beautiful・・・局所的に頭を使って、論理的にスタイリッシュである(能率的)
というような違いでよろしいでしょうか
微妙にずれているのですが端的に説明できません。
＊まぁ、もともと定義できるものではないので、正解不正解のあるものではないですが。
clean code は客観性が強い分、整理がしやすいので、そちらを目指すのであれば、リンク先が参考になるかと。
以下、適当な比較軸で徒然なるままにｗ
clean は共通認識を作り、理解しそれを反映させたコードを指します。
beautiful は共通認識の壁を破り、その先にある仕組みを見せつけます。
clean は多分に客観的です。
beautiful は多分に主観的です。
clean は全体最適化です。
beautiful は部分最適化(?)です。
なんとなくわかった気がします。でも微妙に違うきもしますが、それは今後の経験で感じ取っていこうと思います。
0
既に、参考となるような回答が、多く寄せられていますが、、
「きれいなコード」とは何って疑問を書いておきます。
以前にも書いたかも知れませんが、
「見た目、きれいだけど、正しく動作しないコード」
と、
「スパゲティで汚いけど、結果が正しいコード」
のどちらが良いでしょうか?
特殊な例、と言われるかも知れませんが、過去に出会っています。
「きれい」に"正しく動く"という事を含めるべきでしょうが、見た目、"きれい"で判断されるので、注意という事です。
自分の経験としても、モジュール化し、すっきりしていると思ったら、モジュールの狭間に、割込みが入って、デバッグに苦労した事があります。
また、設定を外部から、容易に変更可能にして、(自分的に)良かったと思ったら、引き継いだ人に完全に無視された(直書きで更新された)なんてのがあって、一筋縄で行かないな、と思っています。
きれいなコードは、「正しく動き」、「メンテナンスが容易な」コードではないかと思います。
投稿2019/11/19 14:11
総合スコア6383
0
｛悪い，よくない，汚い，嫌い，…｝なコードをたくさん書いたり読んだりすること，
そしてそれを｛解消する，繰り返さない，…｝方法を採るように心がけること，
この繰り返しです．
経験，というか，反省と向上心（＋嫌悪感のような何か）というか．
きれいなものを真似る，という方向よりも，むしろ汚いものを避ける的な方向への努力，というか．
投稿2019/11/19 04:02
総合スコア11658
0
良い文章、よい絵画、よい歌詞、よい曲...
よいコードを書くのも、それらと同じだと思います。
投稿2019/11/23 07:27
総合スコア22324
0
良いコードが書けるようなアドバイスや、正しいコードを閲覧できるようなサイトが御座いましたら、ご提示いただけると幸いです。
私はこの手の質問を投稿される度に思うのですが、「この4000行は言語仕様的に仕方がなかった」のか「ただ漠然に書いたら4000行になった」のでは大きく異なります。
基本的に大事なのはこの３つです。
- 2回同じコードを書くなら関数等を作った方がいい
- サイクロマティック複雑度が高い数値を示していないか
- 美しい完璧なコードなど存在しない。「美しい」「完璧」は人の価値観によって変わるためである。
これがしっかり出来ているなら、「まだマシ」と言われるソースコードにはなります。
投稿2019/11/19 00:59
総合スコア3307
低評価はしていませんが、その回答だとその3つを守ってさえいれば、命名は何でも良い、オブジェクト毎に決まった役割を持たせなくても良いと誤認しそうです。そういったコードは、大抵可読性が悪くて、「まだマシ」なレベルかも怪しいと思います。
命名規則とかはその上に乗ってくるものだと思っております。
しっかりとソースコードを理解していない初見の状態で見て、適当にスクロールだけの状態で評価するのはこの３点です。
テキトーに流し見だけでも強烈な眠気に襲われるようなソースコードを読んで来たためか、私の感覚は少しズレているのは否定しませんが、命名規則等は、それを終えた後「ああ、これなら読めるな」と思ってから気にしだすものだと思っております。
そんな低いレベルの話はわざわざ質問しないのでは？
「最低限のコードを書けるようになるには」ではなく、「きれいなコードを書けるようになるには」です。
4000という数字が一つのソースコードなのか複数のソースコードなのかすら分からない質問では、一番最低限の回答でいいと思いますが...
質問にもあるように「こっちの方がいいかも」と思うなら、私なら時間があれば、ブランチ切って試します。
> 美しい完璧なコードなど存在しない。「美しい」「完璧」は人の価値観によって変わるためである。
価値観が人によって異なる点のみ同意できるけど、ここでいう「きれい」「美しい」の評価というのはマジョリティが認めるか否かという問題だと解釈するのが自然だし、逆に「美しいコード」についての本や記事は世の中に沢山あるのに対して「価値観によって変わる」で切り捨てるような回答は求められていない。
むしろこのような回答は議論の根底を否定するものなので、「美しさ」についての共通した見解が得られない事を前提としたいなら、一般的に言われる「『美しいコード』は可読性やメンテナンス性などの面でメリットが有る」等の主張に対する反証を出すべき。
当然、質問者がハッキリした評価軸を用意するのがベストだけど、人間が理解しやすいとされる適切な粒度のコードであるのか、とか、一連の処理で異なる抽象度のものを扱っていないか、とか、一般論で論じることは十分可能な問題なので、上の２つはともかくとしてこの回答だけはちょっと無いな、と思いました。
質問文で、現状を詳しく説明しなかった自分が悪いですが、4000というのは、データ用のプログラム、メインのロジックや表示を担うプログラム、ユーティリティーのプログラム等、そのアプリケーションにおいて自分が書いたコードすべてのことを指します。（ファイルは４０ぐらい）
また、「言語仕様的に仕方がなかった」というのはよくわかりませんでしたが、あまり考えてないところもありますが、オブジェクト指向考えながら、自分なりにコードを書いてきたつもりです。
その上で、「より美しい」「よりキレイ」を目指すにはどう学んでいけばよいかが知りたかったことです。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/11/19 02:13
2019/11/20 15:23