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