Baru-baru ini, saya menemukan sejumlah proyek open source Ruby (atau sebagian besar adalah Ruby) di GitHub yang ketika diperiksa dengan alat penganalisa kode seperti Rubocop , membuat banyak pelanggaran .

Sekarang, sebagian besar pelanggaran ini termasuk menggunakan tanda kutip ganda alih-alih tanda kutip tunggal (bila tidak interpolasi), tidak mengikuti aturan 2 spasi per level, melebihi aturan panjang garis 80 karakter, atau menggunakan {dan }untuk blok multi-garis.

[The] Ruby style guide merekomendasikan praktik terbaik sehingga programmer Ruby dunia nyata dapat menulis kode yang dapat dikelola oleh programmer Ruby dunia nyata lainnya. ~ Sumber: Panduan Gaya Ruby

Meskipun kecil dan mudah diperbaiki, apakah pantas untuk mengubah gaya pengkodean proyek sumber terbuka dengan memperbaiki pelanggaran dan membuat Permintaan Tarik? Saya mengakui bahwa beberapa proyek, seperti Rails, tidak menerima perubahan kosmetik dan beberapa terlalu besar untuk "diperbaiki" sekaligus (Rails misalnya menghasilkan lebih dari 80.000 pelanggaran ketika Rubocop dijalankan - terlepas dari itu, mereka memiliki serangkaian kecil kode sendiri konvensi yang harus diikuti ketika berkontribusi). Lagi pula, Panduan Gaya Ruby ada karena suatu alasan bersama dengan alat-alat seperti Rubocop.

Orang - orang menghargai konsistensi sehingga membuat perubahan semacam ini adalah melakukan hal yang baik untuk komunitas Ruby secara umum, bukan?

[Penulis Panduan Gaya Ruby] tidak datang dengan semua aturan entah dari mana - mereka sebagian besar didasarkan pada karir saya yang luas sebagai insinyur perangkat lunak profesional, umpan balik dan saran dari anggota komunitas Ruby dan berbagai sumber daya pemrograman Ruby yang sangat dihargai, seperti "Pemrograman Ruby 1.9" dan "Bahasa Pemrograman Ruby". ~ Sumber: Panduan Gaya Ruby

Bukankah tidak mengikuti konvensi gaya pengkodean komunitas dan praktik terbaik pada dasarnya mendorong praktik buruk ?

Tanyakan pada pengelola.

Gaya pengkodean adalah diskusi yang cukup subyektif, dan aturan seperti panjang garis maksimum 80 karakter cukup subyektif - sementara kesepakatan umum seharusnya bahwa garis pendek lebih baik untuk dibaca, 80 mungkin terlalu ketat untuk beberapa orang dengan ukuran layar saat ini dan IDE.

Aturan lain dapat diabaikan dengan sengaja juga. Misalnya, pengembang mungkin menganggap penggunaan global tanda kutip ganda lebih baik untuknya dan bersedia menerima "risiko" interpolasi yang tidak disengaja dan peningkatan waktu parsing yang sangat kecil.

Banyak pengelola juga tidak menyukai perubahan gaya pengkodean besar karena membosankan untuk ditinjau dan ada kemungkinan bahwa hal itu dapat menyebabkan kesalahan. Sebagai contoh, sebuah string dapat dialihkan ke kutipan tunggal, meskipun itu berisi interpolasi yang disengaja dan seharusnya menggunakan kutipan ganda. Maintainers lebih suka melakukan pembersihan gaya saat mengerjakan kode aktual sehingga mereka dapat memverifikasi perubahan gaya tidak memperkenalkan bug baru.

Anda tampaknya termotivasi sebagian besar dengan menghormati otoritas alat rubocop dan Ruby Style Guide, yang mungkin tidak dibagi oleh pengelola. Mereka sudah memiliki gaya mereka sendiri, dan sudah terbiasa dengan hal itu, sehingga setiap perubahan akan memengaruhi setiap orang yang mengerjakan proyek, dan itu banyak pekerjaan, terutama jika proyek itu besar.

Pertimbangkan motivasi para pengelola. Mereka (mungkin) ingin orang baru bergabung dengan mereka dengan mengirimkan perbaikan bug, laporan bug, kode kerja, dan dokumentasi yang ditulis dengan baik. Jika Anda muncul dan berkata "Anda memiliki pelanggaran di rubocop" mereka tidak akan berpikir "Oh bagus, seseorang yang baru membantu berbagi beban", mereka akan berpikir "Siapa orang ini? Mengapa dia memberitahu kami melakukan apa?".

Proyek open source cenderung meritocracies: Anda mendapatkan rasa hormat berdasarkan kualitas pekerjaan Anda. Jika Anda muncul dan melakukan hal-hal besar dan kemudian memunculkan kekhawatiran gaya Anda, mereka lebih cenderung mendengarkan, meskipun mereka mungkin masih mengatakan tidak. Ada sumber terbuka yang mengatakan "Bicara itu murah, tunjukkan kodenya".

Pragmatisme atas Dogma, selalu. Panduan gaya pengkodean adalah bentuk kejahatan yang sangat berbahaya yang menarik perhatian dari masalah arsitektur menuju omong kosong sembrono seperti pengutipan tunggal / ganda. Tanyakan kepada diri sendiri: Apakah itu benar-benar membuat perbedaan?

Mereka mungkin baik sampai titik tertentu, tetapi begitu Anda memperlakukan mereka dengan semangat yang hampir religius, Anda sudah melangkah terlalu jauh. Itu adalah pedoman, saran, opini, BUKAN fakta.

Haruskah mereka diabaikan begitu saja? Tidak, ada gunanya menggunakan alat untuk mendapatkan gambaran umum tentang apa yang perlu dilihat, tetapi tidak lebih.

Sungguh mengherankan seberapa sering tipe junior membingungkan opini.

Anda dapat menarik perubahan ini hanya jika ada masalah terbuka untuk memperbaiki pemformatan. Kalau tidak, mulailah cabang Anda sendiri, dan jika penulis melihat bahwa lebih banyak orang menggunakan cabang Anda hanya karena lebih mudah dibaca. Mereka akan bergabung di cabang sendiri, tetapi bersiaplah untuk mempertahankan cabang Anda dengan menggabungkan pembaruan dan terus memperbaiki pemformatan.

Jika proyek itu tidak cukup penting bagi Anda untuk tetap mempertahankan cabang Anda sendiri, maka itu tidak layak dibersihkan di tempat pertama.

Permintaan tarik dapat diambil secara pribadi oleh penulis. Itu bukan mekanisme untuk menawarkan kritik, dan memformat ulang semua kode bisa dianggap sebagai kritik.

Jika Anda tidak ingin mempertahankan cabang Anda sendiri, tetapi Anda ingin berkontribusi pada proyek. Buka masalah baru dan jelaskan mengapa format saat ini menyebabkan Anda mengalami masalah, kemudian tawarkan untuk menyelesaikan masalah bagi penulis. Jika penulis setuju, maka mereka akan memberikan masalah kepada Anda dan Anda sekarang memiliki izin untuk mengajukan permintaan.

Anda telah menyentuh subjek yang saya setuju adalah masalah merajalela di GitHub . Selain memformat, ada sejumlah proyek yang salah menggunakan anotasi dan yang menyebabkan kekacauan dengan banyak IDE. Saya dapat memikirkan tiga proyek yang sangat populer yang menggunakan flag yang tidak benar yang menyebarkan pesan peringatan di IDE saya. Saya telah mengirim permintaan tarikan untuk memperbaikinya, tetapi penulis tidak menggunakan IDE yang sama, sehingga permintaan tarikan diabaikan.

Bercabang, menggabungkan dan memperbaiki tampaknya menjadi satu-satunya solusi.

Diambil dari situs Rubocop sendiri (penekanan milik saya):

Satu hal yang selalu mengganggu saya sebagai pengembang Ruby - pengembang Python memiliki referensi gaya pemrograman yang hebat (PEP-8) dan kami tidak pernah mendapatkan panduan resmi , mendokumentasikan gaya pengkodean Ruby dan praktik terbaik.

Tolong mengerti:

Tidak ada Panduan Gaya Ruby Resmi

Saya tidak mengatakan bahwa panduan gaya buruk. Tetapi tidak hanya tidak ada panduan resmi, tetapi memiliki panduan gaya adalah pilihan yang dibuat pada tingkat pribadi, proyek, tim, perusahaan. Panduan gaya adalah, untuk menggunakan istilah psikologi, "norma sosial dalam kelompok".

Apa artinya itu bagimu? Nah, jika Anda tidak dianggap sebagai bagian dari grup, itu berarti apa pun yang Anda - atau situs web lain katakan - kemungkinan besar tidak akan berpengaruh pada grup. Jadi, jika Anda bukan kontributor aktif untuk proyek tertentu, maka kemungkinan besar saran Anda akan diabaikan, atau paling tidak akan menjadi pengingat pertimbangan sebelumnya tentang memiliki panduan gaya. Paling buruk itu akan dianggap sebagai penghinaan, atau sebagai penyelundup atau bikeshedder menempel hidung mereka di tempat yang bukan miliknya.

Tidak bisakah Anda menyarankan Panduan Gaya?

Sebenarnya, itulah yang ingin Anda lakukan: Anda percaya pada nilai panduan gaya, Anda sangat menghargai konsistensi, dan Anda ingin menginjili untuk dedikasi pada pedoman gaya terpadu.

Tidak apa-apa, selama Anda benar-benar jelas tentang apa yang Anda maksudkan dan apa yang ingin Anda capai. Jika Anda percaya pada Panduan Gaya tertentu dan percaya itu adalah The One True Style Guide, atau setidaknya lebih baik daripada apa pun yang dilakukan oleh orang-orang kafir yang melanggar hukum ini, maka itu juga tidak masalah.

Tetapi apa yang orang tidak hargai adalah diberi tahu bahwa perilaku mereka tidak sesuai dengan aturan tidak resmi, tidak mengikat, dan sebagian besar arbitrer yang berasal dari sumber yang mereka tidak anggap sebagai otoritas yang sah. Ketika itulah yang ingin Anda lakukan, atau jika hanya itu yang dianggap Anda lakukan, Anda akan mendapatkan lebih sedikit "perawatan karpet merah", dan lebih banyak "penduduk asli yang marah dengan tombak dan panci besar mendidih" pengobatan.

Untuk memberikan pendapat alternatif di sini, dalam banyak kasus, perubahan seperti itu akan diterima. Proyek open source cenderung memiliki banyak penulis. Seringkali tidak ada "gaya pengkodean"; gaya adalah apa pun yang digunakan orang yang menulis kode tersebut untuk menggunakannya. Jika satu file ditulis oleh orang yang berbeda dari yang lain, gayanya mungkin juga berbeda. Bahkan dalam proyek-proyek di mana ada gaya konsensus, kecuali mereka memeriksa gaya ini secara teratur, sering tidak digunakan.

Contoh umum dari hal ini dalam pengalaman saya adalah ketika seseorang berkontribusi beberapa kode melalui permintaan tarik yang berkualitas relatif rendah. Namun, kode dapat berfungsi. Orang yang berbeda memiliki pandangan berbeda tentang hal ini. Beberapa orang akan menolak untuk menggabungkan permintaan tarik kecuali gayanya bagus. Beberapa orang tidak peduli, asalkan kodenya berfungsi. Beberapa orang lebih suka memiliki gaya yang baik, tetapi mereka tidak ingin menakut-nakuti kontributor dengan sekelompok "memperbaiki ruang putih di sini" komentar (Saya pribadi selalu merasa sedikit bersalah membuat komentar ini, meskipun saya tahu mereka lebih baik baik dari basis kode, karena itu merasa seperti itu mungkin menakut-nakuti kontributor pergi).

Jadi jangan langsung berasumsi bahwa gaya yang Anda lihat adalah gaya yang diinginkan proyek. Bahkan, itu mungkin dapat digeneralisasi untuk berkontribusi pada open source secara umum: jangan berasumsi bahwa kode yang dimiliki proyek open source adalah kode yang diinginkan .

Anda harus mengetahui beberapa hal, meskipun:

• Beberapa orang religius tentang gaya. Jika menjadi jelas bahwa mereka tidak mau mengalah, maka jangan repot-repot.

• Ini adalah masalah besar bikeshed . Semua orang dan saudara mereka memiliki pendapat tentang hal-hal ini. Menggabungkan permintaan tarikan seperti itu bisa jadi sulit karena hal ini.

• Mungkin juga sulit untuk mendapatkan permintaan tarikan seperti itu karena akan mendapatkan konflik penggabungan dengan sangat cepat; pada dasarnya setiap kali ada bagian dari basis kode yang Anda ubah perubahan, bahkan jika itu dalam cara sepele.

Saya akan tetap dengan pendekatan "minta dulu". Jika mereka terbuka untuk itu, dan Anda bersedia untuk tetap dengan permintaan tarik sampai selesai, maka lakukanlah.

Saya dulu suka memiliki panduan gaya yang baik, tetapi mengingat keadaan di Ruby, "Saya sudah pindah".

Pada dasarnya saya hidup dengan apa yang saya kerjakan dan mengikuti konvensi umum yang saya pelajari dari sejumlah pekerjaan.

Untuk Ruby, yang merupakan bahasa pilihan saya, saya juga (di kepala saya) membagi gaya menjadi preferensi dan praktik terbaik yang diterima secara universal. Hal-hal yang diterima secara universal saya dapat mengirimkan perubahan sebagai bagian dari permintaan perubahan untuk masalah atau permintaan cabang fitur.

Contoh masing-masing gaya (menurut saya):

Diterima secara universal untuk Ruby:

• spasi bukan tab
• dua indentasi ruang
• method_names_use_underscores
• Konstanta mulai dengan Caps.

Diterima secara umum:

• Jangan gunakan tanda kurung jika tidak perlu
• Gunakan { }untuk satu blok garis dan do enduntuk blok multi-garis.
• CONSTANTS_ARE_IN_ALL_CAPS
• Gunakan pernyataan predikatif ( cond ? true : false) lebih if thenjika ekspresi cocok pada 1 baris.

Preferensi pribadi:

• Panjang garis 120 karakter
• whenpernyataan kasus diberi indentasi 2 dari pernyataan kasus.
• Gunakan tanda kutip tunggal kecuali jika dobel diperlukan.

Tidak ada perjanjian:

• Pernyataan Kasus
• Panjang garis

Praktik terbaik:

• metode kecil, <= 5 baris jika memungkinkan.
• kelas kecil, <= 100 baris jika memungkinkan.
• Hindari konstanta
• Kode memiliki tes

Akhirnya, seperti yang orang lain perinci, Anda harus bertanya terlebih dahulu. Pada akhirnya, kunci gaya adalah komunikasi antara pengembang dan kepekaan terhadap orang lain. Sebagai contoh jika saya ingin membuat perubahan gaya pada proyek open source, saya akan sering melakukan permintaan tarikan untuk satu atau dua fitur aktual atau perbaikan bug terlebih dahulu. Setelah pengelola mengetahui saya dan melihat bahwa saya telah berkontribusi, maka saya dapat menyarankan perubahan gaya. Saya hanya menyarankan mereka. Misalnya "Saat melakukan fitur lain pada proyek x, saya perhatikan bahwa Anda memiliki 4 spasi indentasi dalam beberapa file dan saya bertanya-tanya apakah saya dapat mengubahnya menjadi 2?"

Meskipun kecil dan mudah untuk diperbaiki, apakah Anda pikir tidak apa-apa untuk mengubah gaya pengkodean proyek sumber terbuka dengan memperbaiki pelanggaran dan membuat Permintaan Tarik?

Singkatnya, tidak!

Tentu saja, saya berasumsi di sini bahwa ini hanya masalah gaya dan bukan bug yang sebenarnya - menarik permintaan untuk yang terakhir akan selalu masuk akal (IMO.) Saya juga berasumsi bahwa Anda adalah orang asing di proyek dan tidak berhubungan dengan orang-orang yang sudah memeliharanya.

Namun, di antara bahasa apa pun selalu ada beberapa orang yang memiliki preferensi mereka yang berbeda dari panduan gaya, baik atau buruk, dan mencoba untuk menerapkan perubahan gaya pada orang yang tidak Anda kenal , dan proyek yang bukan bagian Anda dari jika tidak ada lagi yang bisa datang di sebagai sedikit kasar. Lagi pula - apa yang Anda capai (pada kenyataannya) jika permintaan itu diterima? Kemungkinan besar, jika anggota dari satu proyek ingin mengubah gaya menjadi sesuatu yang berbeda, mereka akan sudah melakukannya - dan semua yang akan Anda lakukan dengan permintaan itu adalah memaksakan gaya pada mereka yang tidak selalu bekerja lebih baik untuk anggota yang ada.

Ini sedikit berubah jika Anda bersedia berkontribusi pada proyek dengan cara lain selain melakukan "perbaikan" gaya. Saya akan mengatakan jika Anda ingin membuka dialog dengan pengelola tentang bagaimana Anda ingin bekerja pada proyek tetapi menemukan gaya non-standar sulit, maka itu tidak masalah. Tapi saya benar-benar tidak akan hanya berkeliling secara membabi buta membuat permintaan tarikan untuk banyak proyek yang hanya berisi perubahan gaya!

Perubahan APAPUN bertanggung jawab untuk memperkenalkan bug, bahkan mengubah format tipografi kode.
Oleh karena itu tidak ada perubahan yang harus dilakukan pada kode kecuali ada kasus bisnis yang valid, dan "tetapi kode tidak terlihat bagus" atau "kode tidak mengikuti standar pengkodean" bukan kasus bisnis yang valid. Risikonya terlalu besar.
Sekarang, jika Anda membuat perubahan besar pada file sumber, menarik seluruh file sesuai dengan standar mungkin dapat diterima, tetapi kemungkinan besar Anda akan membuat perubahan kecil dalam hal ini hampir secara universal lebih disukai untuk menyimpan perubahan Anda sendiri di sejalan dengan kode yang ada meskipun kode yang ada tidak mengikuti standar pengkodean.
Heck, kode bisa jadi hasil dari pembuat kode dan kadang-kadang dibuat ulang. Generator kode terkenal karena menghasilkan kode jelek ...

Saya memiliki beberapa proyek .NET yang cukup berhasil, dan saya memiliki beberapa PR dari orang-orang yang tampaknya telah melalui kode dengan ReSharper dan StyleCop dan "memperbaiki" banyak hal. Saya tidak menerima PR tersebut, karena beberapa alasan:

• Walaupun banyak dari perubahan itu adalah untuk yang lebih baik, beberapa dari mereka berdampak negatif pada kode dalam beberapa cara, biasanya kinerja, dan memetik bagian yang baik terlalu banyak kerja keras.
• Bahkan jika semua perubahan itu jinak atau bahkan bermanfaat, setiap perubahan dalam setiap file di setiap komit perlu ditinjau, dan sekali lagi, itu hanya memakan waktu terlalu lama.

Yang mengatakan, jika ada yang ingin menambahkan beberapa kesalahan memeriksa atau komentar doc, saya akan menerima PR itu dalam sekejap.

Anda perlu mencari tahu apakah pengelola menganggap pelanggaran gaya pengkodean ini sebagai cacat, atau jika proyek memiliki standar berbeda untuk gaya pengkodean.

Jika memiliki standar yang berbeda, Anda dapat menawarkan untuk membantu mendokumentasikan atau memformalkannya. Maka mungkin ternyata ada beberapa pelanggaran gaya itu, dan Anda bisa memperbaikinya.