駆け出し中のエンジニアです。
仕事としてコードを書いてレビューを頂く時に、
「空行」
「無駄なスペース」
「スペースがない」
など、言語の書き方の規則についてたくさんの指摘をレビュー時に頂いております。
自分でもチェックをしているつもりでも改行などはたまに入ってしまうことがあります。
規則なども色々なものがあり、どれを採用するかは企業次第とも聞きます。
そこでですが、何故このような規則文法にエンジニアの方は厳しいのですか?
見やすさ、保守性などでしょうか?
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/05/11 16:49
回答11件
0
ベストアンサー
以前「リーダブルコード」の訳者の方が登壇するリーダブルコード勉強会に参加したことがあります。
このときはその訳者の方が実際にライブコーディングで読みにくいコードを読みやすく書き直す実演をしてくれたのですが、
何が始まったかというと、まさに空行やインデントの修正がまず始まったのです。
参加者の中から、「そんな枝葉末節の修正じゃなくもっとクラスやモジュールの設計を見直すような“らしい”修正を見たい」という声が上がったのですが、
演者の方は「いいえ、これが大事なんです」と即答されていたのが印象的でした。
なぜそういう枝葉末節の整形がそんなに大事なのか、そのときには突っ込んだ議論をしたわけではないので解釈は各人に任されたところがありますが、いかが思われますか。
私はこう考えます -- クラス設計や処理の組み立てのまずさ、そういうのをまず見えるようにしなくてはコードの改善のスタートラインにも立てないということです。コード整形はスタートラインに立つための第一歩であると。
追記
そのときの勉強会のレポート記事がありました(私の書いたものではないです)。
http://d.hatena.ne.jp/absj31/20120706/1341599360
下から2/3くらいのところに、「いや、大事なことですよ!」「一見本質じゃない所をちゃんとする→本質に集中する事が出来る、というのが私の考え。」という発言が見えます。
投稿2017/04/25 02:48
編集2017/04/26 00:27総合スコア5570
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:04
2017/05/02 04:18
2017/05/11 16:43
0
みなさんが言われていることはどれも正しいと思います。
結局のところ、読みやすさ、分かりやすさ、保守しやすさ、などなど「苦労しないために」というのが一番の理由かなと思います。
すでにみなさんがある程度書かれているので、少しだけ違った視点から書かせてもらうと。
以下はどう思われますか?
「句読点がなく、改行もなく、一文がダラダラと長い日本語を目にした時」
おそらく、読む気をなくすのではないかと思います。
やはり、きれいな日本語で、分かりやすく書かれた記事や書籍は読みやすく、また理解もしやすいものである可能性が高いです。
なにが言いたいかというと、プログラムも「言語」である、ということです。
日本語と同じように、分かりやすく書くにはどうしても改行や空白など「意味の塊」を意識して書く必要があります。
なので自分がプログラムを書くときは、日本語で文章を考えるのと似た発想で書くようにしています。
例えば、ここは意味を勘違いしそうだぞ、と思ったら説明変数を設けてみたり、改行を多めに入れてみたり、などです。
一度、プログラムを「文章を書く」という視点で考えみてはいかがでしょうか。
投稿2017/04/25 03:59
編集2017/04/26 01:14総合スコア2283
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:12
2017/05/02 03:40 編集
2017/05/11 16:47
0
めんどくさがりなら、ツールに任せてしまうのも1つの方法です。
インデントはEditorConfigなど自動設定できますし、スペースの入り具合などは言語によってlinterが存在します(RubyのRubocop、JavaScriptのESLintなど)。
投稿2017/04/25 02:48
総合スコア145930
0
「コードを美しく書くのもプロの仕事のひとつです」
まあ、お金もらってコードを書いている以上、それくらいの気持ちでは書いてます。
それ以外の理由としては以下です。
- コーディング規約に則った結果
- 見やすさ、読みやすさ
- メリハリ
特には2と3でしょうか。
スペースも空けずにギュウギュウに詰め込んだコードは非常に読みづらいです。
逆に無駄にスペースを空けると、他者が読んだ場合に「そこに何か意味があるのか」と思ってしまいます。
例えばある処理を行うコードが10ステップあったとして、なぜか途中に空行があると、別々の処理と捉えてしまいます。
と理由を挙げましたが私の一番の理由は最初に挙げたやつです。
逆にコードが汚いプログラマはプロ意識が低いと思ってしまいますが、世の中にはコードが汚くても凄いプログラマはたくさんいるので困ってしまいますw
投稿2017/04/25 02:33
総合スコア17000
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:05 編集
0
可読性や保守性が主な理由だとおもいます。
1箇所で規則を緩くすると、「あの箇所では緩くやったからここもいいか」と考え2箇所、3箇所と規則を破り、規則違反がどんどんと増えてしまいます。
そして「あの規則を破ったからこの規則程度なら破ってもいいか」と考え、コーディング規約が崩壊します。
この流れの最初を食い止めるために簡単な規則すら破らないという方針が定着しているからじゃないでしょうか。
または、単純に会社内のコーディング規約チェックリストに質問の規約が書かれていて、チェックしやすいからという理由もあるかもしれません。
投稿2017/04/25 02:34
編集2017/04/25 02:35総合スコア18155
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:04 編集
2017/04/30 15:56
2017/05/11 16:40
0
空行やスペースは、文章の句点や読点や、芝居のセリフの間にあたるものです。使い方が不適切だと、読み手に意図が届きません。
「べんけいがな がいなぎな たをふりま わし」と言われても何のことか判りにくいです。
でも、「べんけいが ながい なぎなたを ふりまわし」と言われれば「弁慶が長い薙刀を振り回し」だと判ります。
投稿2017/04/25 06:35
総合スコア6915
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:14
0
見やすさ、保守性などが目的でしょうが、本来プログラムは「決まったルールに則ったコードを決まったルールでコンパイルして動作させる」ものなので、エンジニアが規則文法に厳しいのは当然だと思います。
駆け出し中のエンジニアに対しては、特にそのあたりが厳しくなるんじゃないですかねぇ。
機械的な補助が受けられる部分なので、うまく有効活用するのが良いと思います。
投稿2017/04/25 03:24
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:10
退会済みユーザー
2017/05/02 08:30
2017/05/11 16:39
0
私はかなりの悪筆ですが、読むならきれいな字で読みたいです。
きれいな字とは、見とれてしまう字ではなく、文字の認識に時間がかからないまたは読み間違えをしづらいということです。
同様にインデントなどがきちんとしていないと、修正しようにも大事な部分を見逃すことがあるかもしれないからです。「そのくらいはキチンとしようよ。」という意見には同意します。
また、自分のコードを丁寧に読み返していれば修正してるので、気を抜いてコーディングしてないかと疑っていることもあると思います。
ただし、私はインデントなどのこだわりは強くない方です。基本的にはエディタの整形ルールで縛れる範囲で良いとは思います。一カ所でも変なところがあったら見ないという訳でもないです。
特に条件分岐などの部分でのちょっとした間違いがバグになった経験は多くの人が持っているので、神経質になることは多いと思います。
投稿2017/04/25 08:20
総合スコア2883
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/04/30 15:16
2017/05/15 03:57
2017/05/21 10:50
0
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
0
「見やすい」という感覚自体が主観であり、バラつくものであるからだと思います。
各々が自分の「見やすい」にのっとって書いていたらチームでの一貫性がなくなりますし、自分の「見やすい」は他人の「見にくい」かもしれません。
こればかりは主観なので他人にコントロールできるものではありません。
なので「規則」にみんな合わせるのが吉。ということかと思います。
あと、言語によってはスペースのあるなしで動きが違ったりすることもあるので、厳しくチェックするというのもあるかと思います。
投稿2017/05/02 08:15
総合スコア441
0
うちの場合は、インデントのスペースですら非常に気にしてしまうものです。
うちの場合の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
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/05/10 05:46
退会済みユーザー
2017/05/10 09:59
2017/05/11 16:34
退会済みユーザー
2017/05/15 16:55
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。