it-swarm-id.com

Apakah Anda benar-benar menulis 'kode bersih'?

Saya telah melihat beberapa programmer mengubah kode mereka berulang-ulang tidak hanya untuk membuatnya 'berfungsi baik', tetapi juga untuk membuatnya 'terlihat bagus'.

IMO, 'kode bersih' sebenarnya adalah pujian yang menunjukkan bahwa kode Anda elegan, mudah dimengerti dan dapat dipelihara. Dan perbedaannya muncul ketika Anda harus memilih antara kode yang menarik secara estetis vs kode yang sulit untuk dilihat.

Jadi, berapa banyak dari Anda yang benar-benar menulis 'kode bersih'? Apakah ini praktik yang baik? Apa manfaat atau kelemahan lain dari ini?

57
ykombinator

Saya berpendapat bahwa banyak dari kita tidak menulis kode bersih . Dan umumnya, itu bukan tugas kami. Tugas kami sebagai pengembang perangkat lunak adalah memberikan produk yang berfungsi tepat waktu.

Saya teringat posting blog Joel Spolsky: The Duct Tape Programmer .

Ia mengutip dari Coders at Work :

Pada akhir hari, kirimkan barang itu! Sangat bagus untuk menulis ulang kode Anda dan membuatnya lebih bersih dan pada ketiga kalinya itu akan menjadi cantik. Tapi bukan itu intinya — Anda di sini bukan untuk menulis kode; Anda di sini untuk mengirimkan produk. - Jamie Zawinsky

Saya juga diingatkan tentang tanggapan blog Robert Martin :

Begitu. Jadilah cerdas. Bersihkan. Sederhana saja. Kapal! Dan siapkan gulungan lakban kecil, dan jangan takut untuk menggunakannya. - Paman Bob

Jika kodenya, yang ditulis oleh pengembang kebetulan bersih DAN berfungsi (dapat dikirim), baiklah, baik untuk semua orang. Tetapi jika seorang pengembang bermain-main mencoba untuk membuat kode yang bersih dan mudah dibaca dengan mengorbankan bisa mengirimkannya tepat waktu, maka itu buruk. Buat itu berfungsi, gunakan lakban, dan kirimkan. Anda bisa refactor nanti dan membuatnya super cantik dan efisien.

Ya, itu adalah praktik yang baik untuk menulis kode bersih, tetapi tidak pernah dengan mengorbankan kemampuan untuk memberikan Manfaat mengirimkan produk yang direkam dengan saluran tepat waktu jauh melebihi manfaat kode bersih yang tidak pernah selesai dan dikirim.

Sebagian besar kode yang saya temui tidak bersih. Beberapa benar-benar jelek. Tetapi mereka semua dilepaskan dan digunakan dalam produksi. Beberapa orang mungkin mengatakan bahwa tidak profesional untuk menulis kode yang berantakan. Saya tidak setuju. Yang profesional adalah memberikan kode yang berfungsi, apakah itu bersih atau berantakan. Pengembang harus melakukan yang terbaik yang dia bisa, mengingat waktu apa pun yang dialokasikan sebelum pengiriman. Lalu, kembali untuk membersihkan-- itu profesional. Mudah-mudahan, kode yang dikirim bukan lakban murni dan 'cukup bersih'.

54
spong

Anda harus memastikan bahwa kode Anda sangat mudah dibaca, bersih, dan terpelihara. Itulah yang dilakukan oleh semua programmer harus.

Tetapi Anda berbicara tentang over styling (seperti istilah itu lebih baik dari itu kode-gadis ) yang hanya melayani ego pengarangnya.

Saya telah melihat banyak pengembang di masa lalu sangat bangga dengan kreasi mereka (Anda tahu, seperti di toilet;)), mereka menghabiskan waktu berjam-jam membersihkan dan memoles kode mereka. Beberapa dari mereka sangat teliti sehingga mereka memastikan bahwa ruang putih yang benar antara anggota dihormati.

Terlalu banyak.

Saya menemukan perilaku semacam itu kontraproduktif. Dalam konteks profesional , Anda harus profesional . Anda bisa mendapatkan kepuasan Anda dengan menulis kode yang bersih, sangat mudah dibaca dan dipelihara serta berbicara dengan pengguna atau kolega yang bahagia.

39
user2567

Saya tidak setuju dengan jawaban yang diterima pada pertanyaan ini.

Tanggung jawab Anda jelas untuk dikirimkan, tetapi biasanya Anda juga memiliki tanggung jawab untuk mengirimkan sesuatu yang dapat dikelola dengan biaya seefektif mungkin oleh Anda dan pengembang di masa mendatang.

Saya telah menghabiskan waktu sebagai programmer atau konsultan pemeliharaan yang buruk di situs yang harus memahami dan men-debug beberapa sistem besar yang tidak terdokumentasi, dan saya dapat memberitahu Anda bahwa desain yang buruk dan kode yang membingungkan dapat menyebabkan berjam-jam atau bahkan berhari-hari upaya yang sia-sia. Saya dapat memikirkan banyak situasi di mana upaya ekstra N jam oleh pengembang awal dapat menyebabkan penghematan biaya 5N dalam hal waktu saya.

Saya tahu ada statistik yang beredar tentang ini, tetapi dalam pengalaman saya di beberapa proyek, setiap baris kode yang ditulis dibaca 5-20 kali selama ekstensi dan pemeliharaan.

Jadi saya akan mengatakan kepada bersihkan kode ke dalam satu inci dari hidupnya. Butuh waktu, tetapi kemungkinan penghematan biaya bersih selama umur proyek.

24
Benjamin Wootton

Apakah ada di antara kita yang membeli mobil jika kita tahu bahwa di bawah kap mobil itu berantakan dan sulit untuk dipecahkan, dirawat atau diperbaiki dan dibutuhkan lebih banyak sumber daya untuk berjalan daripada yang seharusnya?

Mengapa harus berbeda untuk perangkat lunak?

Hanya karena pengguna akhir tidak dapat melihat di bawah tenda tidak berarti mereka tidak akan pernah mengetahuinya. Cepat atau lambat itu akan muncul.

Menjawab pertanyaan "Apakah Anda benar-benar menulis 'kode bersih'?" -- Oh ya.!

21
Sifar

Jika dengan 'kode bersih' maksud Anda apakah saya pergi keluar dari cara saya untuk memastikan kode sejelas mungkin?

Heck ya.

Semakin bersih, semakin jelas kodenya, semakin mudah dipelihara, dan dengan demikian menghemat waktu Anda dalam jangka panjang. Jangan melihat kode bersih sebagai kesombongan; melihatnya sebagai investasi dalam menghemat upaya dan waktu di masa depan.

18
GrandmasterB

Jujur itu tergantung. Saya suka bagaimana semua orang melontarkan garis partai tentang bagaimana "kode yang tidak terdokumentasi dengan baik adalah parodi belaka!", Tetapi saya bekerja dalam bisnis dengan siklus penyebaran yang konyol dan pengawasan nol: Saya melakukan yang terbaik yang saya bisa, tetapi saya menulis begitu banyak kode sangat sulit untuk menulis kode sempurna bersih yang diklaim oleh semua orang .

Saya mencoba menulis kode yang dapat dengan mudah dikelola oleh seseorang yang memiliki kemampuan saya kira-kira. Saya mengomentari bagian yang sulit, saya memberi nama program, variabel, dan nama-nama kelas ramah, saya menyebarkan, dan saya melanjutkan. Saya tidak punya waktu untuk melakukan hal lain.

Terkadang saya merasa sedikit bersalah tentang hal itu, tetapi tidak terlalu. Anda harus melihat beberapa kengerian yang saya tangani setiap hari. Puluhan tahun kode kustom dalam bahasa yang tidak jelas dengan nol dokumentasi. Salah satu rekan kerja saya berkembang secara eksklusif dalam Visual Basic 6.0 dan menyebarkan binary bernama samar di semua tempat. Wanita yang saya ganti diprogram secara eksklusif di RPG .

Hanya sangat sulit bagi saya untuk percaya, omong kosong mengerikan seperti yang saya lihat di tahun-tahun saya sebagai seorang programmer, bahwa semua orang hanya menghasilkan kode bersih.

15
Satanicpuppy

Saya rasa saya tidak suka istilah "kode gadis" tetapi kode bersih = kode yang dapat dipelihara. Kurang dari itu tidak profesional.

Sebagai aturan umum, saya mempertimbangkan pengembang berikutnya yang harus melihat kekacauan saya.

Sering kali itu adalah saya ... beberapa bulan kemudian ... ketika saya tidak ingat bagaimana cara kerjanya ... dan saya bahkan memiliki lebih sedikit waktu untuk melakukan perubahan.

7
Heath Lilley

Saya mencoba menulis "kode bersih" dalam arti Bob Martin (mis. OO desain). Ada hebat nilai dalam menulis kode bersih. Jauh lebih bisa dipertahankan.

Lalu saya membiarkan ReSharper menjadikannya "kode cantik" untuk saya (mis. Penyelarasan, jeda baris, dll.). Ada bagus nilai dalam menulis kode cantik. Tetapi ada pengembalian yang semakin berkurang. Beberapa prettification membuatnya sedikit lebih dapat dipertahankan karena kemudahan membaca.

Jika Anda merasa bahwa berbaris rapi blok kode yang besar diperlukan untuk membuatnya dapat dibaca, maka masalahnya adalah blok kode besar freakin Anda! Ini terlalu besar. Saya melihat banyak contoh orang yang bersusah payah untuk mendisain beberapa kode yang dirancang dengan sangat buruk.

Jika saya tidak memiliki ReSharper, saya masih akan memiliki kode bersih, tetapi tidak akan secantik itu.

Saya tidak berpikir saya harus menghabiskan lebih dari ~ 5% dari waktu pengkodean saya dalam prettifying. Yang berarti semakin kuat editor saya dan semakin mahir saya dengan itu, semakin cantik saya bisa melakukannya.

5
dss539

Sepertinya tidak ada yang memunculkan poin apa yang menjadi kepentingan terbaik perusahaan Anda?

Seringkali, jika tidak selalu, programmer hanya karyawan, dan sementara keputusan manajemen mungkin membuat kita frustrasi, kita sering tidak memiliki semua data yang mereka lakukan.

Sebagai contoh, katakanlah perusahaan dikontrak dengan klausa bahwa jika perangkat lunak tidak siap tepat waktu, Anda tidak akan dibayar (itu hanya terjadi pada kami, meskipun saya pikir kami mendapatkan pembayaran setelah semua). Ya, kode bersih itu penting, tetapi yang lebih penting adalah membuat kode berfungsi pada hari pembayaran!

Contoh lain - perusahaan berada dalam posisi keuangan yang buruk dan perlu mengumpulkan uang. Tebak siapa yang peduli dengan kualitas? Anda dapat memperbaikinya nanti, jika perlu, kirimkan saja!

Suatu argumen mungkin adalah "Mengapa saya harus menjual dan menulis kode jelek?". Nah, mengapa perusahaan Anda harus membayar Anda cek Nice setiap bulan? Pilihan, temanku. Jika Anda menginginkan idealisme, cobalah Free Software Foundation ; Saya mendengar mereka melakukan beberapa hal yang sangat keren (maksud saya yang ini, dan saya menghormati FSF dan OSS).

Di sisi lain, jika Anda bekerja pada sebuah proyek di mana pertumbuhan eksplosif dalam penggunaan diharapkan (walaupun proyeksi semacam itu hampir tidak pernah akurat), Anda sebaiknya meletakkan dasar yang kuat dengan kualitas kode terbaik yang diperlukan, karena hampir pasti pemeliharaan akan dilakukan. menjadi biaya yang lebih besar untuk proyek tersebut.

Programmer suka kode 'bersih', apa pun artinya. Kami bahkan tidak bisa menyetujui apa yang bersih, tetapi kami menyukainya. Namun, terkadang itu tidak masalah sebanyak kegunaan dan kebenaran. Ini mungkin tampak sinonim, tetapi tidak - jika Anda telah melihat kode yang ditulis oleh peretas Perl sejati dalam 4 jam dengan maksud untuk digunakan dua kali dan dibuang, Anda akan mengakui itu tidak bersih, tetapi berfungsi.

Jadi kadang-kadang, selain ego, kita harus membuatnya bekerja. Perhatikan bahwa saya tidak merekomendasikan menulis kode buruk sebagai kebiasaan; Saya hanya menunjukkan bahwa mungkin perlu. Kesempurnaan membutuhkan waktu yang mungkin tidak dimiliki oleh perusahaan Anda. Jadi jika perusahaan Anda tidak keberatan, buat perangkat lunak, tetapi jika perlu, cukup tulis kode kerja, Sudahlah kebersihannya. Ini bukan jawaban 'Satu ukuran cocok untuk semua' - Anda harus memprioritaskan.

4
K.Steff

Terlalu banyak hal tidak pernah ada gunanya.

Namun, hal penting yang perlu diingat dengan kode "najis" adalah dapat dengan mudah mengarah ke " broken windows ". Jika kode diformat dengan sangat buruk, saya pikir banyak orang yang baru mengenal basis kode mungkin merasa kurang cenderung melakukan pekerjaan yang baik dengan pemeliharaan dan evolusi yang menyebabkan spiral ke bawah yang pada akhirnya mungkin mempengaruhi kondisi kerja perangkat lunak.

Oleh karena itu mempertahankan tingkat kebersihan tertentu dalam kode bermanfaat bagi lebih dari sekadar sesama pengembang Anda. Jangan menghabiskan terlalu banyak waktu untuk itu (~ 5% telah disebutkan). Pelajari cara menggunakan alat kerajinan Anda untuk mengotomatiskan tugas-tugas manual (pemformatan kode dalam kasus ini). Bertanggung jawab atas apa yang Anda lakukan dan selalu melakukan apa yang menurut Anda paling bermanfaat bagi perusahaan/pelanggan/pengguna Anda.

3
Per Noalt

Ini adalah kutipan dari Clean Code, oleh Bob Martin:

Untuk mengantar titik ini pulang, bagaimana jika Anda seorang dokter dan memiliki seorang pasien yang menuntut agar Anda menghentikan semua cuci tangan konyol sebagai persiapan untuk operasi karena terlalu banyak waktu? Jelas pasien adalah bos; namun dokter harus benar-benar menolak untuk patuh. Mengapa? Karena dokter lebih tahu daripada pasien tentang risiko penyakit dan infeksi. Akan tidak profesional (apalagi kriminal) bagi dokter untuk mematuhi pasien.

Demikian juga tidak profesional bagi programmer untuk tunduk pada kehendak manajer yang tidak mengerti risiko membuat kekacauan.

3
Tulains Córdova

Saya tidak yakin "terlihat baik" dan menjadi "elegan, mudah dimengerti dan dapat dipelihara" adalah setara.

Saya mencoba menulis kode, yaitu "elegan, dapat dimengerti dan dapat dipelihara". Saya melakukan refactor kode saya sendiri agar lebih cocok dengan kriteria tersebut.

Saya tidak melihat kekurangan, kecuali biaya yang dikeluarkan tepat waktu.

Agar kode "terlihat bagus", ada banyak alat otomatis, yang akan membuat indentasi dan mengatur ruang semua sesuai keinginan.

3
back2dos

Saya suka kode dapat dibaca, tetapi yang paling penting adalah konsistensi. Bagi saya itu berarti konsistensi dengan konvensi penamaan dan spasi antara fungsi, tanda kurung pada baris yang sama atau baris berikutnya dari pernyataan if, dll.

Tentu saja, ada kalanya seseorang memprogram sesuatu dengan gaya kode yang konsisten dan itu masih membuat saya gila. Terutama kode yang tidak "bernafas". Sebagai contoh:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Yah ... Terlihat lebih buruk dengan metode Objective-C, dan dengan banyak dan banyak pernyataan if bersarang, dan garis yang lebih panjang dari 80 karakter. Tapi itu masih mengganggu saya :)

2
vedosity

Saya pikir "kode bersih" harus bersih atau bersih daripada cara Anda menulis ujian fisika/teknik/matematika. Jika terlalu berantakan, siswa kelas tidak akan memahami pekerjaan Anda dan mungkin akan menandainya salah meskipun itu benar.

2
chiurox

Saya berusaha keras untuk membersihkan kode. Saya pikir itu sangat membantu bug menonjol.

Saya tidak setuju dengan konsep "kirim barang sialan sekarang", karena kode bersih adalah investasi untuk masa depan. Juga terlalu banyak perangkat lunak yang dikirimkan dengan bug yang terlalu banyak. Mengatasi satu bug menurut saya lebih baik daripada mengimplementasikan satu fitur baru.

Juga jika Anda melihat perkiraan produktivitas programmer , saya rasa skor saya tidak terlalu buruk. Menulis kode bersih adalah kebiasaan, dan semakin banyak pengalaman sebagai seorang programmer, semakin efisienlah jadinya. Jika seseorang tidak pernah mencobanya, jelas, ia tidak akan pernah mendapatkan pengalaman dengannya.

Poin lain yang perlu dipertimbangkan, adalah bahwa sebagian besar waktu pengembang digunakan untuk membaca kode, sehingga kode yang dapat dibaca sangat mengurangi waktu yang dihabiskan untuk membaca. Memahami algoritma tidak berdokumen misalnya bisa mahal dan mengundang bug baru.

Satu hal yang pasti saya lewatkan dan ingin memiliki satu hari adalah pemformat kode otomatis yang dapat saya sesuaikan dengan gaya saya, yang akan sangat menghemat waktu saya, terutama ketika membaca kode orang lain.

Pengkodean yang bersih memang memiliki tautan ke perfeksionisme, yang memang memiliki risiko tidak pernah terwujud, tetapi saya pikir itu terutama merupakan masalah ketika Anda mulai, karena Anda berinvestasi kemudian dan ketika menggunakan kembali potongan kode Anda yang elegan, dikombinasikan dengan pengalaman Anda , semakin tua Anda akan sangat produktif dan jauh lebih sedikit dihantui oleh bug daripada coders yang berantakan.

Ini adalah bagian kode yang menunjukkan gaya pengkodean saya.

2
user20416

Hindari "kode rias". Ada banyak pengembang di luar sana yang melakukan hal-hal murni karena kesombongan (atau karena OCD) dan tidak ada yang lain. Celana dalam saya benar-benar terbelit oleh orang-orang itu.

1
ElGringoGrande

Saya menulis kode yang mencoba memecahkan masalah yang diberikan dengan cara yang paling efisien dan secara teori 'elegan'. Dalam pengertian itu hanya bersih. Jika kebetulan 'cantik' saat aku selesai, biarlah.

Apa yang saya temukan dalam pengalaman terbatas saya adalah bahwa ketika orang mengeluh tentang 'kode bersih', keburukan biasanya merupakan hasil dari solusi yang mengerikan daripada pengkodean konvensi.

1
Kurtis

Saya akan mengatakan saya berusaha untuk menulis kode yang lebih bersih, tetapi itu dapat berubah karena kendala waktu atau jika saya sedang mengerjakan sesuatu yang sulit. Itu cenderung menjadi berantakan ketika fokus pada membuatnya berfungsi. Lalu saya akan kembali dan membersihkan saat saya memeriksanya. Jika Anda kembali ke kode dan harus menghabiskan terlalu banyak waktu untuk menyegarkan ingatan Anda, Anda tidak cukup berkomentar.

Kode bersih itu baik tetapi seperti semua yang lain, itu hanya perlu cukup bersih. Mengindentasi 5 baris kode 4 spasi dan satu baris 5 spasi tidak menambah kesulitan membaca.

1
JeffO

Saya pikir itu tergantung pada apa yang Anda lakukan. Jika saya menulis aplikasi proof-of-concept maka saya pada dasarnya koboi-coding pantatku dan tidak melihat ke belakang. Jika saya sedang mengerjakan aplikasi yang sebenarnya akan saya kerjakan untuk sementara waktu, maka saya memastikan saya membuat kode dengan cukup baik serta membuatnya dimengerti sebulan dari sekarang.

Saya pikir styling kode Anda agak rapuh. Seperti yang dikatakan oleh beberapa orang di atas, pekerjaan Anda adalah membuat produk, bukan kode yang diformat, tetapi saya akan mengatakan setidaknya orang harus tetap dengan gaya komentar dan pengkodean yang jelas. Saya akan benci melihat setengah dari variabel unta yang dikurung dan setengah lainnya dari Hongaria.

Tetapi juga, itu tergantung pada apa yang Anda maksud dengan 'kode bersih'.

1
user7007

Refactoring kode Anda untuk membuatnya elegan membuatnya lebih mudah dibaca, dan lebih mudah dipelihara. Bahkan hal-hal kecil seperti menyelaraskan tugas variabel Anda:

int foo    = 1;
int bar    = 2;
int foobar = 3;

lebih mudah dibaca daripada

int foo = 1;
int bar = 2;
int foobar = 3;

yang berarti lebih mudah untuk membaca skim saat Anda debug nanti.

Juga, dalam PHP Anda diizinkan sejumlah blok kode acak. Saya menggunakan ini untuk mengelompokkan tugas-tugas logis:

// do x
{
    // ...
}

// do y
{
    // ...
}

Ini menambahkan definisi yang jelas ke kode yang relevan.

Edit: Sebagai bonus tambahan, mudah untuk mengawali salah satu blok kode logis dengan if (false) jika Anda ingin melewatinya sementara.

0
Craige

Saya akui melakukan itu; dan manfaatnya tidak terganggu setiap kali saya melihatnya. Saya kira itu juga lebih mudah dibaca, dan karena itu bug menjadi lebih jelas; tetapi alasan sebenarnya adalah bahwa saya tidak tahan kode jelek.

0
user281377