프로그래밍에서 정말 악한 것이 있습니까? [닫은]

따라서 X 악, Y 악이라고 묻는 많은 질문이 있습니다.

내 견해로는 언어 구성, 알고리즘 또는 사악한 것이 없으며 잘못 사용되는 것만 있다는 것입니다. 지옥, 당신이 충분히 열심히 보인다면 goto의 유효한 사용법 조차 있습니다.

그렇다면 절대 악은 모든 모범 사례와 완전히 호환되지 않는 것이 프로그래밍에 존재합니까? 그리고 그렇다면 무엇입니까? 아니면 무언가가 언제 적절한 지 모르는 것은 나쁜 프로그래머입니까?

편집 : 분명히, 프로그래머가하는 일에 대해 이야기하고 있지 않습니다 (예 : 리턴 코드를 확인하지 않거나 버전 제어를 사용하지 않는 것-나쁜 프로그래머가 선택한 것). 도구, 언어, 문장 등을 의미합니다. 나쁜...

1. 마법의 숫자.
2. 내재 성은 본질적으로 악이며, 그 이유는 다음과 같습니다.

프로그래밍에는 진정한 악이 없습니다.

<랜트>

많은 사람들이 악한 일이 있다고 생각하는 이유는 프로그래밍 수업을 처음들을 때 머리에 뭉개져 있기 때문입니다. "goto를 사용하지 마십시오! 항상 데이터베이스를 정규화하십시오! 절대로 다중 상속을 사용하지 마십시오!" 이러한 "악한"관행은 본질적으로 나쁘지 않기 때문에 쉽게 악용 될 수 있기 때문입니다. 처음에는 "never"라고 말하면 도망 갈 수있는 용도가 너무 적습니다. 무엇이 진정으로 악이 있기 때문에, "이 아닌 '모범 사례'는 무엇을 고려해야 할 이유가 없다"며입니다 항상 바로 그 방법은 완벽한 장소가.

</ rant>

총은 사람을 죽이지 않으며 사람들은 사람을 죽입니다.

마찬가지로 개발자 도구도 악한 것이 아니며 프로그래머가 할 수있는 일도 마찬가지입니다.

프로그래밍에서 정말 악한 것이 있습니까?

물론. 당신의 두뇌를 사용하지 않고 당신이하고있는 일과 왜 그것을하고 있는지에 대한 생각은 모든 프로그래밍 악의 근원입니다 .

빈 일반 예외 처리기 :

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 표준위원회가 공식적으로 폐기 한 것은 악한 일이며, 다음 버전의 표준에서 나올 것으로 예상됩니다. - 그 하나의 라이브러리 호출로 인한 신체 상해는 레거시 코드의 30 년 이상 '의 가치를 파괴의 전망보다 더 무서운이다 입니다 그것이 얼마나 악한.

IBM Rational ClearCase는 쉬운 일입니다.

그렇다면 절대 악은 모든 모범 사례와 완전히 호환되지 않는 것이 프로그래밍에 존재합니까?

당연히 아니지. 내 툴박스에 악의적 인 것이 있는지 묻는 것과 같습니다. 내 4 살짜리 아이가 손을 잡지 않으면 내 망치는 나에게 큰 "좋은"것입니다.

오늘의 악은 어제 완벽했습니다. 진화입니다.

너무 진지하지는 않지만 ...

우리는 "악"에 대한 매우 근시적인 견해를 가지고 있습니다. 다른 사람들을 많이 죽이는 사람들은 사악합니다. 다른 사람을 훔치는 사람들은 악합니다. 내가 아는 모든 나라는 과거에 약간의 악을 가지고 있습니다. 일부는 그것을 거부하고 싶습니다.

프로그래밍에 악이 있습니까? 우리의 무고한 프로그래머는 "실제로"생각하지 않을 수 있습니다. 그러나 일단이 주제에 대해 널리 사용되는 계층 데이터베이스의 발명자와 대화를 나눈 적이 있습니다. 누가 최고의 고객인지 알고 싶습니까? 공산주의 폴란드의 비밀 경찰.

지금 세상에 악이 있습니까? 물론이지. 그리고 그들은 프로그래머를 사용하고 있습니까? 물론이지.

널은 악의 뿌리입니다!

https://softwareengineering.stackexchange.com/questions/22912/null-references-the-billion-dollar-mistake-closed

십억 달러의 실수 :나는 그것을 10 억 달러의 실수라고 부릅니다. 그것은 1965 년에 null 참조의 발명이었다. 당시 나는 객체 지향 언어 (ALGOL W)로 참조 할 수있는 최초의 포괄적 인 타입 시스템을 설계하고 있었다. 필자의 목표는 컴파일러가 자동으로 검사를 수행하여 모든 참조 사용이 절대적으로 안전하도록하는 것이 었습니다. 그러나 구현하기가 쉽기 때문에 null 참조를 넣는 유혹에 저항 할 수 없었습니다. 이로 인해 수많은 오류, 취약성 및 시스템 충돌이 발생하여 지난 40 년간 수십억 달러의 고통과 피해를 초래했을 수 있습니다. 최근에는 Microsoft의 PREfix 및 PREfast와 같은 여러 프로그램 분석기가 참조를 확인하는 데 사용되었으며 null이 아닐 수있는 위험이있는 경우 경고를 표시합니다. Spec #과 같은 최신 프로그래밍 언어는 널이 아닌 참조에 대한 선언을 도입했습니다. 이것이 1965 년에 거부 한 해결책입니다. CAR Hoare, 2009

코드를 복사하여 붙여 넣습니다.

그렇게 할 때 가려워하지 않으면 실제 프로그래머가 아닙니다.

나는 개인적으로 도널드 크 누스 (Donald Knuth)의 문구를 발견했다. 경험이 풍부한 관점에서 (이것은 내가 실패했다고 말한다).

실제로, 문구는 다음과 같이 말합니다. 문제에 깊이 들어가기 전에 특정 환경, 특정 PC 또는 사용자 집합의 문제를 이해하려고 시도하지 마십시오.

아무도 Globals를 진정한 악으로 띄우지 않은 것에 놀랐습니다. 매개 변수에 대해 전혀 모르고 매개 변수에 대해 실제로 제어 할 수없는 환경에서 프로그래밍하는 더 좋은 방법은 없습니다. 혼돈! 모든 코딩에서 전역 변수 사용을 엄격히 금지합니다.

도구는 본질적으로 악하지 않습니다. 그것의 존재는 하나의 유스 케이스를 제외하고는 모두 어리석은 것일 수 있지만 그것이 악을 일으키지는 않습니다. 프로그래머에게 적절한 사용을 결정해야 할 책임이 있습니다.

글쎄, 나는 마이크로 소프트가 사악하다고 여겨졌 고 최근에는 오라클이 세상에서 가장 사악한 것이라고 생각했다 .

나는 내가 게시물을 만들지 않겠다고 말했지만 한 가지 답을 쓸 것이다. 다른 사람들이 아무 악도 없다고 말한 것처럼 나는 절대 악이 있다고 말할 것이다

Setjmp / LongJmp 는 순수한 악입니다.

중복 코드는 매우 악합니다.

FAQ는 "그와 같은 것은 악하다"는 무엇을 의미합니까?

그것은 그런 것을 의미하며 그런 것은 대부분 피해야하는 것이지만 항상 피해야하는 것은 아닙니다. 예를 들어, "악한 대안 중에서 가장 악한 것이 가장 적을 때마다" "악한"것을 사용하게됩니다. 농담이야, 알았지? 너무 심각하게 생각하지 마십시오.

어떤 도구는 선과 악에 사용될 수 있지만 , 일부 도구 는 자주 사용하지 않는 프로그래머를 놀라게하기 때문에 악합니다.

32 비트보다 짧은 정수로 작업 할 때 Java 악의 부호없는 오른쪽 시프트 연산자 (>>>) (놀랍게도 부적절한)를 고려합니다.

값이 -1 인 바이트 b가 있다고 가정하십시오.

byte b = -1;  // binary: 1111 1111

부호없는 오른쪽 시프트 연산자는 0을 가장 왼쪽 비트로 이동합니다. 따라서 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

'예상대로'작동하도록합니다.

나는 이것을 돌아 서서 절대 악이 없지만, 두개골 크기 가 한정된 우리의 연약한 사람들 이 다른 사람들보다 실수를 저지르는 것을 더 그럴듯하게 만드는 도구와 구조물이 있다고 말할 것입니다.

그래서 사람들이 실수를 저지르는 확률에 따라 구조물 의 악 에 대해 이야기 할 수 있다고 말하고 싶습니다 . 물론 칼이나 칼날로 그립을 사용하여 전기 톱으로 빵을자를 수는 있지만, 충분히주의해서 잡아 당길 수는 있지만 다른 것보다 손상을 입을 가능성이 더 큽니다.

영어가 아닌 모국어로 코딩하고 모국어로 문서를 작성하십시오. 그런 다음 프로젝트를 인도 회사에 아웃소싱하십시오.

그것은 당신에게 악하다!

추신 : 기록을 위해, 그것은 일어나고, 인디언은 그다지 웃기지 않았다.

나는 계속해서 말하기를 원하지만 정답은 프로그래밍에 객관적이고 절대적인 악이 없다는 것입니다. 반면에 최고의 도구조차도 남용 될 수 있습니다.

프로그래밍 그 자체는 본질적으로 악한 것이 아니라고 생각합니다. 그러나 프로그래밍은 종종 사회 활동이며, 주변 사람들을 무시하는 것은 매우 악할 수 있습니다. 사람들은 대부분의 코드가 다른 사람들과 공유 될 것이라는 사실을 종종 잊습니다. 대부분 읽기도하고 때로는 쓰기도합니다. 오픈 소스, 회사가 출시하는 제품 또는 컨설턴트를위한 작은 패치 작업을 위해 프로그램을 읽을 수 있습니다.

그것이 많은 "유해한 것으로 간주되는"기사가 존재하거나 사람들이 "never"라고 말하는 이유의 절반입니다. 다른 사람을 위해 인생을 어렵게 만드는 것은 모든 악의 근원입니다. 그렇지 않습니까?

그렇습니다. 많은 악이 있습니다. 예를 들면 다음과 같습니다.

Type1 variable1 = function12()
variable5 = variable1.myMethod(variable1+aGlobal);
variable2.otherMethod(anotherGlobal);

불충분 한 이익을 위해 시스템의 총 비용을 늘리십시오. 너무 많은 복사 및 붙여 넣기, 너무 복잡한 아키텍처 또는 값 비싸지 만 비효율적 인 상업용 제품을 사용할 수 있습니다. 일반적으로 모든 소프트웨어 기술은 시스템의 총 비용을 줄이는 데 목적이 있으며, 너무 비싼 시스템으로 끝내면 잘못되었습니다.