プログラミングに何か悪いことはありますか？
したがって、Xの悪、Yの悪を問う質問がたくさん表示されます。
私の見解では、言語の構成、アルゴリズムなど、悪であるものはなく、悪用されているものだけです。地獄、あなたが十分に一見すると gotoの有効な使用法 さえあります。
それで、絶対的な悪、それはすべての場合のベストプラクティスとまったく互換性のないものであり、プログラミングに存在しますか？もしそうならそれは何ですか？それとも、適切な時期を知らないプログラマは悪いのでしょうか？
編集：明確にするために、私はプログラマーが行うこと（リターンコードをチェックしない、バージョンコントロールを使用しないなど-それらは悪いプログラマーによる選択です）について話しているのではなく、ツール、言語、ステートメントなど、悪い...
- マジックナンバー。
- 暗黙性は本質的に悪であり、ここに理由があります：
プログラミングには真の悪はありません。
<暴言>
邪悪なことがあると多くの人が思う理由は、プログラミングクラスを最初に受講したときに頭にぶつかるからです。 「gotoを使用しないでください。常にデータベースを正規化してください。絶対に多重継承を使用しないでください！」これらの「悪」な慣習は、本質的に悪いからではなく、簡単に悪用されるからです。それらの使用法は非常に少ないため、最初は「絶対に」と言っても問題はありません。 「always」がまさに完璧な場所があるので、本当に悪いことは「「ベストプラクティス」ではないことを考える理由は何もない」と言っています。
</ rant>
銃は人を殺さない、人は人を殺す。
同様に、開発ツールは悪ではなく、プログラマーが開発ツールで行うことは可能です。
プログラミングに何か悪いことはありますか？
絶対に。脳を使用せず、何をしているのか、なぜそれをしているのかを考えることに失敗することは、allプログラミングのルーツです悪
空の一般的な例外ハンドラー：
catch(Exception ex)
{
}
誰かが私に有効なユースケースを与えることができることは間違いありません-正直なところ、それは真剣に創造的です...そして少なくともあなたは説明が必要です。
おそらく私は質問を逆にして、プログラミングに絶対におよび完全に良いものがあるかどうか尋ねることができますか？あなたが一つのことを考えることができない場合（私は私ができないことを知っています）、悪の概念もまた泥だらけです。
間違い、誤解、その他の一般的な混乱につながる一般的な動作がありますが、言語機能Xは本質的に悪であると言うのは、機能Xの目的を本当に理解していないことを認めることです。
多くの心痛を軽減し、いくつかの誤解を回避できる一般的な動作がありますが、言語機能Yが本質的に優れていると言うことは、機能Yの使用のすべての影響を完全に理解していないことを認めることです。
私たちは有限の理解と強い意見を持つ人々です-危険な組み合わせです。双曲線は、私たちの意見を表現するための単なる方法であり、事実がフィクションになるまで激怒します。
それでも、問題を引き起こす行動を回避し、それを回避する行動を追求できれば、もう少し生産性が上がるかもしれません。結局のところ、それがすべてです。
思い浮かぶ唯一のものはこれです：
#DEFINE TRUE FALSE
#DEFINE FALSE TRUE
しかし、繰り返しますが、それは単なる昔ながらの誤用です。
スキニング、システムトレイに常駐する自動アップデーター、ファイルの関連付けやその他のシステム設定をハイジャックするアプリケーションは、まさに悪だと思います。
フラッシュのみのウェブサイトと一緒に。
偶然に起こったことすべては本質的に悪です。
デフォルトのコンパイラオプションを使用して、実際に私のマシンで動作する次のCプログラムについて考えてみましょう。
#include <stdio.h>
int main(int argc, char *argv[]) {
char string[10];
int y;
for (y=0; y<10; string[12]++) {
printf("%d\n", y);
}
}
このプログラムがループカウンターをインクリメントする方法を言い訳することはできません。私のマシン、コンパイラー、デフォルトのオプションでたまたま正しいことをするのは、未定義の効果です。
それで、絶対的な悪、それはすべての場合のベストプラクティスとまったく互換性のないものであり、プログラミングに存在しますか？もしそうならそれは何ですか？
はい;標準Cライブラリ関数gets()。 C標準委員会が正式に非推奨にしたのは悪いことであり、次のバージョンの標準からなくなる予定です。その1回のライブラリ呼び出しによって引き起こされる騒乱は、30年以上の価値のあるレガシーコードを壊すという見通しよりも恐ろしい-that'sそれがどれほど悪であるか。
簡単ですが、IBM Rational ClearCaseは残虐行為です。
それで、絶対的な悪、それはすべての場合のベストプラクティスとまったく互換性のないものであり、プログラミングに存在しますか？
もちろん違います。それは、私のツールボックスの何かが悪かどうかを尋ねるようなものです。私の4歳のハンマーが手に取らない限り、私のハンマーは私にとって素晴らしい「良い」ものです。
今日の悪は昨日完璧だった。それは進化です。
あまり真面目ではありませんが...
私たちは「悪」について非常に近視的な見方をしています。他の多くの人々を殺す人々は悪です。他人から盗む人は悪です。 （私が知っている）すべての国には、過去にいくつかの悪があります。それを否定したい人もいます。
プログラミングに悪はありますか？私たちの無実のプログラマーは、「実際にはそうではない」と考えるのが好きかもしれません。ただし、このテーマについて、広く使用されている階層型データベースの発明者と話をしたことがありました。最高の顧客の1人が誰なのか知りたいですか？共産主義ポーランドの秘密警察。
今、世界に悪はありますか？あなたは賭けます。そして彼らはプログラマーを使っていますか？あなたは賭けます。
ヌルは悪の根です！
10億ドルの間違い：私はこれを10億ドルの間違いと呼んでいます。それは1965年にnull参照の発明でした。当時、私はオブジェクト指向言語（ALGOL W）での参照用の最初の包括的な型システムを設計していました。私の目標は、コンパイラーによって自動的に実行されるチェックにより、参照のすべての使用が絶対的に安全であることを確認することでした。しかし、実装が非常に簡単だったという理由だけで、null参照を挿入するという誘惑に抵抗できませんでした。これにより、無数のエラー、脆弱性、システムクラッシュが発生し、過去40年間で10億ドルの苦痛と損害を引き起こした可能性があります。近年、MicrosoftのPREfixやPREfastなどのプログラムアナライザーが参照のチェックに使用され、nullでない可能性がある場合は警告が出されます。 Spec＃などの最近のプログラミング言語では、null以外の参照の宣言が導入されています。これが私が1965年に却下した解決策です。C.A.R。 Hoare、2009
コードをコピーして貼り付けます。
あなたがそうしているときにかゆみを起こさなければ、あなたは本物のプログラマではありません。
私は個人的に、ドナルドクヌースのフレーズを見つけました。「時期尚早な最適化は、すべての悪の根源である」というのは、プログラミングの最初の悪事です。経験豊富な視点で（つまり、私はこれに失敗したと言います）。
実際、このフレーズは次のようなものです。特定の環境、特定のPC、または一連のユーザーの問題を深く理解する前に、理解しようとしないでください。
Globalsを真の悪として浮かび上がらせた者がいないことに驚きます。パラメータがわからない環境でプログラミングを行うのに最適な方法はありません。また、パラメータに何が起こるかを実質的に制御できません。混沌！私はすべてのコーディングでグローバル変数を使用することを厳しく禁止しています。
本質的に邪悪なツールはありません。その存在は、単一のユースケースを除いてすべて愚かなかもしれませんが、それはそれを悪にしません。それはプログラマに適切な使用を決定する責任を負わせます。
FAQは「そのようなものと悪いもの」とはどういう意味ですか？
これは、そのようなことはほとんどの場合避けなければならないことですが、常に避けなければならないことではありません。たとえば、これらの「邪悪な」ものは、「邪悪な選択肢の中で最も邪悪なもの」ではない場合はいつでも使用することになります。 冗談ですよね？あまり真剣に受け止めないでください。
冗長なコードは非常に悪です。
まあ、私はマイクロソフトが悪と見なされている/されていたと思っていましたが、最近では Oracleは世界で最も邪悪なものです 。
投稿しないと言っていましたが、1つ回答を書きます。他の誰もが悪はないと言っているのと同じくらい私ははい、絶対的な悪がいくつかあると言います
Setjmp/LongJmp は悪です。
母国語（英語ではない）でコーディングし、母国語でドキュメントを作成します。そして、プロジェクトをインドの会社に外部委託します。
それはあなたにとって悪です！
PS：記録のために、それは起こりました、そしてインディアンはそれをそれほど面白いとは思いませんでした。
どのツールもsedで善悪に使用できますが、一部のツールareは、頻繁に使用しないプログラマーを驚かせるので悪です。
32ビットより短い整数を処理する場合、Java evil（驚くほど不適切））の符号なし右シフト演算子（>>>）を検討します。
値-1のバイトbがあるとします。
byte b = -1; // binary: 1111 1111
符号なし右シフト演算子は、ゼロを左端のビットにシフトします。したがって、1になるのは7シフトと仮定します。
b >>>= 7; // binary: 0000 0001 ?
しかし、代わりにこの操作は何もしません。 bはまだ-1です。
次の25シフトのすべてでさえ何もしません。
byte b = -1;
for (int i = 0; i < 25; ++i) {
b >>>= i;
System.out.println(b); // always outputs -1
}
これは、b>>>=7大まかに変換
1111 1111
1) the byte gets widened to a 32 bit int to make shifting possible
1111 1111 1111 1111 1111 1111 1111 1111
2) the shift happens
0000 0001 1111 1111 1111 1111 1111 1111
3) the resulting int gets narrowed to a byte again
1111 1111
交換する必要があります
b >>>= i;
沿って
b = (b & 0xFF) >>> (i % 8); // >> would also work this time
「期待どおり」に機能させるため。
私はこれを振り返って、絶対的な悪はないが、そのような微弱な人間のためにそれをもっともらしいにするツールと構成があると言いますa 限られた頭蓋骨のサイズ 他のものより間違いをするため。
だから私はあなたが人がそれを間違える可能性に基づいて構成の悪について話すことができると思います。確かに、ナイフやブレードをグリップにしたチェーンソーを使ってパンを切ることはできますが、慎重に引っ張ることはできるかもしれませんが、一方が他方を損傷する可能性が高くなります。
不十分な利益のためにシステムの総コストを増やす。コピーと貼り付けが多すぎる、アーキテクチャが複雑すぎる、または高価であるが効果のない商用製品を使用している可能性があります。一般的に言って、すべてのソフトウェア技術はシステムの総コストを削減することを目的としており、非常に高価なシステムになってしまうと、間違ったことになります。
プログラミング自体は、本質的に悪ではないと思います。しかし、プログラミングは社会活動であることが非常に多く、周囲の人を軽視することは非常に悪いことです。ほとんどのコードが他の人と共有されることを人々はしばしば忘れます。主に読む、時には書くこともある。それがオープンソースであろうと、企業がリリースしている製品であろうと、コンサルタントにパッチを当てるための小さな断片であろうと、プログラムが読まれるでしょう。
これが、「有害であると考えられる」記事が非常に多く存在する、または人々が「決して」と言わない理由の半分です。他人にとって生活を困難にすることは、すべての悪の根源です。だよね？
期限が近づき、要件が変更され、設計が変更され、16時間オフィスで過ごす場合、それは悪いことです。
プログラミングには悪いことはあると思いますが、私はこの言葉を軽蔑的に使用していません。
悪とは、コードがある方法で振る舞うふりをするものですが、実際には非常に異なる方法で振る舞い、未開拓の合理的なプログラマーに害を与えます。私はこれを " Magic "のタイプと呼ぶことがよくあります。マジックとは、プログラマーに機能が隠されているもので、さまざまなスタイルがあります。
例：Schemeでは、関数「car」と「cdr」は関数のみを使用して実装できますが、そうではありません。代わりに、ほとんどのコンピューターでより高速に実行されるため、それらはより低いレベルで強制的に実装されます。これを「白魔術」と呼んでいます。それは悪ではありませんが、間違いなく魔法です。
比較すると、JavaScriptの一意の番号NANは、他の番号とは異なります。これが「黒魔術」です。なぜJavaScriptにNANがあるのか（またはInfinityとNaNの両方がある理由）の説明には触れたくありませんが、このような単純な概念が浮動小数点数のみの言語に役立つ理由を理解できます。ただし、他の定数と同じ方法でテストできない定数があることは、期待されるものではありません。幸い、JavaScriptはこの問題の解決に役立つisNANを提供しますが、NaNの一意のプロパティを知らない場合は、次のコードを記述して書き込みを行う可能性があります。
if(x == NaN)
またはあなたが賢いなら、あなたは同じ結果で以下を試すかもしれません
if(x === NaN)
私はこれを「マナが燃やされた」と言います（結局それは魔法です...）。
数値ではないものを自動的に同じにしたいのには理由がありますが、IEEE浮動小数点数の場合、NaNには特定のビットシーケンスがあり、この点で他の数値と似ていることに注意してください。 JavaScript NaNをIEEE浮動小数点NaNと同じように扱うと、やけどを負う可能性があります。これは欺瞞的でイライラするものであり、前者が私がこれをEvilと呼ぶ理由です。
それから、その可能な人々はそうではないと考えます...
はい、たくさんの悪があります。例えば：
Type1 variable1 = function12()
variable5 = variable1.myMethod(variable1+aGlobal);
variable2.otherMethod(anotherGlobal);
継続を言いたくなりますが、正しい答えはプログラミングには客観的で絶対的な悪はないということです。一方、最高のツールでさえ悪用される可能性があります。
プログラミングに何か悪いことはありますか？ツール、言語、ステートメント、なんでもいい
そのリストの何も悪いことではありません。これが理由です。
人間は自由意志を持った存在として創造されました。彼らは自分の力を使ってダークサイドに行ったり、ライトサイドを受け入れたりします。この選択は、彼らの手から出てくるものを定義します。
現在、これらのツールとフレームワークは、善意をもって何らかの形で物事をより良いものにしようと真剣に取り組んでいる慈善的な人々によって作成されました。その結果、彼らの創造物（成功したかどうかは関係ありません）は悪の痕跡を負いません。少なくとも中立ですが、悪意はありません。
次に、それらのツールは他の個人の手に渡ります。そして彼らが彼らと何をするかはそれらの人々に依存します。デバッガでさえ、一部のソフトウェアでシリアル番号のチェックを削除しようとするハッカーの手に渡って、悪用される可能性があります。
ただし、ツールの特性を再定義するものではありません。彼らはすべて良いです。便利なものもあれば、使いにくいものもあります。危険なものもあれば、少ないものもあります。しかし、それでも、これらはすべて優れており、特定のシナリオでは非常に便利です。
また、誤ってプログラマーがツールを誤用して損傷を与えたとしても、ツールが悪になることはありません。それはただのプログラマのミス、知識の欠如、無知などです。しかし、悪意はありません。
結論は、すべてのツールが優れているということです。私たちはそれらすべてを愛さなければなりません。
客観的な絶対的な悪はありません。
GOTOなどの問題は、厄介な方法で使用するのが非常に難しいことです。コードニオイではないGOTOの例を考えるのは難しいので、今ここに座ってください。しかし、私はそのような用途があるかもしれないこと、そして問題はツール自体ではなくむしろその乱用の可能性であることを受け入れたいと思っています。
予期しない場所で目に見える副作用。
。Netでは、例はToString()、Equals()/GetHashCode()、プロパティゲッター、および暗黙の変換です。
（明確にするために、私は遅延インスタンス化またはロギングコード以上のものについて話している）
throw new Exception(ex.Message);
一部のプログラミング命令/スタイル/規則は、コーディングするとひどく悪になりますが、マスタープログラマーの手によって非常にエレガントな方法で使用できます。
一方、最高のツールや言語などを使用してコーディングしても、無能なプログラマーや経験の浅いプログラマーが悪い悪を生み出すのを防ぐことができるものは何もありません。
Gotoなどのよく誤用される要素を回避することで、平凡なプログラマーが悪を回避し、おそらく優れたコードを簡単に記述できるようになることが期待されます。
私は c ++ FAQ に同意します：
[6.16]いわゆる「悪」な構造を使用することがありますか？
もちろんそうします！
1つのサイズですべてに対応できるわけではありません。やめる。今、細かい点のマーカーを取り出し、メガネの内側に書き込みます。ソフトウェア開発は意思決定です。 「考える」は4文字の言葉ではありません。ソフトウェアには「決して...」と「常に...」のルールはほとんどありません—考えることなく適用できるルール—すべての市場のすべての状況で常に機能するルール—万能のルール。
平易な英語では、意思決定を行う必要があり、意思決定の質はソフトウェアのビジネス価値に影響を与えます。ソフトウェア開発は、大部分がルールをたやすく従うことではありません。それは考えてトレードオフを作り、選択することの問題です。そして、時々あなたはたくさんの悪いオプションから選択しなければならないでしょう。それが起こるとき、あなたが望むことができる最高のものは、「悪魔」のより少ない、より悪い選択肢を選ぶことです。
「悪」のラベルが付いたアプローチやテクニックを時々使用します。それがあなたを不快にさせるなら、「悪」という言葉を「頻繁に望ましくない」に精神的に変えてください（しかし、著者になるためにあなたの一日の仕事をやめないでください：そのような人を眠らせるような言葉:-)
武器でさえ実際に悪であるものは何もありませんが、私たちは時々それらをそのように考えます。しかし、武器に関しては、私たちは通常ある程度の敬意を持っています。私たちはそれらの危険性を非常に認識しており、慎重に使用しています。しかし、それらを使用するにはあまりにも愚かな人々がまだいます。
同じことがすべてのツールに当てはまり、それらのツールを乱用した結果が困難であるほど、人々がそれらを乱用する可能性が高くなります。
プログラミングはすべてがほぼ仮想的であり、プログラムは私たちの思考プロセスの表現であり、何かを完全に理解しなかったり、少し間違ったものにしたりすることの長期的な影響は、判断するのがはるかに難しく、それから私たちが直面している死の即時の危険性銃を扱うとき。
これにより、使用して自由に使用できるツールが非常に使いにくくなりますが、プログラマーのスキルを測定する簡単な方法も得られます。あなたが持っているツールをいつどのように使用するかの知識は、優れたプログラマーになるために重要です。ツールのセットを制限することでいつでも安全にプレイできますが、すべてが釘のように見える人にのみ、最終的には、何の打撃でも修正できない何かに遭遇します。
唯一の「悪」は、特定のプログラミングのことは「悪」であると考えることです。さまざまなアプローチ-この手法を使用する、そのステートメントを使用しない、この方法論を使用する、その言語を使用しない、この「ベストプラクティス」を使用するなど-opinionsです。
残念ながら、あまりにも多くの開発者がopinionsをobjective trueと間違えています。
「なぜ[x]は悪と見なされるのですか？」などの質問が表示されるたびに、私はうんざりしています。
すべてが独自の有効な用途を持っているか、実装されていません。人々はそれを安全または適切な方法で使用しないため、物事は悪と呼ばれています。このことを考慮...
剣は悪ですか？いいえ。誰かが病院で刀を使おうとするからといって、それが悪であるとは限らない。缶切りは悪ですか？いいえ。
すべてが適切に使用されています。したがって、悪はありません。