パスワードを忘れた？ アカウント作成
Close
12559658 story
プログラミング

ついつい使ってしまうプログラミングの悪いテクニックは？ 188

ストーリー by headless
悪癖 部門より
プログラミングの際に、さまざまな理由でコーディングのルールを破ってしまうことがある。これらは誰もが「悪い」プログラミングテクニックであると認めるようなものだが、結果としてコードがクリーンになり、高速かつシンプルになることもある。InfoWorldの記事では、愛される悪いプログラミングテクニックを9つ選んでいる。

InfoWorldが選んだ悪いプログラミングテクニックは以下の通り。
  1. gotoを使う
  2. 関数名だけで内容がわかるようにしてドキュメンテーションを避ける
  3. 1行に大量のコードを詰め込む
  4. 型宣言をしない
  5. 値の型を繰り返し変換する「ヨーヨーコード」
  6. 独自のデータ構造を書く
  7. ループの半ばでループを抜ける
  8. 短い変数名を使う
  9. 演算子や関数を再定義する

プログラミング言語や環境によっては使用できないものもあるが、皆さんがよく使うものはあるだろうか。また、リストに追加するとしたらどのようなものがあるだろう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

ついつい使ってしまうプログラミングの悪いテクニックは？ More

  • コピペ (スコア:3)

    by iwakuralain (33086) on 2015年10月24日 19時30分 (#2905889)

    コーディングのルールなのでちょっと違うか…

    • Re:コピペ (スコア:2)

      by t-wata (10969) on 2015年10月25日 0時54分 (#2906050) 日記

      あるある。
      共通処理考えるのめんどくさいから、まるっとコピペして一部書き換えた程度のものを作ってしまうときあるわ。

      シェア
      親コメント

      • Re:コピペ (スコア:1)

        by shibuya (17159) on 2015年10月25日 1時11分 (#2906057) 日記

        ＞まるっとコピペして一部書き換え

        共通処理にとどまらない発展形を実現しようとがんばれば、例えばMDISの図書館システムパッケージのようなしろものが花開くそうです…4年前の旧聞ですけどね。
        もっと新しいものがあったら知りたい。

        シェア
        親コメント

  • 手続き型プログラミングとオブジェクト指向プログラミングの両方が可能な言語の場合、作法が混在してしまうことがよくあります。

    大きな実害は無いですが、気分が悪いです。

  • nullの多用 (スコア:2)

    by srad (47258) on 2015年10月25日 12時48分 (#2906220)

    空の値、確定する前の値、適用不能なもの、域外値、例外で返す値、その全てを null で表してしまう。

    --
    アレゲなニュースと雑談サイト

  • > 6.独自のデータ構造を書く
    > 7.ループの半ばでループを抜ける

    これって駄目だったんだ？
    普通にやってしまってるけど……。

    6番のデータ構造を書くっていうのが漠然とし過ぎて、具体的にどんなデータ構造を書いてどのように使ったらどう悪いのかわかんないなぁ。
    メソッドを持たないクラスを書いたらそれもデータ構造だと思うけど、それも駄目って事？
    構造体だけを言ってるんなら、何故に構造体だけ駄目なのか？　……うーん、わからない。
    原文も読んでみたけど、どうも……要約すると
    「大体のデータ構造は既に用意されてるからそれ使えや」
    って事かな。英語苦手なので解釈おかしいかも知れないけど。
    でも、用意されてないデータ構造なんていくらでもあるし……。
    もっと原始的な話でリスト構造とかの再実装をするなって言うならわかるし、それは僕も稀にしかやってない。
    (標準の連想配列が要件を満たさなくて、色々ごちゃごちゃといじった事がある程度)

    あと、ループを途中で抜けるのも。
    そんなにコードの可読性下げてるとは思えないけど……。
    そう思ってるのは僕だけで、みんな読み辛いのかなぁ？

    • 単に、既存のライブラリで使える構造体を独自に実装するなってだけかと。
      で、余計な機能が付いてる駄目ライブラリなら無視して良いって、原文には書いてる。

      あと、ループを抜ける件については、「ループを抜ける理由を書け」って事らしい。
      で、フラグ命名に抜ける理由を付けると可読性が上がるよって事だって。

      でも個人的には、フラグ乱立の方がよっぽど危険だと思う。ま、この辺はケースバイケースだが。

      --
      -- Buy It When You Found It --
      シェア
      親コメント

    • 6はもしかすると、
      「この関数に渡す時だけに適用されるルールがある謎文字列」とか「オレオレJSONモドキ」とかのような、負の遺産まっしぐらなヤツを言っているのかもしれない。。。

      7は私もよく使う。
      もちろん1ループ単位で綺麗に終了条件が定まるフローを作るのが基本だけど、
      「これ以降は処理しないでねフラグ」みたいなのを使うより、途中でぬける方がよほど好ましいと思う。

      シェア
      親コメント

    • Re:大体はやってないけど (スコア:1)

      by Anonymous Coward on 2015年10月24日 20時04分 (#2905921)

      冒頭の内容からも、それぞれのルールにたいするコメントからも、「XXXというルールがあるけど、破ったほうが良いときもあるよな！？破っても良いけど上司には黙っとけよ！」っていう記事に読めます。

      たとえば、6については、要件を満たす上で標準ライブラリや広く知られているライブラリでは十分でない時に限って、データ構造を当たらしく作っても良いと書いてありますね。

      7も同様で、ループの不変条件だけで制御しようとするとgoto禁止と同様な冗長な表現になるので問題だと有ります。

      シェア
      親コメント

  • #defineがあれば、何でも出来る (スコア:1)

    by Anonymous Coward on 2015年10月24日 20時19分 (#2905934)

    #define private public

    #include "hoge/hoge.h"

    これで秘匿関数呼びたいホーダイ。

    • Re:#defineがあれば、何でも出来る (スコア:3, 参考になる)

      by Egtra (38265) on 2015年10月25日 1時48分 (#2906062)

      ちなみに、少し前からVisual C++には#define private public対策が入っています。

      #define private public
      #include <iostream>

      これをコンパイルすると、このようにコンパイルエラーとなります。

      T:\>cl /c hoge.cpp
      Microsoft(R) C/C++ Optimizing Compiler Version 19.00.23026 for x86
      Copyright (C) Microsoft Corporation.  All rights reserved.
       
      hoge.cpp
      C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xkeycheck.h(214): warning C4005: 'private': マクロが再定義されました。
      hoge.cpp(1): note: 'private' の以前の定義を確認してください
      C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xkeycheck.h(250): fatal error C1189: #error:  The C++ Standard Library forbids macroizing keyword
      s. Enable warning C4005 to find the forbidden macro.

      まあ、ヘッダーでの対処なので、インクルードよりあとに#define private publicすると回避できるのですが。

      シェア
      親コメント

    • マクロなら、OKだけど、関数は無理。 (C/C++)
      リンク時に相手がいない。

      シェア
      親コメント

  • optionalでこっそり引数を増やす (スコア:1, おもしろおかしい)

    by Anonymous Coward on 2015年10月24日 23時07分 (#2906005)

    ごめんなさい

  • 既存の機能を使わない (スコア:1)

    by Anonymous Coward on 2015年10月25日 3時33分 (#2906100)

    「既存の機能を使わない」、いわゆる車輪の再発明。

    ・日時や時刻の計算を自作ルーチンで行なう
    「n日前」だとか「指定日の午前0時ジャストをUNIX秒で」とか「UNIX秒→YYYY/MM/DD hh:mm:ss」とか。
    よくみれば、1か月を31日決め打ち(他との兼ね合いでこれでも動く)とか、うるう年を考えていないとか。

    ・配列やリストやセット(データ構造)の全体の処理をループでやっちゃう
    処理順が関係ないものも、mapやfindを使わない。まあ動きますがね。

    ・SQLで集約せずに、呼び出した言語側で集約する
    (上の2つとはカテゴリが違うかも)

  • 何も考えていません (スコア:1)

    by ksyuu (4917) on 2015年10月25日 11時23分 (#2906172) 日記

    ググってコピペ。

  • プログラミングの処方箋 (スコア:1)

    by Anonymous Coward on 2015年10月25日 13時28分 (#2906246)

    ストーリーにあるような、効果はあるけど乱用すると害を引き起こすテクニックを
    うちでは薬になぞらえて処方箋と呼びます。

    処方箋はとある課題に対して目に見える効果があります。同時に、取るに足らない(と感じる)副作用が付随します。
    乱用するなどして条件が揃うと、害をなします。複数同時にかけあわせると、思わぬ副作用を引き起こすこともあります。
    継続して使うと麻痺して、問題とも思わなくなります。

    本物の薬は、医者が症状を判断して病人に処方します。
    プログラミングでは、病人が自分自身に処方します。
    その結果、症状に合わない処方を使っていることもあれば、逆に、規約などで一律に禁じられ、症状が出ても放置するしかないこともあります。
    どちらも不健全です。

    プログラミングの世界に医者はいません。
    病気があれば自分で調べて治療することが求められます。
    悪だが使わざるを得ないテクニックのリストがもっと広まると、苦しむ人が減ると思います。

    処方を守って、必要な時に必要なだけ使うのが正しい使い方です。

typodupeerror

一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy