사람들이 시도하는 많은 문제에 대한 실질적인 해결책은 아니지만 프로그래밍에 남용 (IE가 필요 이상으로 과도하게 사용) 또는 남용 또는 모든 것에 조금 사용 된 것으로 보이는 프로그래밍 기술이 있습니까? 그것으로 해결하십시오.

정규 표현식, 디자인 패턴 또는 알고리즘 또는 완전히 다른 것일 수 있습니다. 사람들이 다중 상속 등을 남용한다고 생각할 수도 있습니다.

코드의 주석

나는 대학 교수들이 학생들이 다음 코드가 1에서 x까지 반복되는 for 루프라는 10 줄의 주석을 쓰도록 가르 칠 필요가 없다는 것을 이해하기를 바랍니다. 코드에서 볼 수 있습니다!

먼저 자기 문서화 코드를 작성하고 적절하게 자기 문서화 할 수없는 것에 대해 적절하게 설명하도록 가르치십시오. 소프트웨어 세계가 더 나은 곳이 될 것입니다.

싱글 톤 디자인 패턴.

물론 유용한 패턴이지만 새로운 프로그래머가이 패턴에 대해 배울 때마다 자신이 만든 모든 단일 클래스에 적용하기 시작합니다.

바보 같은 프로그래밍을 보호하는 가장 악한 일. 시도 캐치에 모든 것을 넣고 캐치로 아무것도하지 않습니다.

        try
        {
            int total = 1;
            int avg = 0;
            var answer = total/avg;
        }
        catch (Exception)
        {

        }

나는 아무것도하지 않고 바보 같은 논리를 처리하도록 설계된 try catch를 볼 때 떨립니다. 일반적으로 try catch는 과도하게 사용되지만 경우에 따라 매우 유용합니다.

어려운 문제를 파악하는 대신 문제를 해결하기 위해 StackOverflow에 의존합니다.

SO에 대한 풍부한 지식을 찾는 새로운 프로그래머는 생각하고 시도하기 전에 게시물을 게시합니다.

하루는 책이나 인터넷, 코드를 코딩해야했습니다. 이제 내 잔디밭에서 내려

분명히. 매우 가치가 있지만 잘못 사용 하면 명확한 코드를 쉽게 숨기고 (R의 S4 프로그래밍의 일부 예가 떠오를 수 있음) 불필요한 오버 헤드를 줄 수 있으며 불필요한 오버 헤드를 제공하여 성능에 큰 시간을 소비 할 수 있습니다.

또 다른 것은 (예를 들어 Perl) OOP가 종종 같은 방식으로 다른 방식으로 작성하는 경우가 종종 있습니다. result = $object ->function(pars)대신에 result = function(object, pars)이것은 의미가 있지만 절차 적 프로그래밍과 혼합하면 코드를 읽는 것이 매우 혼란 스러울 수 있습니다. 그 외에도 디자인을 개선하지 않는 경우 더 많은 오버 헤드가 발생합니다. 싱글 톤 패턴에 대해서도 언급되어 있습니다. 모든 것이 아니라 사용해야합니다.

나는 OOP를 스스로 사용하지만, 내 분야 (과학 컴퓨팅) 성능은 큰 문제이며, 오늘날 모든 학생들이 Java를 얻음에 따라 OOP가 종종 남용됩니다. 더 큰 문제를 다루고 개념화하는 데 좋습니다. 그러나 BioPerl에서 DNA 서열로 작업하는 경우 매번 객체를 사용하고 게터 및 세터와 일관되게 작업하면 계산 시간이 10 배 증가 할 수 있습니다. 코드가 몇 시간이 아닌 며칠 동안 실행되면 그 차이가 실제로 중요합니다.

ASP.NET Webforms에서 몇 년을 보냈지 만 분명한 말을해야합니다.

스마트 UI

Webforms에서 계층화되고 테스트 가능한 응용 프로그램을 만드는 것이 전적으로 가능하지만 Visual Studio를 사용하면 개발자가 모든 UI 코드 주위에 응용 프로그램 논리가 흩어져있는 방식으로 한 번의 클릭으로 데이터 소스에 단단히 바인딩 된 양식을 만들 수 있습니다.

Steve Sanderson은이 안티 패턴을 Pro ASP.NET MVC 서적에서 할 수있는 것보다 훨씬 더 잘 설명합니다.

스마트 UI 응용 프로그램을 빌드하기 위해 개발자는 먼저 일련의 UI 위젯을 캔버스로 끌어 UI를 구성한 다음 가능한 각 버튼 클릭 또는 다른 UI 이벤트에 대한 이벤트 처리기 코드를 채 웁니다. 모든 애플리케이션 로직은 다음과 같은 이벤트 핸들러에 상주합니다. 사용자 입력을 승인 및 검증하고, 데이터 액세스 및 스토리지를 수행하고, UI를 업데이트하여 피드백을 제공하는 로직입니다. 전체 응용 프로그램은 이러한 이벤트 처리기로 구성됩니다. 기본적으로 이것은 Visual Studio 앞에 초보자를 둘 때 기본적으로 나타나는 경향이 있습니다. 이 디자인에서는 관심사가 분리되지 않습니다. 발생할 수있는 다른 UI 이벤트 측면에서만 모든 것이 통합되어 있습니다. 로직 또는 비즈니스 규칙을 둘 이상의 핸들러에 적용해야하는 경우 코드는 일반적으로 복사하여 붙여 넣습니다. 또는 무작위로 선택된 특정 세그먼트는 정적 유틸리티 클래스에 포함됩니다. 여러 가지 명백한 이유 때문에 이러한 종류의 디자인 패턴을 안티 패턴이라고합니다.

나는 때때로 이것을보고 부울 식을 완전히 이해하지 못했기 때문에 발생합니다.

if (someCondition == true)

코어의 존재에 대한 무지 또는 커스터마이제이션에 대한 인식의 필요성 때문에 코어 (또는 다른 방식으로 제공) 기능을 다시 구현 합니다.

계승.

이해가되지 않는 곳에 is-a를 강요하지 마십시오.

상용 소프트웨어 사용자 정의

이것이 유용 할 수 있음을 인정할 수는 있지만, 의심스러운 이익을 위해 적은 일을하는 데 얼마나 많은 돈이 소비되는지 궁금합니다. 여기에서 회사는 일부 소프트웨어의 라이센스에 수백만 달러가 아닌 수십만 달러를 소비 할 수 있으며,이 소프트웨어는 구성 가능하고 편집 가능하며 유연하여 기본적으로 실제로 많은 일을하지 않기 때문에 사용자 정의됩니다. 결국 모든 새로운 코드가 처음에 구입 한 것을 추가했기 때문에 맞춤형 응용 프로그램입니다.

컴파일러를 디버거로 사용합니다.

Complier 경고를 무시하거나 완전히 끄십시오.

글로벌 변수.

모든 디자인 패턴.

그들은 소금이나 설탕과 같습니다. 당신의 음식에있는 그들 중 일부는 그것을 훌륭하게 만들고, 많은 사람들이 음식을 짜증나게합니다.

내가 틀리지 마 디자인 패턴은 훌륭한 기술입니다. 나는 그들을 많이 사용했습니다. 그러나 때때로, 나는 "당신은 디자인 패턴을 사용해야합니다"라는 문제를 가진 프로그래머를 찾았습니다.

예를 들어 "선형 / 순차 컬렉션"에보다 적합한 "방문자 패턴"이 있습니다. 한 번 트리 데이터 구조로 작업해야했습니다. 각 항목을 "방문"하기 위해 비 디자인 패턴 방법을 코딩하고 전 상사는 "방문자 패턴"을 사용하거나 적용 할 것을 주장합니다. 그런 다음 두 번째 의견을 얻기 위해 인터넷을 탐색합니다. 글쎄, 다른 프로그래머들도 같은 상황과 같은 해결책을 가지고있었습니다. 새로운 디자인 패턴으로 "트리 / 계층 방문자 패턴"이라고합니다.

"디자인 패턴"책의 새 버전에서 기존 패턴에 새로운 패턴으로 추가되기를 바랍니다.

흐름 제어로 예외 사용 유사의 정렬 이 대답 하지만, 다른.

예외를 삼키는 것은 코드에서 신비하고 찾기 어려운 버그를 유발하기 때문에 나쁜 형태입니다. 반면에 흐름 제어로 예외를 사용하는 것은 코드를 훨씬 비효율적으로 만들고 개념적으로 부주의하기 때문에 좋지 않습니다.

예외 처리는 예상치 못한 예상치 못한 시나리오를 처리하는 데만 사용해야하며 숫자가 예상되는 알파벳 문자를 입력하는 사용자와 같은 것은 아닙니다. 이런 종류의 예외 남용은 Java 세계의 나쁜 프로그래머들 사이에서 매우 흔합니다.

과도한 데이터 숨기기를 통해 유연성을 가지려고합니다.

우리는 추상화와 구현을 숨기는 것이 좋지만 항상 더 나은 것은 아니라는 것을 알고 있습니다. 지나친 요구 사항의 변화에 ​​대처할 수없는 융통성없는 결과를 얻을 수 있습니다. 변경 사항을 처리하려면 해당 변경 사항을 처리해야하는 클래스를 수정해야 할뿐만 아니라 데이터 숨기기 계층에도 불구하고 액세스 할 수 없었던 정보에 대한 방법을 만들어야합니다.

문제는 모든 상황에 맞는 올바른 균형을 찾는 것과 마찬가지로 경험이 필요하다는 것입니다.

내부 배열 노출

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

http://www.oracle.com/technetwork/java/seccodeguide-139067.html 에 따르면

의도를 공유하지 않는 한 반환 가능한 가변 객체를 복사합니다.

가변 상태 및 루프. 거의 필요하지 않으며 거의 ​​항상 더 나은 코드를 얻습니다.

예를 들어, 이것은 StackOverflow 스레드에서 직접 가져옵니다.

// ECMAScript
var thing, things_by_type = {};
for (var i = 0; i < things.length; i++) {
    thing = things[i];
    if(things_by_type[thing.type]) {
        things_by_type[thing.type].push(thing);
    } else {
        things_by_type[thing.type] = [thing];
    }
}

# Ruby
things_by_type = {}
things.each do |thing|
  (things_by_type[thing.type] ||= []) << thing
end

그들은 모두 같은 일을하고 있습니다. 그러나 나는 그들이 무엇 을하고 있는지 전혀 모른다 . 다행히도, 질문은 실제로 그들이하는 일을 설명하므로 다음과 같이 다시 작성할 수 있습니다.

// ECMAScript
things.reduce(function (acc, thing) {
    (acc[thing.type] || (acc[thing.type] = [])).push(thing);
    return acc;
}, {});

# Ruby
things.group_by(&:type)

// Scala
things groupBy(_.type)

// C#
from thing in things group thing by thing.Type // or
things.GroupBy(thing => thing.Type);

루프가없고 변경 가능한 상태가 없습니다. 음, 명백한 루프와 루프 카운터는 없습니다.

코드는 훨씬 짧아지고 훨씬 단순 해졌으며, 코드가 수행해야 할 작업에 대한 설명과 비슷해졌으며 (특히 루비의 경우에는 "유형별로 그룹화"라고 거의 직접 표시합니다) 오류가 훨씬 적습니다. 루프 인덱스 및 종료 조건이 없기 때문에 루프 끝 및 종료 조건에서 어레이 끝, 펜스 포스트 오류 또는 한 번에 하나씩 오류를 실행할 위험 이 없습니다 .

조롱. 코드에 과도한 디커플링을위한 인공적인 요구 사항이 너무 많아 과도하게 엔지니어링 된 라비올리 코드로 이어지고보다 절차 적이거나 기능적인 디자인이 문제에 대한 간단한 해결책 일 때 목을 줄이십시오.

전 세계 델파이 프로그래머들은 지난 2 년간 전체적인 유니 코드 변환으로 인해 문자 배열을 사용하여 바이트를 저장하는 것이 얼마나 나쁜지 알아 냈습니다.

그리고 "곧" 64 비트로 변경 하고 싶을 때 정수를리스트에 저장하는 것이 얼마나 나쁜지 알게 될 것 입니다.

속성. 나는 이것이 논란의 여지가 있다는 것을 알고 있지만 .net에서 속성이 많이 남용된다고 생각합니다.

이 두 라인의 차이점은 무엇입니까?

public string Property { get; set; }

public string Field;

개발자에게는 차이점이 전혀 없습니다. 컴파일 된 양식을 사용하면 라이브러리를 작성하고, 만약 그렇다면, 작은 비트 다른 및 해당 라이브러리가 프로그램에서 업그레이드 할 것입니다, 그리고 당신이 플러그인을위한 인터페이스를 작성하는 경우 (예를 들어, 프로그램 자체를 다시 컴파일 할 수없는 소프트웨어의 여러 버전에서 작동해야합니다) 그런 다음 공용 필드를 속성으로 바꿀 수 없으므로 공용 필드를 사용하지 않아야합니다. 다른 경우 에는 필드를 사용하는 것과 수정자가없는 자동 속성을 사용하는 것에는 전혀 차이 가 없습니다 .