Apakah ada teknik dalam pemrograman yang Anda temukan terlalu sering digunakan (IE menggunakan cara yang lebih berlebihan dari yang seharusnya) atau disalahgunakan, atau menggunakan sedikit untuk semuanya, sementara tidak menjadi solusi yang benar-benar baik untuk banyak masalah yang orang coba lakukan selesaikan dengan itu.

Itu bisa berupa ekspresi reguler, semacam pola desain atau mungkin suatu algoritma, atau sesuatu yang sama sekali berbeda. Mungkin Anda pikir orang menyalahgunakan beberapa pewarisan, dll.

Komentar dalam Kode

Saya hanya berharap para Profesor Universitas akan mengerti bahwa mereka tidak perlu mengajar siswa mereka untuk menulis 10 baris komentar dengan mengatakan kode berikut adalah untuk loop, iterasi dari 1 ke jumlah x. Saya bisa melihatnya di kode!

Ajari mereka untuk menulis kode pendokumentasian diri terlebih dahulu kemudian mengomentari dengan tepat tentang apa yang tidak bisa didokumentasikan dengan baik sendiri. Dunia perangkat lunak akan menjadi tempat yang lebih baik.

Pola desain tunggal.

Tentu, ini adalah pola yang berguna tetapi setiap kali seorang programmer baru belajar tentang pola ini ia mulai mencoba menerapkannya pada setiap kelas yang ia ciptakan.

Hal paling jahat untuk melindungi pemrograman bodoh. letakkan semuanya dalam tangkapan mencoba dan tidak melakukan apa-apa dengan tangkapan

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

        }

Saya ngeri ketika saya melihat try catch yang tidak melakukan apa-apa dan dirancang untuk menangani logika bodoh. Secara umum hasil tangkapan try over, namun dalam beberapa kasus sangat berguna.

Ketergantungan pada StackOverflow untuk menyelesaikan masalah Anda alih-alih mencari jalan keluar yang sulit.

Pemrogram baru yang menemukan banyak pengetahuan di SO (terlalu sering) memposting sebelum berpikir dan mencoba hal-hal.

Di hari saya kami harus kode dari buku, tidak ada internet, tidak ada SO. Sekarang turunlah dari halaman saya.

OOP jelas. Ini sangat berharga, tetapi ketika disalahgunakan dapat mengaburkan kode yang jelas jika tidak cukup mudah (beberapa contoh pemrograman S4 dalam R datang ke pikiran), dan dapat memberikan overhead yang luar biasa yang tidak perlu dan dapat menghabiskan banyak waktu untuk kinerja.

Hal lain adalah bahwa (dalam Perl misalnya) OOP sering turun untuk menulis hal yang sama result = $object ->function(pars)sebaliknya : bukannya result = function(object, pars)ini kadang-kadang masuk akal, tetapi ketika dicampur dengan pemrograman prosedural itu dapat membuat membaca kode cukup membingungkan. Dan terlepas dari itu, Anda hanya memperkenalkan lebih banyak overhead di mana itu tidak meningkatkan desain. Berasal dari apa yang dikatakan tentang pola singleton juga: Harus digunakan, tetapi tidak pada segalanya.

Saya memang menggunakan OOP sendiri, tetapi dalam bidang saya (komputasi ilmiah) kinerja adalah masalah besar, dan OOP sering disalahgunakan di sana karena semua siswa mendapatkan Java saat ini. Ini bagus untuk menangani masalah yang lebih besar, untuk membuat konsep dan sebagainya. Tetapi jika Anda bekerja dengan misalnya sekuens DNA dalam BioPerl, menggunakan objek setiap kali dan bekerja secara konsisten dengan getter dan setter dapat meningkatkan waktu perhitungan sepuluh kali lipat. Ketika kode Anda berjalan beberapa hari, bukan beberapa jam, perbedaan itu sangat penting.

Setelah menghabiskan beberapa tahun di ASP.NET Webforms, saya harus mengatakan dengan tegas:

UI Smart

Walaupun sepenuhnya mungkin untuk membuat aplikasi berlapis dan dapat diuji dalam formulir web, Visual Studio membuatnya terlalu mudah bagi pengembang untuk mengklik satu kali cara mereka untuk mengikat dengan ketat ke sumber data mereka, dengan logika aplikasi berserakan di sekitar semua kode UI.

Steve Sanderson menjelaskan anti-pola ini jauh lebih baik daripada yang saya bisa dalam bukunya Pro ASP.NET MVC:

Untuk membangun aplikasi Smart UI, pengembang pertama membangun UI, biasanya dengan menyeret serangkaian widget UI ke kanvas, dan kemudian mengisi kode pengendali event untuk setiap klik tombol yang mungkin atau acara UI lainnya. Semua logika aplikasi berada di event handler ini: logika untuk menerima dan memvalidasi input pengguna, untuk melakukan akses dan penyimpanan data, dan untuk memberikan umpan balik dengan memperbarui UI. Seluruh aplikasi terdiri dari penangan acara ini. Pada dasarnya, ini adalah apa yang cenderung keluar secara default ketika Anda menempatkan seorang pemula di depan Visual Studio. Dalam desain ini, tidak ada pemisahan kekhawatiran sama sekali. Semuanya menyatu bersama, diatur hanya dalam hal berbagai peristiwa UI yang mungkin terjadi. Ketika logika atau aturan bisnis perlu diterapkan di lebih dari satu penangan, kode biasanya disalin dan ditempelkan, atau segmen tertentu yang dipilih secara acak difaktorkan ke dalam kelas utilitas statis. Karena banyak alasan yang jelas, pola desain semacam ini sering disebut anti-pola.

Saya melihat ini sesekali dan biasanya hasil dari tidak sepenuhnya memahami ekspresi boolean.

if (someCondition == true)

Menjalankan kembali fungsionalitas inti (atau yang disediakan lain), baik karena ketidaktahuan tentang keberadaannya atau karena kebutuhan yang dirasakan untuk penyesuaian.

Warisan.

Jangan memaksakan itu-di mana itu tidak masuk akal.

Menyesuaikan perangkat lunak yang tidak tersedia.

Meskipun saya bisa mengakui ini bisa berguna, saya bertanya-tanya berapa banyak uang yang dihabiskan untuk menyelesaikan hal-hal kecil untuk keuntungan yang dipertanyakan. Di sinilah perusahaan dapat menghabiskan ratusan ribu jika tidak jutaan dolar untuk lisensi untuk beberapa perangkat lunak yang kemudian disesuaikan karena sangat dapat dikonfigurasi, diedit, dan fleksibel sehingga benar-benar tidak melakukan banyak hal secara default. Pada akhirnya itu adalah aplikasi khusus karena semua kode baru ditambahkan apa yang awalnya dibeli.

Menggunakan komplier sebagai debugger.

Mengabaikan peringatan penyusun atau mematikannya sama sekali.

Variabel global.

Semua Pola Desain.

Mereka seperti garam atau gula. Beberapa dari mereka membuat makanan Anda enak, banyak dari mereka, membuat makanan Anda menyebalkan.

Jangan salah sangka. Pola Desain adalah teknik yang luar biasa. Saya sering menggunakannya. Tetapi kadang-kadang, saya menemukan programmer, (beberapa dari mereka mantan bos saya), yang memiliki "Anda harus menggunakan pola desain", bahkan jika tidak cocok dengan masalahnya !!!

Salah satu contoh adalah "Pola Pengunjung" yang lebih diarahkan untuk "Koleksi Lineal / Sekuensial". Saya harus bekerja dengan struktur data pohon, sekali. Untuk "mengunjungi" setiap item, saya membuat kode metode pola non desain, dan mantan bos bersikeras untuk menggunakan atau mengadaptasi "Pola Pengunjung". Lalu, saya telusuri internet, untuk pendapat kedua. Nah, programmer lain mengalami situasi yang sama, dan solusi yang sama. Dan menyebutnya "Pola Pengunjung Pohon / Hierarkis"., Sebagai Pola Desain BARU

Saya harap ini ditambahkan sebagai pola baru pada pola yang sudah ada, dalam versi baru buku "Pola Desain".

Menggunakan pengecualian sebagai kontrol aliran. Agak mirip dengan jawaban ini , tetapi berbeda.

Menelan pengecualian adalah bentuk yang buruk karena memperkenalkan kode yang misterius dan sulit ditemukan. Sebaliknya, menggunakan pengecualian sebagai kontrol aliran adalah buruk karena membuat kode jauh lebih tidak efisien daripada yang seharusnya, dan secara konsep ceroboh.

Penanganan pengecualian hanya boleh digunakan untuk menangani skenario yang benar-benar luar biasa (duh), tidak terduga, bukan hal-hal seperti pengguna mengetikkan karakter alfabet di mana angka diharapkan. Pelecehan pengecualian semacam ini sangat umum di antara programmer buruk di dunia Java.

Aku akan pergi dengan tidak fleksibel melalui penyembunyian data yang berlebihan.

Kita semua tahu bahwa abstraksi dan menyembunyikan implementasinya bagus, tetapi lebih banyak tidak selalu lebih baik. Berlebihan, Anda bisa mendapatkan hasil yang tidak fleksibel yang tidak bisa mengatasi perubahan persyaratan. Untuk menangani perubahan, Anda tidak hanya harus memodifikasi kelas yang perlu menangani perubahan itu, tetapi Anda juga harus membuat cara agar informasi yang tidak pernah dibutuhkan sebelumnya dapat diakses meskipun ada lapisan data yang disembunyikan.

Masalahnya adalah, karena dengan semua masalah menemukan-keseimbangan-tepat-untuk-setiap-konteks, dibutuhkan pengalaman.

Mengekspos array internal

    public class Data {
    int[] x;

    public void setArray(int[] x) {

        this.x = x;
    }

    public int[] getArray() {

        return x;
    }
}

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

salin objek yang bisa berubah sebelum kembali, kecuali tujuannya adalah untuk berbagi status.

Status dan loop yang bisa berubah. Anda hampir tidak pernah membutuhkannya, dan Anda hampir selalu mendapatkan kode yang lebih baik tanpa mereka.

Misalnya, ini diambil langsung dari utas 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

Mereka berdua melakukan hal yang sama. Tetapi saya tidak tahu apa yang mereka lakukan. Untungnya, pertanyaannya benar-benar menjelaskan apa yang mereka lakukan, jadi saya dapat menulis ulang mereka sebagai berikut:

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

Tidak ada loop, dan tidak ada keadaan bisa berubah. Baiklah, oke, tidak ada loop eksplisit dan tidak ada loop counter.

Kode telah menjadi jauh lebih pendek, lebih sederhana, lebih seperti deskripsi tentang apa yang seharusnya dilakukan kode (terutama dalam kasus Ruby itu secara langsung mengatakan "kelompok hal-hal berdasarkan jenis"), dan jauh lebih rentan kesalahan. Tidak ada bahaya menjalankan akhir array, kesalahan fencepost atau kesalahan off-by-one dengan indeks loop dan kondisi terminasi, karena tidak ada indeks loop dan kondisi terminasi.

Mengejek. Ini memperkenalkan terlalu banyak persyaratan buatan untuk decoupling yang berlebihan ke dalam kode Anda, mengarah ke kode ravioli yang direkayasa berlebihan dan memaksa desain gaya OO ke tenggorokan Anda ketika desain yang lebih prosedural atau fungsional mungkin merupakan solusi yang lebih sederhana untuk masalah Anda.

Pemrogram Delphi di seluruh dunia telah mencari tahu selama dua tahun terakhir betapa buruknya menggunakan array karakter untuk menyimpan byte karena konversi Unicode skala besar

Dan, "segera" kita akan belajar betapa buruknya menyimpan bilangan bulat dalam daftar ketika kita ingin melakukan perubahan ke 64-bit.

Properti. Saya tahu ini kontroversial, tetapi saya merasa properti sangat banyak digunakan di .net.

Apa perbedaan antara dua garis ini?

public string Property { get; set; }

public string Field;

Bagi pengembang, perbedaannya adalah: sama sekali tidak ada. Bentuk yang dikompilasi sedikit berbeda, jadi jika Anda menulis perpustakaan, dan perpustakaan itu akan ditingkatkan dalam program, dan Anda tidak dapat mengkompilasi ulang program itu sendiri (misalnya jika Anda sedang menulis antarmuka untuk plugin yang harus bekerja lintas versi perangkat lunak Anda), maka Anda tidak boleh menggunakan bidang publik karena Anda tidak dapat menggantinya dengan properti. Dalam kasus lain, sama sekali tidak ada perbedaan antara menggunakan bidang atau properti otomatis tanpa pengubah.