パスワードを忘れた? アカウント作成
13965496 story
スラッシュバック

「 いいコーディング規約、悪いコーディング規約?」2019年版 140

ストーリー by hylom
新たな言語の登場で変わったことはあるかも 部門より

Anonymous Coward曰く、

2008年の記事「いいコーディング規約、悪いコーディング規約? 」より

本格的なソフトウェア開発企業で働くとき、最初の頃にまずコーディング規則や慣習などのガイドラインに目を通したかと思う。基本的なガイドラインとして、gotoは原則使用禁止だとか、インデントにはスペースではなくタブを使用すべきであるとか、またはその逆などがあっただろう。ひょっとしたらcontinue禁止や、複数リターン値禁止など、ちょっと変わってるように思える慣習や、あまり直感的とは言えないルールといったものもあったかもしれない。

可読性を高めたり、メンテ性を向上させるには、どんな規約が有効だっただろうか? ドキュメント上では一見良さそうに見えたが、実際はイマイチだったものなどあるだろうか?

SlashdotJ諸氏が実践してきたコーディング規約で特に有効だったのはどんなものだろうか? 逆に規約のせいで問題が起きてしまったケースなどあるだろうか? ほかにも、使える「自分ルール」などもあれば是非。

元々のストーリーからは十余年経過してますが、新たな「いい/悪い」は現れただろうか?

  • by wolf03 (39616) on 2019年07月25日 6時41分 (#3657649) 日記
    ①1行は80桁に収めろ
    ②1関数は50行に収めろ
    ③1ファイルは200行に収めろ

    ②③で超えさせたい場合は理由を添えて申請しろ

    ※どんな言語でもこれ適用
    ここに返信
    • by Anonymous Coward on 2019年07月25日 7時13分 (#3657658)

      1はlambda式とかfluent interfaceとかずらずら書く方式を使ってるとキツイね。
      まあ適当に改行入れれば回避できる。それで行数が極端に増えるってことはないだろう。
      2, 3は上限の数字云々よりも、「大きくなりすぎたら機能を分割できないか見直そう」っていう哲学から来てると思う。
      機能を詰め込むとテストしづらくなってバグの温床となる。

    • by nim (10479) on 2019年07月25日 11時17分 (#3657827)

      Cloud9+Lambda なので「ファイル」がありません……

    • by Anonymous Coward

      画面が640*480時代とかcobol時代の悪い面がレガシーで残ってるような規約だね

      • Re: (スコア:0, 荒らし)

        by Anonymous Coward
        でもこの規則がないと君ら10万行のクラス作っちゃうでしょwww
    • by Anonymous Coward

      ①1行は80桁に収めろ

      普段から何となく感じているのだが、これは人間が頭を使ってやる作業ではないと思うし、
      80桁強制は可読性でデメリットがある(ケースがある)。

      桁は制限せず、ビュー側のツールで何とかするとかが良い気がする。
      整形表示モードを切り替えられるとか、マウスオーバーなりのアクションで展開表示されるとか。

    • by Anonymous Coward

      ①②は(この規則を破る例外が許容されているならば)まあ分かるけど、
      ③はないわ。少なすぎ。

  • by Anonymous Coward on 2019年07月25日 7時34分 (#3657665)

    #define TRUE 0
    #define FALSE -1

    ここに返信
    • by Anonymous Coward

      それこそまさにコーディング規約が悪い. 次のように書くべきだ!

      #define TRUE 0xffffffff
      #define FALSE 0x00000000

      • by Anonymous Coward

        いきなりエンバグするバカのルールには従えねえ

    • by Anonymous Coward

      bool型使え、と言いたくなるな。
      未だC99すら使えない環境があるのも事実だが。

  • インデントはツールの自動整形に任せとけ、って空気になりつつあるな。
    エディタがリッチになったのも影響してるし、
    どうせ納品物はトランスパイルして整形されちゃうし、というケースが増えているのもあるか。

    ここに返信
  • 悪いコーディング規約なんて存在しない
    あるのは悪い現場だけだ

    --
    確率なんてクソくらえでしょう?  -UHED UNIT#507@GUNHED-
    ここに返信
    • by Anonymous Coward

      pushしてretしてたら自殺コード書いてたヤツに文句つけられた。
      こいつも大概だと思った。

  • by lcc (46023) on 2019年07月25日 13時04分 (#3657896) 日記

    EVALUATE禁止
    外PERFORM禁止
    ADD等禁止(COMPUTE使用)
    変数はプログラム名+連番(台帳管理)
    TOはxx桁(忘れた)に揃える

    ここに返信
  • by Anonymous Coward on 2019年07月25日 6時04分 (#3657646)

    変数名やら関数名に、cmとかkmとかkmphとかmpsとか単位を入れておくと
    単位換算ミスを防ぐことができる

    ここに返信
  • by Anonymous Coward on 2019年07月25日 11時22分 (#3657837)

    ここ10年で使えるようになった規約っていうとこれかな。ぱっと見で元の単語が推測できないような省略は基本的にしないルール。
    エディタの補完がまともな速さで動くようになって、長い識別子の入力が苦じゃなくなったので。

    関連ストーリー [developers.srad.jp]

    ここに返信
  • by Anonymous Coward on 2019年07月25日 7時48分 (#3657671)

    ・修正で追加行には必ず修正日・修正者をコメントに記載する事
    ・修正で削除行はコメントアウトして残し、修正日・修正者もコメントに記載する事
    ・修正が完了したら「project名_日付_aから始まるアルファベット」という名のディレクトリにまとめる事

    30年前ならともかく、なんて21世紀にもなってこんな仕事をしてるのやら…

    ここに返信
    • by Anonymous Coward on 2019年07月25日 11時40分 (#3657855)

      前職がこれでした

      理由は、海外のカジノマシンのコードだったので
      審査機関(GLIやNGCBなど)にビルド可能なソースコードと実行バイナリをセットで
      提出する必要があり、修正箇所はコメントアウトの上で修正理由を英文で記載する
      必要があったためです

      #CIOがクラウド利用とサーバ構築禁止してたせいで辞めるまでCIもGitも入らなかったのでAC

    • by Anonymous Coward

      単にVCSを使ってないだけならまだいいんですが、
      VCS (subversion)を使っていながら、
      上記のようなルールを採用してるところがあるんですよね・・・

      話に聞いた限りでは、VCSの知識が皆無な非IT系上司が、
      「紙に印刷したときにわからないから」と余計なルールを
      追加したそうで・・・

      いまさっき調べたら、その上司の方は、誰でも知ってるレベルの
      IT系企業のそこそこお偉いさんになってました。

  • by Anonymous Coward on 2019年07月25日 8時10分 (#3657679)

    C99 や C11 なんて認めない。
    (言語指定の話なので、これをコーディング規約というかどうかは知らんが……)

    /* さすがに K&R で書けと言われたことはない。 */

    ここに返信
    • by Anonymous Coward

      組込の世界では珍しいことではない
      ARMだとかはともかく、8bit/16bitの非力なプロセッサでは最新の規格に準拠したコンパイラが無いこともある
      LinuxやWindowsでバリバリ開発やってる人が、中小企業や個人が販売してる組込プロセッサ向けのコンパイラを使ったら発狂するだろう
      そういうコンパイラはプロセッサ(ハードウェア)に特化した独自の仕様拡張も多い

    • by Anonymous Coward

      ANSI Cも C99になってるから、ANSIだと言われても C99は使っていいはず。

  • by Anonymous Coward on 2019年07月25日 9時25分 (#3657722)

    やめてくださいおねがいします

    ここに返信
    • by Anonymous Coward

      どうしてですか?

      • by Anonymous Coward on 2019年07月25日 10時36分 (#3657787)

        Microsoft系で一時期非常に広がっていたシステムハンガリアン記法のことでは?
        あれは害悪でしかないので、当然やめるべき。
        Microsoftも最終的に心を改めて、非推奨にしたはず。

        同じくMicrosoftで生まれたアプリケーションハンガリアン記法(こちらが元々のハンガリアン記法)の方は
        有用なので、やめる必要はないですね。

        システムハンガリアン記法とアプリケーションハンガリアン記法の違いについては
        Joel Spolsky の間違ったコードは間違って見えるようにする [joelonsoftware.com]が詳しいです。

        • by marimoo (46364) on 2019年07月25日 15時23分 (#3657988)

          アプリケーションハンガリアンにしても、本来は型システムで解決すべき問題なのでは?

          そもそも今時あんまり見かけないのは同じですし。

          1人の人が一度アプリケーションハンガリアンならOKと言ったからと言って、
          いかなる場所でも永久にOKと言う話になっているのに違和感を感じる。

      • by Anonymous Coward on 2019年07月25日 11時04分 (#3657815)

        元ではないが、ハンガリアン記法使うと、変数の型が変わると変数名も変える必要がでるから、
        ハンガリアン記法はオレもやめて欲しい。

        これが、グローバル変数とかクラスの変数とかだったりすると、修正が多岐に渡り過ぎて嫌になる。
        グローバル変数とかクラスの変数の型を変えるなら、使ってる関数も直す必要があるのは分かるが、
        全ての変数名なんか変えてられんし、変数名変えたら関数の中にも影響するし。

typodupeerror

日々是ハック也 -- あるハードコアバイナリアン

読み込み中...