2014-08-12

コーディングスタイル論争「カッコを省略するな」が出るたびに思う事

こういう記事が上がって

それへの反応

記事最初のカッコの省略だけど、世界的に評価されて広く使われてるようなプロジェクトコードを見ると、案外{}が省略されていたりしてそんなことは気にしてない。(たとえばlinux, apache, postgresql, mysql, chromium, netbeeans, eclipse, llvm, jruby, android)

で「こんなコードを書くヤツは夜道に気をつけろ」「八つ裂き」みたいな大げさな反応してるのって、どういうコードを書いてるかよく分からないような人たち。

自転車置き場の議論的な、素人でも分かりやすポイントからこのツッコミって人気あるのかね。

―――――↓見てないかもしれないけどブクマとかへの返信を追加―――――

2chあたりでコーディングスタイル議論になったときは、俺様基準じゃなくて実際に成果を出してる人たちが採用してるコーディングスタイル基準にしようぜってことで、誰もが認める成果を出しててソースを見れるオープンソースコードを引き合いに出すことが多いんだけど、そうするとよくある反論が二つある。

みたいなの。

さすがにはてなツイッターじゃ、前者のような「お前は20年前からタイムスリップしてきたのか」みたいな認識の人はいないみたいだけど後者のような人は何人もいるね。

高度なコードを書いてる人とITドカタのコーディングルールは違うってなんなんだろうね。

「高度なコードを書いてる人は低レベルケアレスミスなんてしない、だからカッコを省略しても平気なんだ、レベルの低い連中はケアレスミスをするからカッコが必要なんだ」って認識なのかね。

まあたしかに「viは一晩で書かれた」みたいにハッカーが複雑なコードを一気に書きあげてバグがなかったみたいな伝説ってあるけど、素人じゃないんだからそういうハッカーイメージで高度な人たちをとらえるのはやめよう。

集中力が高度でケアレスミスをしないとか、今どきのソフト開発の「高度」はそういう意味じゃありません。

高度なソフトを開発している人たちは、おおむね読みやすさや保守性にセンシティブです。そのらのSIerなんかに比べたらはるかに。

で、そういう人たちが、カッコを書くか書かないかなんてどうでもいいって認識からカッコを省くコードが書かれてるんです。

ハンガリアン記法コードの質を高めると信じられてたときとか、if (100 == n) のように比較で定数を左にもってくるのが流行ったときも、そういう流儀の人たちは自分らは安全側に倒してるから正義だって信じて主張を全然曲げなかったですね。

むやみに安全側に倒せばプロだとか、コードの質にセンシティブだって思考は恥ずかしいみたいな風潮になればいいのにね。

トラックバック - http://anond.hatelabo.jp/20140812112643
  • http://anond.hatelabo.jp/20140812112643

    どっちもどっちだか、 まともにコード書いた事ないヤツは黙ってろや! って事だよ。

  • http://anond.hatelabo.jp/20140812112643

    あの なんというか。   >>| if( bool ){ function(); } |<< ってね。 >>| if( bool ) function(); |<< ってかけるんだけど 第3者がデバッグしている時に function();にブレークポイント...

    • http://anond.hatelabo.jp/20140812113750

      そもそも、フォーマッタを統一すればいいだけの話でなんでいちいちデバッガの話とかに発展してんの? 手で文書をフォーマットするとかそれ以前の話だで。

      • http://anond.hatelabo.jp/20140812114200

        なんでいちいちデバッガの話とかに発展してんの? デバッガの事を気にしないでコーディングルールの論争をしていたから。 開発する時にデバッガ使わない人もいるけど、使う人もい...

        • http://anond.hatelabo.jp/20140812114517

          前提がちげー。コードをコミットする前にフォーマッタでフォーマットしてからコミットするの。 そうすりゃ誰がどんなコード書こうが、ちゃんと統一された書式やらインデントやらに...

          • http://anond.hatelabo.jp/20140812115005

            昔のコードを扱うにしても、プロジェクト開始時に一斉にフォーマットしちまえ。 これは怖いわ。コードが化石ならコンパイラも化石だろ。今の基準でフォーマットしちまったら意味...

            • http://anond.hatelabo.jp/20140812115457

              どうせそのプロジェクトがマイグレーションの役目も含んでいるなら、最初のうちにレガシーをつぶしちまう方がいいだろ。 テストしてるうちとかに非互換が出てきたときのほうが悲惨...

  • http://anond.hatelabo.jp/20140812112643

    世界的に評価されて広く使われてるようなプロジェクトのコードを見ると、案外{}が省略されていたりしてそんなことは気にしてない その結果バグは出てるし、やっぱ使わないほうが...

    • http://anond.hatelabo.jp/20140812114304

      マジレスすると中カッコが増える度にコードの複雑度は増すから、中カッコが少ないコードの方がバグの少ないコード足りうるぞ。

      • http://anond.hatelabo.jp/20140812114509

        中括弧の数ではなく分岐の数だと思うし 中括弧を省略したifと 省略してないifで複雑度は変わらない。

        • http://anond.hatelabo.jp/20140812115007

          本当にそう思うか? if(A==条件){ if(B==条件){ 処理(); } } と if(A==条件 && B ==条件) 処理(); なら、圧倒的に後ろの方がバグが少なくなるコードだよな? なにより、見やす...

          • http://anond.hatelabo.jp/20140812115420

            それなら if( (A==条件) && (B==条件) ) { 処理();} にすればもっと見やすくなるじゃん

            • http://anond.hatelabo.jp/20140812115657

              割とマジレスすると、ifの中にAND条件入れるってのは、ブレークポイント入らないと困る派にとっては割とありえん話なんだぜ。 if( A==条件 && B==条件 ){ 処理(); } こんな...

              • http://anond.hatelabo.jp/20140812120406

                条件式のANDの話と中括弧の省略の話って全く関連ないよね? 糞プログラマって関係してないことを関係してるかのように話して、無駄に複雑に見せようとするよね。

                • http://anond.hatelabo.jp/20140812120815

                  if文だけを覚えてる初心者レベルにコードを書かせると、ANDで省略せずにifネスト地獄を書くやつが結構いるってことだよ。 だからこそ、「省略できるカッコは可能な限り省略するように...

                  • http://anond.hatelabo.jp/20140812121901

                    全然意味わかんねー。 それがプログラマの論理的思考なの? ANDが無くて無駄にネストしてんならAND教えりゃいいじゃん。中括弧の省略は関係ねーって。

                    • http://anond.hatelabo.jp/20140812122354

                      なんでわかんねーんだよ。「中カッコはなるべく入れましょう」って思想だと、ifネストしてても「だってそう教わりましたしおすし」っていう考え方になるから、なかなか洗練されたコ...

          • http://anond.hatelabo.jp/20140812115420

            なんで上だけネストさしてんだよ。 こうだろ? if(A==条件 && B ==条件) { 処理();} お前糞だな。

            • http://anond.hatelabo.jp/20140812115903

              AND条件があるってことは、ELSE条件も本質的には存在してるってことなんだよ。 本当の意味で丁寧に描くなら if(A==条件){ if(B==条件){ //AB達成した時の処理 } else{ //Aのみ達...

          • http://anond.hatelabo.jp/20140812115420

            結論から言うと そのコードは どっちでもいい。 昔は1画面20-25行しか無いVGA環境だったが 今は1画面に100行ぐらい入るから if( a ){ if( b ){ f(); } } if( a && b ){ ...

  • http://anond.hatelabo.jp/20140812112643

    中括弧は、プログラミングを覚えて1年くらいの段階で絶対に付けるようになって今に至ってる。 ブロック内がシングルステートメントなら無くてもいいんだが、後で処理を追加するの...

    • http://anond.hatelabo.jp/20140812132823

      せやな。「ネストすんな」を言い続けてたらprivate void()でソースを埋め尽くされたこともあるし、もっと大枠で語らないかんな。

      • http://anond.hatelabo.jp/20140812133748

        private void()でソースを埋め尽くされた 別にいいだろ、関数名が適切なら。process1、process2とかならアレだけど。

        • http://anond.hatelabo.jp/20140812135354

          良くねえよ。引数なしのprivate void();って、プログラム的には「まったく意味のない」メソッドであって、処理を纏めてる意味合いしか持たないんだよ。 デバッグしてるときとかに処理が...

          • http://anond.hatelabo.jp/20140812140732

            処理を纏めて名前付けるのは超重要だろ。 適切に名前付けされてれば、人間にとって読みやすくなるだろ。 まとまった処理を、関数に分離しながら開発していけば、自然に処理も共通化...

            • http://anond.hatelabo.jp/20140812142259

              引数を与えてないのに内部状態が変わるってのは「どう変わるか」が分からないってことなんだよ… コメント読む、ソース読む。どちらかを強いている(概ね後者)のが激しくクソなん...

              • http://anond.hatelabo.jp/20140812143653

                関数化されるのが「まとまった処理」で「適切に名前付けされてる」のが前提。 その限りにおいては、できるだけ細かく関数に切り出すべき。 関数名読んで何やってるかわからないのは...

                • http://anond.hatelabo.jp/20140812144441

                  適切に名前付けされててもダメだ… 何故なら、private void()メソッドの作成を許すなら、必然とprivate void()の中でまた別のprivate void()を呼ぶような設計になるからな。 他のクラスのpublic void(...

                  • http://anond.hatelabo.jp/20140812145234

                    横からだが、言ってることがよくわからないな。 ・状態は出来るだけ減らす ・適切にクラス分割、カプセル化して状態の依存関係を極限化する あたりなら分かるが、private voidな関数に...

                  • http://anond.hatelabo.jp/20140812145234

                    横だけど、 switch-caseもどきのif elseが多段でネストしているロジックの時にcaseの中身を private voidにしないと1000行ぐらいあるケースの場合は private void __whatdo(); という使い方になる...

                    • http://anond.hatelabo.jp/20140812150741

                      「関数が長くなるから、読みやすくするためにprivate void()にする」がナンセンスなんだよ。 おおよそ、{}で括ったブロックは殆どのIDEでは縮めて省略表示出来るようになってる。 設計...

                  • http://anond.hatelabo.jp/20140812145234

                    いや普通にGUIがらみの共通の処理とかで使うだろ。

  • http://anond.hatelabo.jp/20140812112643

    まあでも、Appleとかでさえこんなミス見逃して出しちゃうくらいだから、 括弧くらいつけとけ、って感じにはなるよね。 https://www.imperialviolet.org/2014/02/22/applebug.html

  • http://anond.hatelabo.jp/20140812112643

    研究者のコードだったり、世界的に有名なプロジェクトのコードなどは、 コードを書く人のスキルが担保されているから省略を多用してわかりづらくなっても問題が起きにくい。 翻って...

    • http://anond.hatelabo.jp/20140812150734

      あくまでも読みづらかったらという前提だが 優れたプロジェクトほどコミッターに怒られてレジェクト食らうだろ。

    • http://anond.hatelabo.jp/20140812150734

      研究者のコードだったり、世界的に有名なプロジェクトのコードなどは、 コードを書く人のスキルが担保されているから省略を多用してわかりづらくなっても問題が起きにくい。 い...

    • http://anond.hatelabo.jp/20140812150734

      そうかー。 みんなif文の括弧省略できるならしてるし、俺も好きだけど、コーディング力の質の担保された世界に住んでたんだ俺。 なんかちょっと優越感だな。

  • http://anond.hatelabo.jp/20140812112643

    典型的なアンチパターンやん if (hoge) fuga(); って書いてオレカコイイ(キリッしたら 後日誰かが if (hoge) fuga(); piyo(); って書き足して涙目になるで。

  • 「カッコを省略」でひどい目にあうと、「カッコを省略するな」教になるのは当然

    あと、すごい系のエンジニアは、頭の構造が完全に、プログラミング言語とかに最適化されてると思うので、自然言語に近いとか関係なく、逆に自然言語に近いほうが思考を邪魔される可...

  • http://anond.hatelabo.jp/20140812112643

    >どういうコードを書いてるかよく分からないような人たち。 重箱の隅つついて悪いけどちょっと調べりゃgithubのアカウント見つかるよ

  • http://anond.hatelabo.jp/20140812112643

    python ! python !!

  • http://anond.hatelabo.jp/20140812112643

    そういう本質的でないところでつっこんでくるだけでなく あまつさえ八つ裂きとか言い出すひととは一緒に仕事したくないですね 自転車置き場で一生たむろしてて欲しいです

  • http://anond.hatelabo.jp/20140812112643

    こういう事件があったことをもうお忘れかい? ttp://qiita.com/tomohisaota/items/e6995e89b843e1295c08

    • http://anond.hatelabo.jp/20140812210735

      ケアレスミスは、どういうコーディングスタイルでも起きるよ。 問題なのはコーディングスタイルじゃなくて、それがレビューなしでコミットされた開発体制であって 個人の責任じゃな...

      • http://anond.hatelabo.jp/20140812212046

        なるほど、もっともだ しかし、しょうがなく「レビューなしでコミットされた開発体制」を取らざるを得ない場合はどうだ? 人手が足らなくて、時間も無い時。 できればケアレスミス...

  • http://anond.hatelabo.jp/20140812112643

    きちんとしたテストがあれば、どっちでもいいとマジレスするとまずい雰囲気だな、これ。

  • http://anond.hatelabo.jp/20140812112643

    プログラミング作法読みなおしてみた。 K&Rと同じく、基本省略スタイル推奨。 ただ、ifがネストした場合には、elseのぶら下がりがわかりづらくなるから、必ず中括弧書け、とも言って...

    • http://anond.hatelabo.jp/20140812223659

      しかしこういうアホな論争をみるにつけてgit hubなどにも見られるように近年増々顕著になりつつある ”プログラミングの社会化”に 多くのプログラマーがついていけない(特に日本人...

      • http://anond.hatelabo.jp/20140812224418

        コードの美しさについては常に世界中のプログラマの間で話題になってる。 中括弧省略の是非を論じてる人は今でもいっぱいいる。 http://stackoverflow.com/questions/8020228/is-it-ok-if-i-omit-curly-brac...

        • http://anond.hatelabo.jp/20140812225547

          プログラマーならご存知の通りプログラミングは戦争だ。 でも最近あまりにくだらない価値観で戦争している馬鹿が目立つ。

注目エントリ

記事への反応(ブックマークコメント)