Q&A
これを書いている時点(5／2 20：40)で、yuba氏の回答は+15の賛同を得ていますが、まだ質問者さんは 納得されてないご様子。具体的な先輩からの指摘内容を追記されてはいかがでしょうか？プログラムはアートです。指摘している人にその感覚があるかどうかは指摘内容でわかります。
駆け出し中のエンジニアです。
仕事としてコードを書いてレビューを頂く時に、
「空行」
「無駄なスペース」
「スペースがない」
など、言語の書き方の規則についてたくさんの指摘をレビュー時に頂いております。
自分でもチェックをしているつもりでも改行などはたまに入ってしまうことがあります。
規則なども色々なものがあり、どれを採用するかは企業次第とも聞きます。
そこでですが、何故このような規則文法にエンジニアの方は厳しいのですか？
見やすさ、保守性などでしょうか？
出来れば様々な人からの回答を頂き、色々な角度の意見を聞いたほうがタメになる、と思いベストアンサーはまだしていない状況です。決して納得していないわけではなく、落ち着いたら正しく評価いたします。
回答11件
23
ベストアンサー
以前「リーダブルコード」の訳者の方が登壇するリーダブルコード勉強会に参加したことがあります。
このときはその訳者の方が実際にライブコーディングで読みにくいコードを読みやすく書き直す実演をしてくれたのですが、
何が始まったかというと、まさに空行やインデントの修正がまず始まったのです。
参加者の中から、「そんな枝葉末節の修正じゃなくもっとクラスやモジュールの設計を見直すような“らしい”修正を見たい」という声が上がったのですが、
演者の方は「いいえ、これが大事なんです」と即答されていたのが印象的でした。
なぜそういう枝葉末節の整形がそんなに大事なのか、そのときには突っ込んだ議論をしたわけではないので解釈は各人に任されたところがありますが、いかが思われますか。
私はこう考えます -- クラス設計や処理の組み立てのまずさ、そういうのをまず見えるようにしなくてはコードの改善のスタートラインにも立てないということです。コード整形はスタートラインに立つための第一歩であると。
追記
そのときの勉強会のレポート記事がありました（私の書いたものではないです）。
http://d.hatena.ne.jp/absj31/20120706/1341599360
下から2／3くらいのところに、「いや、大事なことですよ！」「一見本質じゃない所をちゃんとする→本質に集中する事が出来る、というのが私の考え。」という発言が見えます。
投稿2017/04/25 02:48
編集2017/04/26 00:27
総合スコア5562
回答へのコメント
回答ありがとうございます。
リーダブルコードの訳者の勉強会に参加されたんですね。
自分はまだ読んだことがないのですが、タイトルだけは知っていて読みたいなあと思っている本ではあります。
「コード成形がスタートラインであり重要」
ということですね。エンジニアとして上位に居る人でもそういった考えの元コーディングしているんですね
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
回答では一般論を述べましたので、実際のところ職場の先輩方のレビュー姿勢がどうなのかについてはまた別の答えになってくるかも知れません。ルールに厳密に従ってクソコードを量産している方々であるかもしれませんので、断言はできないです。まさか業務のコードを見せろというわけにもいかないのでご自身で判断できるようになっていただくしかないのですが、そうすると必要なのは何より見聞を拡げることですね。様々な組織でのコードの書き方を知ることで現職のレビューについても俯瞰的に評価できるようになると思います。するとやるべきことは…転職？
ありがとうございます。
まだまだエンジニアとして歴の浅いというのもあり、こういう質問をさせてもらいました。
今はまだ無理ですが、ある程度こなれてきたと感じたらやはり色々な企業でのコードの書き方を見るということが自分のためになりそうですね。
ありがとうございました。
15
みなさんが言われていることはどれも正しいと思います。
結局のところ、読みやすさ、分かりやすさ、保守しやすさ、などなど「苦労しないために」というのが一番の理由かなと思います。
すでにみなさんがある程度書かれているので、少しだけ違った視点から書かせてもらうと。
以下はどう思われますか？
「句読点がなく、改行もなく、一文がダラダラと長い日本語を目にした時」
おそらく、読む気をなくすのではないかと思います。
やはり、きれいな日本語で、分かりやすく書かれた記事や書籍は読みやすく、また理解もしやすいものである可能性が高いです。
なにが言いたいかというと、プログラムも「言語」である、ということです。
日本語と同じように、分かりやすく書くにはどうしても改行や空白など「意味の塊」を意識して書く必要があります。
なので自分がプログラムを書くときは、日本語で文章を考えるのと似た発想で書くようにしています。
例えば、ここは意味を勘違いしそうだぞ、と思ったら説明変数を設けてみたり、改行を多めに入れてみたり、などです。
一度、プログラムを「文章を書く」という視点で考えみてはいかがでしょうか。
投稿2017/04/25 03:59
編集2017/04/26 01:14
総合スコア2275
回答へのコメント
回答ありがとうございます。
日本語の視点で考えてみると仰ることは良く分かりました。
確かにキレイで分かりやすい日本語を書いていていれば誰からも文句は言われませんし、分かりやすいのも確かです。
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
確かに、そこはむずかしい問題だと思います。
個人的にも「hoge, more」と空白を空けたほうが読みやすいので、そういう指摘をすることがあります。
一方で、「規則だから」というのもある一理あるのです。
なぜなら、すべてが統一されているなかで、一箇所だけ異なる書き方をしていたら。
例えそれが見やすい書き方であっても違和感があるし、「なにか別の意図が？」ともなりかねません。
日本語に関しても同様で、例えきれいな日本語であっても「だ、である調」と「です、ます調」がまざっていたら読みづらいですよね？
読みやすさ、というのは全体の流れからも生まれるものなので、そのあたりはある程度規則に従う必要があると思います。
ただ、「本当にそれが読みやすいのか？」を自問することは大事です。
「規則だから」だけでは、よりよくできるものを黙殺していることになるからです。
規則になった背景が必ずあるはずで、もしそれが言えないのであれば、変えることを進言してもいいと思います。
結局のところ、読みやすさというのはプロジェクトや関わる人たち次第で変わってくるものでもあるので、「みんなが読みやすく、開発しやすい書き方を、みんなで思いやりを持って書こう」というのが自分が大事にしている視点です。
（正直なところ、1ヶ月前の自分のコードは他人のコードに近いくらい分からなくなったりするので、将来の自分のためでもあったりしますがｗ）
ありがとうございます。
やはり規則だから、ということで最初は確実に従うことが重要ということですね。
そこから経験を積んでいき、ある程度のベースが出来てきてからの「規則に疑問を持つ」ということは大事だと思いますが、今はその時期ではないということですね。
まだまだエンジニアとして経験が浅い身ですので経験を積んでいき、また自分のこの質問を見直してみたら面白そうかも、と感じました。
ありがとうございました。
10
めんどくさがりなら、ツールに任せてしまうのも1つの方法です。
インデントはEditorConfigなど自動設定できますし、スペースの入り具合などは言語によってlinterが存在します（RubyのRubocop、JavaScriptのESLintなど）。
投稿2017/04/25 02:48
総合スコア142240
回答へのコメント
回答ありがとうございます。
Rubyを書いているのでRubocopを導入したりしてみました。
導入してから初期のカスタマイズで苦労しそうですが、ツールにある程度任せてそれに則ってコーディングしていく、というのも最初は重要、ということでしょうか
9
「コードを美しく書くのもプロの仕事のひとつです」
まあ、お金もらってコードを書いている以上、それくらいの気持ちでは書いてます。
それ以外の理由としては以下です。
- コーディング規約に則った結果
- 見やすさ、読みやすさ
- メリハリ
特には2と3でしょうか。
スペースも空けずにギュウギュウに詰め込んだコードは非常に読みづらいです。
逆に無駄にスペースを空けると、他者が読んだ場合に「そこに何か意味があるのか」と思ってしまいます。
例えばある処理を行うコードが10ステップあったとして、なぜか途中に空行があると、別々の処理と捉えてしまいます。
と理由を挙げましたが私の一番の理由は最初に挙げたやつです。
逆にコードが汚いプログラマはプロ意識が低いと思ってしまいますが、世の中にはコードが汚くても凄いプログラマはたくさんいるので困ってしまいますｗ
投稿2017/04/25 02:33
総合スコア16992
回答へのコメント
回答ありがとうございます。
「お金をもらって書いている以上〜」
確かに言うとおりではあります。コードを書くことでお金をもらっているので出来る限りキレイに書くというのは正しいかもしれません。
自分は一部のエリートプログラマーと違って全然コーディングする能力はないので、そういう所できちんと正しくキレイなコードを書かなければ価値のない人間だとは重々承知しております・・・
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
5
可読性や保守性が主な理由だとおもいます。
１箇所で規則を緩くすると、「あの箇所では緩くやったからここもいいか」と考え2箇所、3箇所と規則を破り、規則違反がどんどんと増えてしまいます。
そして「あの規則を破ったからこの規則程度なら破ってもいいか」と考え、コーディング規約が崩壊します。
この流れの最初を食い止めるために簡単な規則すら破らないという方針が定着しているからじゃないでしょうか。
または、単純に会社内のコーディング規約チェックリストに質問の規約が書かれていて、チェックしやすいからという理由もあるかもしれません。
投稿2017/04/25 02:34
編集2017/04/25 02:35
総合スコア18151
回答へのコメント
回答ありがとうございます。
確かにそうですね。チームで書く以上統一しないとバラバラなコードになっていく、というのは分かります。
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
「自分がわかりやすい」ではなく、「たくさんの人が平均的にわかりやすい」という事です。
たくさんのコードを読めば言っている意味がわかりますよ。
今、あなたがそう思っていても数年後には先輩と同じことを言っているはずです。
ありがとうございます。
そうですね、今の段階ではやはりそう思ってしまいましたがこういう規則に慣れていくに連れて大事さ、というものが分かってくるのだと思うようになってきました。
ありがとうございました。
4
空行やスペースは、文章の句点や読点や、芝居のセリフの間にあたるものです。使い方が不適切だと、読み手に意図が届きません。
「べんけいがな がいなぎな たをふりま わし」と言われても何のことか判りにくいです。
でも、「べんけいが ながい なぎなたを ふりまわし」と言われれば「弁慶が長い薙刀を振り回し」だと判ります。
投稿2017/04/25 06:35
総合スコア6911
回答へのコメント
回答ありがとうございます。
空行やスペースは句点や読点に置き換えてみれば確かに不適格だと大変読みづらいものですね。
自分は経験が浅いのでやはりそこの点がまだコードを書く上でまだ理解できていないのかも知れません。
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
4
見やすさ、保守性などが目的でしょうが、本来プログラムは「決まったルールに則ったコードを決まったルールでコンパイルして動作させる」ものなので、エンジニアが規則文法に厳しいのは当然だと思います。
駆け出し中のエンジニアに対しては、特にそのあたりが厳しくなるんじゃないですかねぇ。
機械的な補助が受けられる部分なので、うまく有効活用するのが良いと思います。
投稿2017/04/25 03:24
退会済みユーザー
総合スコア0
回答へのコメント
回答ありがとうございます。
エンジニアが文法に厳しい、ということですが、今それをコードレビューを通じてとても痛感している最中です。
ただ、自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
ちょっと伝わってない感じですね＾＾；
エンジニアは、「決まったルールを守る」ことがコード作成上重要なので、「規則に乗っ取らない方が見やすいのに」とという思考をしないように新人の間に訓練されます。
他のルールの方が優秀であると感じるのであれば、ルールを破るのではなく、「決まったルールを守る」ために「決まっているルール自体を変更する」ことがエンジニアには求められます。
ルールを守ることはエンジニアにとってただの「必要最低限のスキル」なので慣れるとか慣れないじゃないです。
ちょっと極論ですが、そういうことが言いたかったんですが、伝わりますかね？
ありがとうございます。
規約に乗っ取らない方が〜という思考をしないようにする、というのがエンジニアの最低条件なのですね
エンジニアでコードを書くということは、単に「見やすいようにいいコードを書く」、というぼんやりしたものよりも「規則に則っていいコードを書く」、というのが最低条件でここから始めなければいけないということを痛感しました。
ありがとうございました。
3
私はかなりの悪筆ですが、読むならきれいな字で読みたいです。
きれいな字とは、見とれてしまう字ではなく、文字の認識に時間がかからないまたは読み間違えをしづらいということです。
同様にインデントなどがきちんとしていないと、修正しようにも大事な部分を見逃すことがあるかもしれないからです。「そのくらいはキチンとしようよ。」という意見には同意します。
また、自分のコードを丁寧に読み返していれば修正してるので、気を抜いてコーディングしてないかと疑っていることもあると思います。
ただし、私はインデントなどのこだわりは強くない方です。基本的にはエディタの整形ルールで縛れる範囲で良いとは思います。一カ所でも変なところがあったら見ないという訳でもないです。
特に条件分岐などの部分でのちょっとした間違いがバグになった経験は多くの人が持っているので、神経質になることは多いと思います。
投稿2017/04/25 08:20
総合スコア2883
回答へのコメント
回答ありがとうございます。
「読むならきれいな字を」そうですね。自分もそう思います。
日本語で文章を書くなら出来るだけ読みやすい文章を書こう、とは思います。
その中で敢えてこういう文章の書き方をしたら〜みたいに考えられるのが日本語ですがプログラミング言語だとそうはいかないのですね。
自分が感じたのは、規則に馴染んでいないエンジニアとして新米だからかもしれませんが
「規則に乗っ取らない方が見やすいのに」
と思ってしまうことかもしれません。
「ここ1行空白だと見づらいから2行開けよう」
「こことここは一緒にしたくないから1行開けよう」
「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
と思って書いても規則では違うからコメントで厳しく指摘されたりします。
ここは言語、ということでそう慣れるべきなのでしょうか
自分が見やすい、と思っても他の全員は見づらいと思われていたりしそうですね。
コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
返信が遅くなってしまいました。
> 「ここ1行空白だと見づらいから2行開けよう」
> 「こことここは一緒にしたくないから1行開けよう」
そこそここだわりが強い方だとお見受けします。
行の開け方に関しては、感覚的な部分も多いと思います。書いたコードはチームの所有物、コードはチームが読みやすいように書くのが基本だと思います。もちろん、チームの一員として提案をするというのはありですし、一部の権力者が独善を押し付けるのもいけないとおもいます。
時間をかけてチームのメンバーとすり合わせていけばよいと思います。
> 「|hoge,moge|より| hoge, moge |」の方が見やすそうだな」
私も後者の方がよいと感じます。一般的で、それに合わせた方が、新しいメンバーがすぐに慣れるという利点があるからです。それでも、チームの意見が優先されるべきだとは思います。
> コードレビューで、わずかなスペースや空行一つも見逃さずにそういう指摘をして頂くのはやはり新米時代に厳しく指摘されてきて育ってきているのでしょうか？
それもあると思います。しかし、バグフィックスなどの神経質なときに、整形がチキンとしていないことで読みづらく苛立った経験の影響も大きいと思います。
ちなみに私は、整形しながら読むので気にならないということが多いです。（結構やばいコードを読んできた自信があります。）
返信ありがとうございます。
自分はエンジニアとして初めて会社に属し、初めてチームでコードを書く、という状況に直面している事もあり、まだ習慣として馴染めてない部分もあると思います。
個人で今まで書いてきた場合だと、「ある程度動けばいい」、または「適当にコードを書いて動かしてみた」のような感じでしたので、ある程度自分が書きやすい（自分が書いてしまったという方が正しい？）コードだけしか見てなかったので今そういうギャップが生まれている段階だと思っています。
他のコメントでもありましたが、チームで書く場合はまずチームの書き方というもので書き、それである程度慣れてから自分の意見のすり合わせなどをしたほうが良さそうですね。
ありがとうございました。
2
Javaのスタイルガイドとして先駆的な Scott.W.Ambler さんによる "Writing Robust Java Code" 「頑健なJavaプログラムの書き方」は、「1.1 なぜコーディング標準が重要なのか」から始まります。短いので一読してはいかがでしょうか。
http://www.ambysoft.com/essays/javaCodingStandards.html
http://seiza.dip.jp/link/files/writingrobustjavacode.pdf
そして。
そのすぐ次にあるのが「1.2 最優先規範」であるというのがサイコーにイケてます。これが本質であると思います。
Gitなどにより「コードの共同所有」が進んできた今の時代、各個人の美観に基づくちょっとした修正でも差分として認識されるので、規約に厳密に従っておかないと、履歴がノイズに埋もれてしまいます。そんな些細なことで意識を持っていかれて集中力が途切れるのはとても嫌なことですし、生産性も保守性もガクンと下がります。レビュアの方はそういうことを痛感しているからこそ、厳しくなるのだと思います。
投稿2017/05/10 06:46
総合スコア2493
回答へのコメント
回答ありがとうございます。
経験の浅い開発者は標準に従うことに抵抗する。
というのは完全に自分に当てはまっていますね・・・
規約に厳密に従うことが大人数で開発し、その後も残り続けるコードであるがゆえに必要なのですね。
ありがとうございました。
1
「見やすい」という感覚自体が主観であり、バラつくものであるからだと思います。
各々が自分の「見やすい」にのっとって書いていたらチームでの一貫性がなくなりますし、自分の「見やすい」は他人の「見にくい」かもしれません。
こればかりは主観なので他人にコントロールできるものではありません。
なので「規則」にみんな合わせるのが吉。ということかと思います。
あと、言語によってはスペースのあるなしで動きが違ったりすることもあるので、厳しくチェックするというのもあるかと思います。
投稿2017/05/02 08:15
総合スコア441
回答へのコメント
回答ありがとうございます。
言語の見やすさというのはあくまで主観でしかないですよね
規則、というからにはやはり大多数が決めて選んだものだと思われるので、そちらに従って見ようと思います。
ありがとうございました。
1
うちの場合は、インデントのスペースですら非常に気にしてしまうものです。
うちの場合のNG
void(space)main(void)(space){
(space)(space)(space)(space)printf("Hello World\n");
}
うちの場合のOK
void(space)main(void)(space){
(tab)printf("Hello World\n");
}
確かに、0x20というコードではなく、0x09というコードでインデントをすることになります。
これだけでも3バイト節約できるんですよ。
理由としては
・一応は限られたディスクスペースを少しでも節約したい
・高級ツール等がありますが、そのようなツールに一切依存せずつくりたい
・単なるテキストエディタでいじるとき、カーソルキーでインデント部分を移動する時に最小限になる
というのがあります。
だからといって、エディタのtab4、tab8には依存してしまうのがありますが、極力tab4にするように設定はします。
この例ではCで書いたので、コンパイルしてバイナリーになってしまえば、一切関係ないのですが、
もし、これがインタプリタでしたらどうでしょう？
文法解析の高度化によってあまり意識をしなくなったものの、スペースを可能な限り除去するだけで
ごくわずかではありますが、解釈の時間が短くなります。
古いBASICの例でいえば・・・
10 A=1
20 FOR I=0 TO 32767
30 FOR J=0 TO 32767
40 A=A+1
50 NEXT J
60 NEXT I
とかくよりも
10 A=1:FOR I=0 TO 32767:FOR J=0 TO 32767:A=A+1:NEXT:NEXT
とかくよりも可読性はかなり低くなりますが
10 A=1:FORI=0TO32767:FORJ=0TO32767:A=A+1:NEXT:NEXT
のほうのが、明らかに目でわかるぐらい高速化してたわけです。
また、今では通信回線を介してものすごく頻繁に転送されているわけです。
いわゆるインターネットですが。
初心者、中級者、上級者ですら気にしない場合もあるのですが
HTMLのインデントとかいって
とかよくする人もいます。
これはかなり短いですので、IPV4/V6の1パケットに余裕で収まるものの
そこそこのコンテンツを書けば、最低でも10パケット以上になることでしょう。
1パケットでも節約できれば、Webサイトの高速化ができます。
ギガビットのインターネットが確かに流行ってはいますが、
実際に見るユーザーはどんな回線でしょうか？
未だにADSLであったり、モバイルであったり
そのような方を考慮して、うちはどうしても汚いソースですが
<html> <body> <div> あいうえお </div> </body> </html>と書いてしまいます。
理想は
<html><body><div>あいうえお</div></body></html>なんですけどね。
https://www.google.co.jp/ のソースを見れば、どれだけ美しく、表示に最適化されたか、わかるかと思います。
投稿2017/05/02 06:15
退会済みユーザー
総合スコア0
回答へのコメント
回答ありがとうございます。
tabとspaceですが、自分がプログラミングを習った時にエディタで強制的にtabをspaceで変換する設定をしていたので気に留めていませんでした。
突き詰めると無駄な記述削除で高速化という面もあるんですね、勉強になります。
今の時代になると、コードでの高速化とインデント含めた読みやすさどちらが大事か、というと難しい話なのでしょうか
ちなみに、さすがにHTMLとなると、自動ツールで最適化しているのがあります。JS/CSSも著名な圧縮ツールが多数あります。ちなみに、読みやすさと高速化というのは両立する必要はありません。高速化は先にもいったようにツールで行うこともできますので。
なるほど、それでしたら尚更各自が規約に従ってコードを書き、読みやすく保守性が高いコードにすることがやはり重要なのですね
ありがとうございました。
あと、HTMLに限って、こんなこともあります。
意図的に
<div>
<div>
<div>あいうえおかきくけこさしすせそあいうえおかきくけこさしすせそあいうえおかきくけこさしすせそあいうえおかきくけこさしすせそ</div>
</div>
</div>
とインデントしないことがあります。
これは、ネストが大きくなることによって、文書自体がエディタ内で改行されることで、可読性が悪くなってしまうこともあり、わざとインデントを一切行わないこともあるんです。
