Berurusan dengan kata-kata kotor dalam kode sumber [ditutup]


34

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?


15
Kasus per kasus ... komentar adalah jalan bagi kepribadian pengembang. Sama seperti Anda harus berurusan dengan jenis kepribadian N Anda juga harus berurusan dengan jenis komentar N yang berdarah kepribadian pengembang. Bagaimana Anda berurusan dengan pengembang yang diberikan menggunakan kata-kata kotor ketika Anda berinteraksi dengan mereka melalui IM, email, secara lisan?
Aaron McIver

10
Saya harus memberi tahu beberapa Jr. devs sebelum tidak memasukkan kata-kata yang tidak senonoh. IMHO itu sangat tidak profesional. Jika Anda tidak akan bersumpah di depan rekan kerja atau klien Anda mengapa bersumpah dalam komentar / kode? Dan jika Anda bersumpah di depan rekan kerja dan klien Anda ... maka Anda memiliki lingkungan kerja yang jauh lebih santai daripada saya. :)
Tyanna

4
@Tyanna: Di tempat kerja terakhir saya, kami bahkan agak rasis! Jika Anda bisa menyebutnya begitu. Saya pikir kebenaran politik sangat buruk di antara rekan kerja yang saling melihat hari demi hari. Apakah Anda takut menceritakan lelucon rasis kepada seseorang yang Anda lihat selama 10 jam sehari? Kemudian lagi, saya tinggal di Bolivia - saya pikir AS memiliki mentalitas yang lebih banyak menuntut ini, menuntut itu dan itulah sebabnya tidak ada yang mau menginjak-injak jari kaki.

4
@Anna Lear: Tidak pernah ada orang yang digugat di Denmark karena menceritakan lelucon pedas. Namun AS ... Ini semua masalah suasana seperti apa yang Anda kerjakan. AS memiliki bobot lebih pada drone SDM yang memantau setiap hal kecil.

10
Lakukan saja grep f.ckpada kode sumber kernel Linux. Jika itu cukup baik untuk mereka, itu cukup baik untukku. Tetapi jangan pernah menyinggung sesuatu di tempat-tempat di mana ada sedikit peluang pelanggan dapat menemukannya. Saya melakukannya sekali dan untungnya kami berhasil menarik pembaruan di menit terakhir, tetapi itu tidak menyenangkan. (Ya, sebenarnya setelah itu.)
biziclop

Jawaban:


41

Itu harus dengan lembut dicegah

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

Walaupun itu semua 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.
  • Komentar 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 mengeluarkan uap, 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 merindukan o, l dan d - dan telah membumbui banyak kode dengan penjelasan panjang tentang bagaimana dia tidak bisa dapatkan X untuk bekerja karena orang Y yang menyebabkan masalah Z. Kode-nya hebat; ejaannya tidak begitu baik. Cukuplah untuk mengatakan, setiap peninjau kode ini selanjutnya (misalnya saya) khawatir untuk melihat sejumlah besar sumpah acak dalam kode. Beberapa kode ini selanjutnya ditampilkan kepada mitra (penulis 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 anggota 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 tertarik dengan seni ASCII dan memasukkan segala macam karya seni ke dalam kode sumbernya, tidak ternoda (atau mungkin diberkati) oleh peninjau kode. Setelah beberapa saat, dia memikirkan 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 senang dengan gambar-gambar itu, tetapi kemudian tersinggung ketika beberapa garis tag konyol bisa dianggap sebagai ofensif. Ya, beberapa mediasi pemimpin tim diperlukan, tetapi ini seharusnya tidak terjadi.


Nama / spesifik dihapus untuk melindungi yang tidak bersalah.


1
Saya akan menambahkan bahwa kata-kata kotor dalam sistem pelacakan cacat Anda tidak boleh didorong juga. Setelah berada dalam posisi meminta submitter untuk mengedit komentar mereka untuk menghilangkan kata-kata kotor, saya dapat memberi tahu Anda ini bukan posisi yang menyenangkan bagi pengawas / pemimpin tim / manajer. Terutama ketika mereka menolak.
cepat

@quickly_now, bagaimana Anda menangani situasi itu?

Saya bertanya lagi. Ketika orang itu menolak lagi, saya mengedit komentar itu sendiri untuk membersihkannya. Saya tidak berpikir ini layak melalui proses konseling / disiplin (langkah # 1 yang mengarah ke pemecatan), tetapi saya juga melaporkan kepada bos saya apa yang telah saya temukan dan lakukan. Kita semua sepakat bahwa itu tidak akan berlanjut kecuali diulang (dan itu tidak diulang). Tidak menyenangkan. [Saya harus menambahkan lebih lanjut bahwa komentar yang tidak sopan itu dilaporkan kepada saya oleh anggota staf lain yang peduli. Itu membuat masalah saya untuk dipecahkan. Terkadang posisi senior tidak sepadan dengan tambahan $ !!!]
cepat_now

"Tapi kemudian tersinggung ketika beberapa baris tag konyol bisa dianggap sebagai ofensif." Anda harus menjadi orang yang SANGAT sangat terganggu untuk tersinggung oleh gambar naga karena Anda orang Wales.
Miles Rout

24

Jika Anda menjual kode sumber Anda (yaitu Anda seorang penulis komponen), mungkin tidak ada di sana.

Jika ini masalah kearifan, maka apa pun yang terjadi, 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 terhadap 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.


1
+1 untuk poin tentang tidak menjual kode sumber sarat eksplosif. Kode harus diperiksa secara saksama untuk komentar semacam itu sebelum dikirim.
FrustratedWithFormsDesigner

2
Komentar kasar jelas bukan ide yang baik jika Anda seorang pengembang HTML. :)
biziclop

@biziclop, yang sangat disayangkan karena HTML adalah bahasa yang membuat frustasi. Lihat tautan @the jinx tentang tingkat senonoh dalam sumber. sepertinya Javascript terikat terlebih dahulu (tidak yakin apakah ini termasuk cacian javascript minified yang tidak disengaja)
Peter Turner

Filter konten sederhana kami yang berjalan di jenkins memiliki masalah dengan ini: void pushItem (...
sal

17

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 menjadi 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 pengadilan nyata.

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

<rant_mode_off>

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


1
+1 untuk menunjukkan aspek paling berbahaya dari perilaku UNPROFESSIONAL ini. Saya telah bekerja pada tim "uji tuntas" yang meninjau kode sumber perusahaan yang akan dibeli oleh F500 yang akan saya beli. Kami mencari hal-hal semacam ini untuk alasan yang Anda sebutkan dan itu membuat perbedaan siapa yang mendapat tawaran kerja terus-menerus dan siapa yang tidak ketika merger selesai. Khususnya sebuah perusahaan besar (berkantong tebal) tidak membeli perusahaan kecil untuk mewarisi pelecehan / permusuhan lingkungan kerja yang bermusuhan sehingga para pelaku diberhentikan / dibuat mubazir ketika pembelian selesai.
kloucks

5
KILL_CHILD hanyalah contoh yang tidak masuk akal. Dan saya ingin melihat kutipan pada "Komentar tidak langsung seperti itu telah menjadi faktor penentu dalam kasus pengadilan nyata." (Saya tidak hanya mengatakan bahwa sebagai STFU ... Saya benar-benar ingin membaca kutipan.)
Wolfger


1
"Itu berarti bahwa nama variabel dan fungsi tidak boleh menyertakan istilah inciteful, seperti KILL_CHILD" Itu hal paling bodoh yang pernah saya baca dan Anda harus malu bahkan menyiratkan bahwa KILL_CHILD adalah nama yang buruk untuk fungsi.
Miles Rout

9

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.


Begini masalahnya: Saya tidak "menyedot" hal-hal.
gnasher729

7

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

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

Jika saya 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 kata-kata kotor dalam kode: http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/


1
Saya pikir ini lebih tergantung pada sektor - dalam lingkungan tekanan tinggi seperti keuangan, kata-kata kasar adalah umum.
JBRWilkinson

itu juga sangat tergantung pada apa yang Anda anggap "tidak senonoh". Seperti dalam artikel yang ditautkan "lol" dan "rofl" dipilih sebagai kata-kata kotor, ketika sebagian besar dari kita saya pikir tidak akan mengklasifikasikan mereka seperti itu.
jwenting

Ini bukan tentang PC - ini tentang penggunaan bahasa yang tepat (Anda bisa benar-benar bukan PC dan masih memilih untuk tidak menggunakan senonoh - Anda bisa sangat ofensif dan kasar dan masih tidak menggunakan senonoh). Perlu dipikirkan dalam hal tidak memberikan pelanggaran yang tidak semestinya - yang tidak semestinya karena hampir semuanya menyinggung seseorang - tetapi kebanyakan dari kita tahu di mana garis itu dan umumnya kata-kata bersumpah berada di sisi yang salah. Menahan diri di area ini berguna - jika Anda tidak bersumpah banyak atau sering saat orang memperhatikan ...
Murph

6

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 (yaitu 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.


3
+1, Menarik, saya tidak berpikir untuk menggunakan pola penampilan-sumpah serapah untuk melacak frustrasi dengan fungsi / perpustakaan tertentu.
FrustratedWithFormsDesigner


5

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.


Kuncinya di sini adalah "dalam situasi tertentu" - yaitu di mana sesuai dan dapat diterima. Saya pikir masuk akal untuk menyarankan bahwa komentar (kode atau komit) bukan tempat yang benar-benar dapat diterima dan karenanya tidak pantas.
Murph

5

Salah satu masalah dengan kata-kata kotor adalah berbeda dari budaya ke budaya. Di AS, hal-hal yang tidak bersalah cenderung "dihilangkan", sementara di negara-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 komitmen 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 menginstal filter senonoh pada sistem kontrol sumber Anda (sebagai skrip presubmit atau cek biasa).


2
Saya harus tidak setuju dengan saran Anda tentang filter senonoh otomatis. Pertama, Anda berisiko mengalami masalah Scunthorpe, dan kedua, seperti yang dikatakan Stephen C, kata-kata kotor kemungkinan merupakan gejala dari masalah lain dan melarangnya tidak akan memperbaikinya secara ajaib.
Scott

2
+1 Untuk filter senonoh, tetapi penting untuk menghindari "kesalahan clbuttic" ( thedailywtf.com/Articles/The-Clbuttic-Mistake-.aspx )
rjzii

filter tidak senonoh tidak bekerja. Mereka cenderung memblokir hal-hal yang tidak bersalah dan membiarkan hal-hal buruk melewati. Mereka juga cenderung mudah dikerjakan.
jwenting

cntd. Saya melakukan moderasi untuk forum fotografi alam. Ketika admin memutuskan untuk memasang filter senonoh, semua diskusi tentang berang-berang, kucing peliharaan, burung, dll. Orang-orang akan disensor. Sebelum dihapus lagi, pengguna mulai mengembangkan cara di sekitar filter. Jika Anda tidak dapat berbicara tentang perjalanan Anda untuk menembak berang-berang (oops, 3 kata-kata buruk dalam satu kalimat pendek), Anda berbicara tentang tr.ip Anda ke sh.oo.t be.ave.rs sebagai contoh dan filter akan terlalu stu.pi.d (kata lain yang dilarang) untuk menangkapnya.
jwenting

Bagi saya argumen untuk menghindari filter yang tidak senonoh "karena banyak dari mereka omong kosong" masuk akal seperti menghindari filter spam, sql sanitizers, dll. Ada opsi pihak ketiga yang layak di luar sana. Jika Anda hanya menggunakan regexps, Anda SOL.
Uri

3

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 # ...


Itu lucu. Tidak produktif, tapi lucu.
Paul Nathan

@ Paul: Ha! Maaf, ya - tidak terlalu produktif tetapi konyol melihat hari ini sambil melihat-lihat beberapa kode.
Nodey The Node Guy

2

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, pengembang game mungkin tidak terlalu peduli (atau pergi ke ekstrim lain).

Saya selalu berpikir bahwa komentar apa pun (dalam kode atau komit) harus membantu . Kata-kata tertentu menarik perhatian kita lebih dari yang lain - kata-kata kasar, bahkan variasi yang lembut, pasti diperhatikan. Mungkin bermanfaat untuk meminta 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.


Maaf, apa itu "perangkat lunak Alkitab"? (bukan bahasa Inggris asli di sini).
Benteng

2
Alkitab adalah tempat doktrin Kristen ditulis. Perangkat lunak Alkitab adalah perangkat lunak yang dapat digunakan orang Kristen untuk memeriksa silang teks dalam terjemahan yang berbeda, mencari tahu apa yang dikatakan para sarjana tentang suatu bagian tertentu, dan secara umum mempelajari teks tersebut. Satu tulisan suci berbicara tentang "Jangan biarkan komunikasi yang korup keluar dari mulut Anda" yang merupakan bahasa Inggris kuno untuk tidak disumpahi, atau berbicara tentang hal-hal yang menghancurkan orang. Saya yakin ada aplikasi keagamaan lain di mana mengutuk sama-sama tidak disukai.
Berin Loritsch

3
Orang Kristen membongkar executable untuk mencari kata-kata kutukan di sumbernya?

Eh, komentar tidak bisa dikompilasi sehingga bahkan tidak akan berfungsi;)
the JinX

5
Jadi jika saya menulis perangkat lunak Alkitab saya harus menyensor semua hal-hal cabul dalam Alkitab?
Wooble

1

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.)


3
Bunuh sumbitch itu dengan api dan magnet!

1

Seperti yang 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 yang dirilis dan tidak mengizinkan komentar checkin di sana di luar deskripsi tentang apa yang disediakan oleh setiap versi baru. Apa yang saya lakukan pada hari ke hari dan semua salah 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 masih harus dilakukan saat ini yang merupakan bagian dari proses.


1

Jika Anda melihat kata-kata kotor dalam perangkat lunak open source dan ingin menyingkirkannya, bersiaplah untuk kemungkinan push-back. Jangan hanya menulis laporan bug tiga baris , dan berharap laporan itu diterima. Tulis sebuah esai mini yang menjelaskan mengapa kata-kata yang tidak senonoh dan diskriminatif itu buruk, dan sanggah lebih dulu.


0

Saya pikir ini masalah preferensi pribadi. Hal itu tidak terlalu mengganggu saya, jadi saya mungkin akan meninggalkannya. Mungkin bahkan 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.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.