it-swarm-id.com

Berurusan dengan kata-kata kotor dalam kode sumber

Bagaimana orang berurusan dengan kata-kata kotor dalam kode sumber dan komentar VCS. Simpan atau hapus?

Bagaimana dengan soft-expletives seperti WTF atau Arrgggh?

Apakah tidak profesional, ofensif atau sesuatu yang harus diabaikan?

34
sal

Seharusnya tidak disarankan

..you tidak mungkin tahu siapa yang akan melihat kode sumber selama masa pakainya.

Walaupun itu adalah bagian dari pekerjaan untuk frustrasi dengan potongan kode yang sangat kompleks atau lama dan ingin mengabaikannya, memasukkan kata-kata kasar/kata kasar/seni ASCII/lelucon buruk/komentar ofensif ke dalam kode sumber keduanya tidak profesional dan ide buruk dalam pengalaman saya. Terkadang, insinyur yang menulis komentar tidak menyadari efek akhirnya dari komentarnya - berikut adalah beberapa masalah yang saya lihat:

  • Sejumlah besar sumpah serapah dalam kode dirilis ke publik sebagai kode sumber terbuka/sampel.
  • Lelucon dalam rasa yang buruk menyebabkan pelanggaran mendalam bagi beberapa anggota tim yang menghasilkan pengadilan industri.
  • Pernyataan yang dibuang yang sebenarnya rasis/seksis/gender menyebabkan orang dipecat.

Sementara kita semua perlu memiliki beberapa outlet untuk frustrasi/bersenang-senang/japing tentang, kode sumber bukan tempat untuk melakukan ini, IMO. Anda tidak akan memasukkan komentar kasar/lelucon/komentar ofensif dalam Kontrak, Halaman Bantuan, Cetak Biru, atau dokumen profesional lainnya, meskipun dokumen-dokumen itu mungkin lebih jarang dibaca daripada kode sumber.

Jika para pemimpin tim mendapatkan semua tentang hal itu, akan ada kesal, jadi saya katakan 'lemah hati' dengan kata-kata yang tenang dengan insinyur yang bermasalah dan menyediakan mekanisme ventilasi yang sesuai untuk melepaskan Steam, apakah itu Facebook, pesan instan , hoki udara atau karung tinju.

Tidak ada pembelaan untuk mengatakan bahwa komentar dikompilasi baik - bagaimana dengan JavaScript, atau kode sisi klien dinamis lainnya?

Berikut adalah beberapa pengalaman dunia nyata yang saya miliki yang membentuk pendapat saya:

  • Saat bekerja di Microsoft, saya melihat bahwa seorang insinyur perangkat lunak tidak tahu ejaan yang benar dari "tidak bisa" - dia melewatkan o, l dan d - dan telah membumbui banyak kode dengan penjelasan panjang tentang bagaimana dia couldn't dapatkan X bekerja karena orang Y menyebabkan masalah Z. Kode-nya hebat; ejaannya tidak begitu baik. Cukuplah untuk mengatakan, setiap pengulas kode ini selanjutnya (mis. Saya) merasa khawatir melihat sejumlah besar sumpah acak dalam kode tersebut. Beberapa kode ini selanjutnya ditampilkan kepada mitra (driver driver). Bayangkan ketakutan mereka melihat sumpah serapah. Kata-kata kasar idealnya harus kepada manajer proyek dalam bentuk verbal (dalam hal ini orang Y dapat ditarik ke diskusi) atau mungkin melakukan pesan, tetapi tidak dalam sumber.

  • Di satu perusahaan, seorang individu yang berbahasa asing bergabung dengan tim yang sebagian besar berbahasa Inggris. Dia menulis komentar dalam bahasanya, berpikir bahwa tidak ada orang lain yang bisa membacanya. Ini baik-baik saja, sampai Babelfish/Google Translate merilis opsi 'ke bahasa Inggris' untuk bahasanya, di mana saat itu seluruh tim menerjemahkan beberapa komentar dan terkejut dengan komentar-komentar yang kotor dan sering menghina yang telah dibuat orang itu tentang perusahaan tersebut. , timnya dan seorang rekan kerja wanita. Canggung.

  • Di perusahaan lain, seorang lelaki benar-benar dibawa dengan seni ASCII seni dan memasukkan segala macam karya seni ke dalam kode sumbernya, tidak ternoda (atau mungkin diberkati) oleh pengulas kode. Setelah beberapa saat, ia berkutat dengan naga , untuk beberapa alasan, biasanya dengan semacam tag line. Kemudian, seorang Welsh bergabung dengan tim. Lambang nasional Wales adalah naga merah, jadi lelaki baru itu awalnya suka dengan gambar-gambar itu, tetapi kemudian tersinggung ketika beberapa tag line konyol bisa ditafsirkan sebagai ofensif Ya, beberapa mediasi pemimpin tim diperlukan, tetapi ini seharusnya tidak terjadi.


Nama/spesifik dihapus untuk melindungi yang tidak bersalah.

41
JBRWilkinson

Jika Anda menjual kode sumber Anda (mis. Anda adalah penulis komponen), mungkin kode itu tidak ada di sana.

Jika ini masalah kearifan, maka apa pun itu, terserah Anda.

Jika Anda melihat seseorang menulis banyak WTF maka mungkin itu pertanda bahwa Anda harus berbicara dengan mereka tentang masalah yang mereka hadapi.

Jika seseorang mengarahkan agresi mereka ke kode orang lain, maka mereka mungkin melecehkan orang itu dan Anda punya situasi yang sama sekali berbeda untuk dihadapi. Mungkin mereka memiliki keluhan yang sah dan tidak tahu bagaimana cara menyuarakannya. Mungkin mereka hanya brengsek.

Tidaklah bijak jika hanya memiliki semacam filter konten, apa pun yang ditulis pengembang itu penting dan memberi tahu Anda banyak hal tentang perkembangannya.

24
Peter Turner

Saya bekerja untuk perusahaan Fortune 500 yang mendesain, memproduksi, dan menjual produk-produk konsumen yang memiliki μControllers yang menjalankan kode yang dikembangkan sendiri. Litigasi selalu merupakan suatu kemungkinan, baik dari konsumen yang berharap untuk menjadi kaya dengan cepat, atau oleh pesaing yang mengklaim pelanggaran. Karena itu, kami menulis kode kami dan SEMUA komentar dengan pengetahuan bahwa itu mungkin (mungkin akan) berada di bawah pengawasan juri yang bermusuhan pada suatu waktu. Itu berarti bahwa nama variabel dan fungsi tidak boleh menyertakan istilah inciteful, seperti KILL_CHILD(int process_id). Sementara tujuan dari contoh fungsi ini bisa sangat baik untuk menghentikan proses anak, bagaimana juri yang bermusuhan melihat nama fungsi jika anak penggugat dibunuh saat menggunakan produk?

Komentar dalam kode bisa lebih buruk. Sementara tim pertahanan yang layak mungkin dapat menangani menjelaskan apa itu proses anak-anak (dari contoh sebelumnya) dan mengapa hal itu mungkin perlu dihentikan, hampir tidak mungkin untuk mempertahankan diri terhadap komentar seperti:

// The following section of code is REALLY BAD!!!  I hope
//  it doesn't burn anybody's house down.

Komentar tidak langsung seperti itu telah menjadi faktor penentu dalam kasus-kasus nyata pengadilan.

Pada topik terkait, nama-nama untuk proyek juga dapat memberatkan ketika di bawah mikroskop litigasi intens. Apakah Anda ingat kegemparan dari kelompok konservatif di pertengahan tahun 90-an ketika sumber berita teknologi melaporkan "SATAN Unleashed On The Internet"?

<rant_mode_off>

Dengan semua itu, untuk proyek pribadi Anda bebas melakukan apa yang Anda suka dalam kode Anda.

17
oosterwal

Jika itu mengganggu Anda dan Anda adalah honcho kepala, saya tidak mengerti mengapa Anda tidak dapat menerapkan aturan tentang ini. Anda adalah setelah semua pemimpin dalam situasi hipotetis ini.

Namun, jika itu hanya mengganggu Anda dan tidak ada orang lain yang keberatan mungkin Anda hanya perlu menyedotnya.

9
Sergio

Saya mungkin bukan orang yang tepat untuk bertanya karena saya sering menggunakan kata-kata yang tidak sopan.

Saya pikir itu sebagian besar tergantung pada bagaimana PC (Politically Correct) lingkungan Anda.

Jika saya membuat kode untuk perusahaan jas-dan-dasi saya akan mencoba untuk tidak menggunakan kata-kata kotor sama sekali tetapi jika itu untuk proyek hobi atau sesuatu yang saya cenderung berbicara pikiran saya lebih bebas.

Tampak bagi saya bahwa di AS dan beberapa negara lain orang lebih banyak PC (atau macet) daripada di Belanda tempat saya tinggal dan bekerja.

Sebagai bonus tambahan, berikut adalah beberapa statistik tentang senonoh dalam kode: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming- bahasa /

7
the JinX

Saya cenderung setuju bahwa itu bisa sangat tidak profesional, tetapi setiap orang meminta dari waktu ke waktu jadi saya mencoba untuk tidak menentangnya. Yang mengatakan, basis kode cenderung mencerminkan profesionalisme keseluruhan kelompok sehingga basis kode sarat eksplosatif dapat mencerminkan kelompok tidak profesional dan pertemuan mungkin perlu untuk "menerapkan beberapa polesan" ke grup. Demikian juga, jika tren tertentu muncul dalam kode, itu bisa menjadi indikator masalah umum dalam grup yang perlu diselesaikan (mis. API yang Anda kerjakan memiliki masalah yang membuat pengembang frustrasi).

Dalam hal basis kode, saya biasanya hanya mengedit komentar yang relevan agar aman untuk bekerja dan biarkan saja. Bergantung pada bahasa yang Anda gunakan, ini selalu merupakan ide bagus karena Anda tidak pernah tahu apa yang mungkin muncul di depan klien atau pelanggan.

6
rjzii

Apakah ini tidak profesional, ofensif atau sesuatu yang harus diabaikan?

Mungkin ketiganya ... tergantung sudut pandang Anda.

Sudah menjadi sifat manusia bagi manusia untuk mengekspresikan diri menggunakan "bahasa penuh warna" dalam situasi tertentu. Lebih dari itu dalam beberapa budaya daripada yang lain, dan beberapa orang lebih dari yang lain. Tetapi kecenderungannya bersifat universal.

Jika saya jadi Anda, saya akan mengabaikannya kecuali Anda bersedia membuat diri Anda tidak populer dengan rekan kerja Anda.

Namun, jika kode sumber/komentar VCS dipublikasikan di luar organisasi Anda, manajemen Anda mungkin ingin mengambil garis yang lebih kuat, dengan alasan bahwa bisnis tidak baik untuk menyinggung pelanggan Anda.

5
Stephen C

Salah satu masalah dengan kata-kata kotor adalah berbeda dari budaya ke budaya. Di AS, hal-hal yang tidak bersalah cenderung menjadi "bleeped out", sementara di negara lain sering Anda dapat mendengar bahasa yang sama dipertukarkan dalam diskusi parlemen.

Kata-kata kotor dalam kode dan komentar komit cukup umum, kemungkinan karena tampilan "tidak ada yang akan melihatnya". Saya pikir itu sebenarnya lebih umum sekarang karena sebagian besar organisasi melarang telur paskah.

Saya pribadi berpikir bahwa hal-hal yang tidak berhubungan dengan pelanggan (seperti materi komit internal) bukan masalah besar.

Namun, sebagian besar perusahaan multinasional dijalankan oleh departemen hukum dan "tempat kerja yang aman" dan semua itu, yang berarti bahwa apa pun yang dapat menyinggung setidaknya satu orang adalah masalah dan kemungkinan penyebab pemecatan. Aku benci mengakuinya, tapi aku cenderung tunduk pada peraturan mereka yang membayar gajiku.

Solusi cepat untuk masalah ini adalah memasang filter senonoh pada sistem kontrol sumber Anda (sebagai skrip presubmit atau cek biasa).

5
Uri

Saya pikir tidak apa-apa asalkan tidak lepas kendali seperti menjatuhkan bom di sana. Saya telah melihat seorang pria yang bekerja dengan saya menulis naskah antara dua karakter yang membahas berbagai objek yang mereka wakili masing-masing. Ada komentar multiline yang berjalan seperti 30 baris dari dua karakter ini berbicara bolak-balik satu sama lain.

/ * * igor: haruskah saya menjadikan diri saya masster publik? * Frankenstein: ah igor, aku akan mewarisi sifat terbaikmu ... * /

Itu berlangsung seperti ini untuk waktu yang lama. Dia menciptakan dua objek yang disebut, Anda dapat menebaknya: Frankenstein dan Igor sebagai bagian dari pemeriksaan kewarasan. Itu sebenarnya sangat kreatif tetapi membuang-buang waktu. Saya lebih suka melihat beberapa WTF atau sumpah serapah daripada skenario antara dua objek C # ...

3

Tergantung pada budaya perusahaan/klien. Misalnya, jika Anda mengembangkan perangkat lunak Alkitab, kata-kata kasar dalam bentuk apa pun pasti tidak disukai. Di sisi lain, seorang pengembang game mungkin tidak terlalu peduli (atau pergi ke ekstrim lain).

Saya selalu berpikir bahwa komentar apa pun (dalam kode atau komit) harus membant. Kata-kata tertentu menarik perhatian kita lebih dari yang lain - kata-kata kasar, bahkan variasi yang lembut, pasti diperhatikan. Mungkin bermanfaat untuk menarik perhatian pada sesuatu yang benar-benar salah tetapi Anda belum menemukan jalan keluarnya.

Yang mengatakan, saya tidak menggunakan kata-kata kasar tetapi saya kadang-kadang akan menggunakan hal-hal seperti "Doh!" atau "Hah?" yang tidak terlalu berbeda dalam semangat. Jika itu mengganggu Anda, bicarakan dengan pelaku - ia mungkin tidak memikirkannya. Jika mereka meminta Anda untuk mendaki dan Anda sangat menyukainya, pergilah ke manajer. Jika Anda tidak mendapat dukungan dari manajer, maka Anda harus belajar untuk hidup dengannya atau pergi ke tempat lain.

2
Berin Loritsch

Seperti orang lain katakan, itu tergantung pada tempat kerja dan siapa yang akan melihat kode sumber.

Jika saya menjual kode sumber saya akan memiliki repositori kedua hanya versi dirilis dan tidak mengizinkan komentar checkin di sana di luar deskripsi dari apa yang masing-masing menyediakan versi baru. Apa yang saya lakukan pada hari ke hari dan semua kesalahan langkah saya adalah antara saya dan tim saya, bukan klien saya.

Saat ini build server saya melaporkan OMG, WTF, kludge, mess, dan komentar TODO sebagai metrik pembersihan yang tersisa untuk melakukannya sekarang ini adalah bagian dari proses.

1
Bill

Jika Anda melihat kata-kata kotor dalam perangkat lunak sumber terbuka dan ingin menyingkirkannya, bersiaplah untuk kemungkinan Push-back. Jangan hanya menulis laporan tiga baris bug , dan mengharapkannya diterima. Tulis sebuah esai mini yang menjelaskan mengapa kata-kata yang tidak senonoh dan diskriminatif itu buruk, dan jauhkan dari bantahan.

1
Andrew Grimm

Yah, saya tidak begitu yakin apa lagi yang harus Anda katakan tentang kode seperti ini:

tocommit = (n + (COMMITSIZE/PAGESIZE) - 1) & ~(COMMITSIZE/PAGESIZE - 1);

Kode ini ditarik dari basis kode nyata, sangat kasar saya telah mencoba untuk mengoptimalkan akhir-akhir ini. (Kode ini open source, jadi saya tidak mengungkapkan rahasia majikan di sini atau apa pun.)

1
dsimcha

Saya pikir ini masalah preferensi pribadi. Hal itu tidak terlalu mengganggu saya, jadi saya mungkin akan meninggalkannya. Bahkan mungkin memberi saya petunjuk ke mana area masalah dalam kode.

Apakah mereka mengganggu Anda? Dari kenyataan bahwa Anda mengajukan pertanyaan ini, saya menduga mereka melakukannya. Dalam hal ini, hapus atau bersihkan menjadi komentar yang lebih tepat tentang apa yang salah.

0
Marcie