Sejauh yang saya tahu, pernyataan yang membingungkan Anda adalah kompromi pragmatis yang dibuat agar pedoman untuk melayani audiens seluas mungkin. Bergantung pada konteks spesifik Anda (lebih banyak tentang itu di bawah), Anda mungkin memiliki opsi untuk menyesuaikannya dan menggunakan pedoman ini dengan lebih efisien.
Anda lihat, pedoman merujuk pada "keberatan pribadi yang kuat" sebagai sarana untuk membenarkan pelanggaran. Keberatan semacam itu bukanlah sesuatu yang bisa diabaikan begitu saja, terutama jika ini berasal dari pengembang berpengalaman.
Keberatan ini mungkin salah, ingatkan Anda, tetapi (dan ini sangat TETAPI BESAR), mereka juga dapat menunjukkan bahwa aturan tertentu salah - baik secara umum atau dalam konteks proyek tertentu (salah satu contoh ketidakcocokan aturan adalah persyaratan untuk menyediakan login terperinci dalam kode kritis kinerja).
Saya pikir bahwa setiap panduan gaya yang masuk akal harus mempertimbangkan hal di atas dan mencoba mengakomodasi kemungkinan kebutuhan untuk menyesuaikan diri. Sekarang, jika panduan yang membingungkan Anda hanya ditargetkan untuk tim dewasa dengan proses dan lingkungan yang efisien dan halus, itu dapat dinyatakan jauh lebih tidak ambigu, misalnya seperti ini:
Aturan harus diikuti secara ketat, kecuali jika ada tantangan yang diajukan terhadap mereka - dalam hal ini aturan yang ditentang harus tetap diabaikan sampai ini diselesaikan - baik dengan menolak tantangan atau dengan menerimanya dan menyesuaikan aturan agar sesuai.
Anda mungkin menyukai hal di atas dengan lebih baik dan Anda mungkin berharap hal itu terjadi di mana-mana, untuk semua orang, tetapi lihat lebih dekat ke bagian "tantangan dimunculkan / tetap diabaikan / sesuaikan" dan tanyakan pada diri Anda bagaimana hal itu dapat diimplementasikan. Tanyakan pada diri sendiri berapa lama mungkin tergantung pada proyek dan tim. Jika butuh satu jam, apakah itu bisa diterima? Bagaimana jika dibutuhkan sehari, atau seminggu, atau ... sebulan?
Anda lihat, bahwa pendekatan tantangan-dan-abaikan-sampai-diselesaikan dapat membuka pintu lebar untuk penyalahgunaan jika itu disajikan sebagai panduan untuk proyek apa pun. "Ya, ya kami dengar, mari kita lakukan seperti yang dikatakan panduan ini. Pertama, isi formulir tantangan ini dan dapatkan persetujuan CEO / CFO / CTO; perkirakan ini akan memakan waktu satu atau dua minggu. Setelah itu, tunggu sampai kami memperbarui pemeriksaan kode kami ; itu mungkin memerlukan satu atau dua minggu lagi. Sementara itu, pastikan kode kritis kinerja Anda memformat pernyataan logging yang benar tentang setiap gerakan register. "
Saya tidak bisa membaca pikiran penulis panduan, tetapi masuk akal untuk berasumsi bahwa mereka ingin menghindari menggunakannya untuk membenarkan kekacauan seperti yang dijelaskan di atas. Dari perspektif ini, lebih aman untuk menyatakan dengan jelas bahwa panduan ini tidak mengambil tindakan penegakan hukum - dengan cara ini, betapapun canggungnya, masih memungkinkannya digunakan untuk berbagai tim dan proyek yang sewenang-wenang. Mungkin ada harapan bahwa tunjangan luas seperti itu membuat tim yang lebih matang dan efisien kesempatan untuk mempersempitnya secara wajar tanpa merusak produktivitas pengembang.
Diterapkan pada kasus spesifik Anda, menulis dokumen gaya pengkodean untuk tim Anda dan gagal tinjauan kode jika gaya tersebut tidak cocok - saya pikir Anda perlu mencari tahu berapa lama waktu yang dibutuhkan bagi pengembang untuk menantang aturan tertentu, biarkan diabaikan, diselesaikan, dan apakah itu berubah atau pulih tergantung pada resolusi.
Jika Anda mencari cara untuk membuat proses ini bekerja tanpa memasukkan banyak hambatan ke dalam alur kerja pengembangan Anda, maka pendekatan tantangan / resolusi yang diformalkan dan mudah memang patut dipertimbangkan daripada kekacauan "melanggar jika Anda menangis cukup keras".
Sebagai catatan, saya ingin membahas apa yang Anda tulis dalam komentar lain , "Asumsikan bahwa gaya pengkodean ideal, dan jika itu tidak terjadi, dll."
Ini asumsi yang berbahaya, sungguh. Saya mematahkan hidung saya (dua kali! Dalam satu proyek! Di mana saya memiliki pengalaman yang luas dan membayangkan bahwa saya tahu segalanya tentang hal itu, pikirkanlah) dan saya sangat menyarankan Anda untuk menjatuhkannya. Lebih aman untuk mengasumsikan bahwa pemandu gaya mungkin memiliki kesalahan dan berupaya memikirkan apa yang harus dilakukan jika kesalahan tersebut ditemukan.