Có bất kỳ kỹ thuật nào trong lập trình mà bạn thấy bị lạm dụng (IE sử dụng quá mức so với những gì họ nên làm) hoặc lạm dụng, hoặc sử dụng một chút cho mọi thứ, trong khi không phải là một giải pháp thực sự tốt cho nhiều vấn đề mà mọi người cố gắng giải quyết với nó

Nó có thể là các biểu thức chính quy, một số kiểu mẫu thiết kế hoặc có thể là một thuật toán hoặc một cái gì đó hoàn toàn khác. Có thể bạn nghĩ rằng mọi người lạm dụng nhiều di sản, vv

Nhận xét trong mã

Tôi chỉ mong các Giáo sư Đại học sẽ hiểu rằng họ không cần phải dạy sinh viên của mình viết 10 dòng bình luận nói rằng đoạn mã sau đây là một vòng lặp, lặp từ 1 đến số x. Tôi có thể thấy điều đó trong mã!

Dạy chúng viết mã tự viết tài liệu trước sau đó nhận xét thích hợp về những gì không thể tự viết đầy đủ thứ hai. Thế giới phần mềm sẽ là một nơi tốt hơn.

Các mẫu thiết kế singleton.

Chắc chắn, đó là một mẫu hữu ích nhưng mỗi khi một lập trình viên mới biết về mẫu này, anh ta bắt đầu cố gắng áp dụng nó cho mỗi lớp mà anh ta tạo ra.

Điều xấu xa nhất để bảo vệ lập trình câm. đặt mọi thứ vào một cái bẫy thử và không làm gì với cái bẫy

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

        }

Tôi rùng mình khi thấy một cái bẫy thử không làm gì cả và được thiết kế để xử lý logic ngu ngốc. Nói chung, các sản phẩm khai thác thử được sử dụng quá mức, tuy nhiên trong một số trường hợp rất hữu ích.

Dựa vào StackOverflow để giải quyết vấn đề của bạn thay vì tìm ra nó một cách khó khăn.

Các lập trình viên mới tìm thấy sự giàu có của kiến ​​thức về SO (quá thường xuyên) đăng trước khi suy nghĩ và thử mọi thứ.

Trong thời của tôi, chúng tôi phải viết mã từ sách, không có internet, không có SO. Bây giờ có được ra bãi cỏ của tôi.

OOP hiển nhiên. Nó rất có giá trị, nhưng khi sử dụng sai, nó có thể che khuất mã rõ ràng một cách dễ dàng (một số ví dụ về lập trình S4 trong R), và có thể cung cấp một chi phí rất lớn không cần thiết và có thể khiến bạn mất thời gian lớn về hiệu suất.

Một điều nữa là (ví dụ Perl) OOP thường viết ra điều tương tự theo cách khác: result = $object ->function(pars)thay vì result = function(object, pars)Điều này đôi khi có ý nghĩa, nhưng khi trộn lẫn với lập trình thủ tục, nó có thể khiến việc đọc mã khá khó hiểu. Và ngoài ra, bạn chỉ giới thiệu thêm chi phí mà không cải thiện thiết kế. Nó cũng nói về những gì được nói về mẫu singleton: Nên được sử dụng, nhưng không phải trên tất cả mọi thứ.

Bản thân tôi sử dụng OOP, nhưng trong lĩnh vực của tôi (tính toán khoa học) là một vấn đề lớn và OOP thường bị lạm dụng ở đó vì tất cả các sinh viên đều có Java ngày nay. Thật tuyệt vời khi xử lý các vấn đề lớn hơn, để khái niệm hóa và vân vân. Nhưng nếu bạn làm việc với các chuỗi DNA trong BioPerl, sử dụng các đối tượng mọi lúc và làm việc nhất quán với getters và setters có thể tăng thời gian tính toán lên gấp 10 lần. Khi mã của bạn đang chạy một vài ngày thay vì một vài giờ, sự khác biệt đó thực sự quan trọng.

Đã dành vài năm trong ASP.NET Webforms, tôi phải nói một cách dứt khoát:

Giao diện người dùng thông minh

Mặc dù hoàn toàn có thể tạo các ứng dụng phân lớp, có thể kiểm tra trong các biểu mẫu web, Visual Studio giúp các nhà phát triển quá dễ dàng chỉ cần một cú nhấp chuột để tạo các liên kết chặt chẽ với nguồn dữ liệu của họ, với logic ứng dụng nằm rải rác trong tất cả mã UI.

Steve Sanderson giải thích cách chống mô hình này tốt hơn nhiều so với tôi có thể trong cuốn sách Pro ASP.NET MVC của mình:

Để xây dựng ứng dụng Giao diện người dùng thông minh, trước tiên, nhà phát triển xây dựng giao diện người dùng, thường bằng cách kéo một loạt các tiện ích UI vào khung vẽ, sau đó điền mã xử lý sự kiện cho mỗi lần nhấp nút có thể hoặc sự kiện UI khác. Tất cả logic ứng dụng nằm trong các trình xử lý sự kiện này: logic để chấp nhận và xác thực đầu vào của người dùng, để thực hiện truy cập và lưu trữ dữ liệu và cung cấp phản hồi bằng cách cập nhật giao diện người dùng. Toàn bộ ứng dụng bao gồm các trình xử lý sự kiện này. Về cơ bản, đây là những gì có xu hướng xuất hiện theo mặc định khi bạn đặt một người mới trước Visual Studio. Trong thiết kế này, không có bất kỳ mối quan tâm nào. Mọi thứ được hợp nhất với nhau, chỉ được sắp xếp theo các sự kiện UI khác nhau có thể xảy ra. Khi logic hoặc quy tắc kinh doanh cần được áp dụng trong nhiều trình xử lý, mã thường được sao chép và dán, hoặc các phân đoạn được chọn ngẫu nhiên nhất định được đưa vào các lớp tiện ích tĩnh. Vì nhiều lý do rõ ràng, loại mẫu thiết kế này thường được gọi là mẫu chống.

Thỉnh thoảng tôi thấy điều này và nó thường xuất phát từ việc không hiểu đầy đủ các biểu thức boolean.

if (someCondition == true)

Thực hiện lại chức năng cốt lõi (hoặc được cung cấp theo cách khác), vì sự thiếu hiểu biết về sự tồn tại của nó hoặc do nhu cầu nhận thức về các tùy chỉnh.

Di sản.

Đừng thi hành là một nơi không có ý nghĩa.

Tùy chỉnh phần mềm sẵn có.

Mặc dù tôi có thể thừa nhận điều này có thể hữu ích, tôi tự hỏi bao nhiêu tiền được chi cho việc hoàn thành những việc nhỏ để kiếm lợi nhuận đáng ngờ. Đây là nơi một công ty có thể chi hàng trăm nghìn nếu không phải hàng triệu đô la cho giấy phép cho một số phần mềm sau đó được tùy chỉnh vì nó có thể cấu hình, có thể chỉnh sửa và linh hoạt đến mức nó thực sự không làm được gì nhiều theo mặc định. Cuối cùng, nó là một ứng dụng tùy chỉnh vì tất cả các mã mới được thêm vào những gì ban đầu được mua.

Sử dụng trình biên dịch như một trình sửa lỗi.

Bỏ qua các cảnh báo trình biên dịch hoặc tắt chúng hoàn toàn.

Biến toàn cầu.

Tất cả các mẫu thiết kế.

Chúng giống như muối hoặc đường. Một số trong số chúng trên thực phẩm của bạn làm cho nó tuyệt vời, rất nhiều trong số chúng, làm cho thực phẩm của bạn hút.

Đừng hiểu lầm tôi. Mẫu thiết kế là những kỹ thuật tuyệt vời. Tôi đã sử dụng chúng rất nhiều. Nhưng đôi khi, tôi tìm thấy các lập trình viên, (một số trong số họ là ông chủ cũ của tôi), người đã có những "bạn phải sử dụng một mẫu thiết kế", ngay cả khi không phù hợp với vấn đề !!!

Một ví dụ là "Mẫu khách truy cập", người được định hướng nhiều hơn cho "Bộ sưu tập Lineal / Sequential". Tôi đã phải làm việc với một cấu trúc dữ liệu cây, một lần. Để "truy cập" từng mục, tôi mã hóa một phương thức mẫu không thiết kế và một ông chủ cũ khăng khăng sử dụng hoặc điều chỉnh "Mẫu khách truy cập". Sau đó, tôi duyệt mạng, cho ý kiến ​​thứ hai. Vâng, các lập trình viên khác có cùng một tình huống, và cùng một giải pháp. Và gọi nó là "Mẫu khách truy cập cây / phân cấp"., Như một mẫu thiết kế MỚI

Tôi hy vọng nó được thêm vào như một mẫu mới cho các mẫu hiện có, trong phiên bản mới của cuốn sách "Mẫu thiết kế".

Sử dụng ngoại lệ như kiểm soát dòng chảy. Sắp xếp tương tự như câu trả lời này , nhưng khác nhau.

Nuốt ngoại lệ là hình thức xấu vì nó giới thiệu các lỗi bí ẩn, khó tìm trong mã. Mặt khác, sử dụng các ngoại lệ như kiểm soát luồng, là xấu vì nó làm cho mã kém hiệu quả hơn nhiều so với khả năng và về mặt khái niệm là cẩu thả.

Xử lý ngoại lệ chỉ nên được sử dụng để xử lý các tình huống thực sự đặc biệt (duh), không lường trước được, không phải là những thứ như người dùng nhập vào một ký tự chữ cái trong đó một số được mong đợi. Kiểu lạm dụng ngoại lệ này cực kỳ phổ biến đối với các lập trình viên xấu trong thế giới Java.

Tôi sẽ đi với sự không linh hoạt thông qua việc ẩn dữ liệu quá mức.

Chúng ta đều biết rằng sự trừu tượng và che giấu việc thực hiện là tốt, nhưng nhiều hơn không phải lúc nào cũng tốt hơn. Quá liều, bạn có thể nhận được một kết quả không linh hoạt mà không thể đối phó với những thay đổi trong yêu cầu. Để xử lý thay đổi, bạn không chỉ phải sửa đổi lớp cần xử lý thay đổi đó mà còn phải tạo một cách để thông tin không bao giờ cần có trước đây có thể truy cập được mặc dù có các lớp ẩn dữ liệu.

Vấn đề là, như với tất cả các vấn đề tìm kiếm sự cân bằng cho mọi bối cảnh, nó cần có kinh nghiệm.

Hiển thị mảng nội bộ

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

Theo http://www.oracle.com/technetwork/java/seccodeguide-139067.html

sao chép các đối tượng có thể thay đổi trước khi quay trở lại, trừ khi có ý định chia sẻ trạng thái.

Trạng thái đột biến và vòng lặp. Bạn gần như không bao giờ cần chúng, và bạn hầu như luôn nhận được mã tốt hơn mà không có chúng.

Ví dụ: cái này được lấy trực tiếp từ luồng 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

Cả hai đều làm điều tương tự. Nhưng tôi không có ý tưởng những gì họ đang làm. May mắn thay, câu hỏi thực sự giải thích những gì họ đang làm, vì vậy tôi đã có thể viết lại chúng như sau:

// 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);

Không có vòng lặp, và không có trạng thái đột biến. Vâng, không có, không có vòng lặp rõ ràng và không có bộ đếm vòng lặp.

Mã đã trở nên ngắn hơn nhiều, đơn giản hơn nhiều, giống như mô tả về những gì mã phải làm (đặc biệt là trong trường hợp Ruby, nó nói trực tiếp "nhóm các thứ theo loại") và ít bị lỗi hơn. Không có nguy cơ chạy hết mảng, lỗi hàng rào hoặc lỗi do lỗi với các chỉ số vòng lặp và điều kiện kết thúc, bởi vì không có chỉ số vòng lặp và điều kiện kết thúc.

Chế giễu. Nó đưa ra quá nhiều yêu cầu giả tạo để tách mã quá mức vào mã của bạn, dẫn đến mã ravioli bị áp đảo và buộc thiết kế kiểu OO xuống cổ họng của bạn khi một thiết kế chức năng hoặc thủ tục hơn có thể là một giải pháp đơn giản hơn cho vấn đề của bạn.

Các lập trình viên Delphi trên toàn thế giới đã phát hiện ra trong hai năm qua về việc sử dụng các mảng ký tự để lưu trữ byte do chuyển đổi Unicode toàn bộ sẽ tệ đến mức nào.

Và, "sớm thôi" chúng ta sẽ biết mức độ tệ của việc lưu trữ số nguyên trong danh sách khi chúng ta muốn thực hiện thay đổi thành 64 bit.

Tính chất. Tôi biết điều này đang gây tranh cãi, nhưng tôi cảm thấy rằng các thuộc tính được sử dụng quá mức trong .net.

Sự khác biệt giữa hai dòng này là gì?

public string Property { get; set; }

public string Field;

Đối với nhà phát triển, sự khác biệt là: hoàn toàn không có gì. Biểu mẫu được biên dịch hơi khác một chút, vì vậy nếu bạn đang viết thư viện và thư viện đó sẽ được nâng cấp trong các chương trình và bạn không thể tự biên dịch lại các chương trình (ví dụ: nếu bạn đang viết giao diện cho các plugin nên hoạt động trên các phiên bản phần mềm của bạn), sau đó bạn không nên sử dụng các trường công khai vì bạn không thể thay thế chúng bằng các thuộc tính. Trong mọi trường hợp khác, hoàn toàn không có sự khác biệt giữa việc sử dụng trường hoặc thuộc tính tự động mà không cần sửa đổi.