Memformat kode merupakan hal yang buruk saat menggunakan VCS?


24

Saya hampir selalu memformat kode saya sebelum saya berkomitmen untuk memastikan itu dilakukan dengan benar. Sebagian besar tim saya tidak begitu peduli dan tidak selalu memformat kode mereka dengan benar (hal-hal kecil yang tidak memengaruhi kode tetapi memengaruhi keterbacaan saat mencoba mempertahankannya).

Saya baru-baru ini menginstal alat-alat listrik VS yang memiliki opsi "Format pada save", dan membuat perubahan pada file yang tidak diformat sebelumnya. VP pengembangan baru saja datang kepada saya dan menegur saya karena memformat karena muncul di alat penggabungan karena hampir seluruh file diubah, alih-alih hanya satu atau dua baris (jadi dia tidak bisa melihat dengan tepat apa yang saya modifikasi dengan mudah), dan mengatakan kepada saya untuk menonaktifkan format simpan di masa mendatang. Meskipun saya memahami kekhawatiran itu, kadang-kadang saya merasa kesulitan untuk memilah-milah kode yang tidak diformat, dan IMO itu harus diformat dengan benar sepanjang waktu. Perhatikan bahwa saya tidak hanya memformat ulang hal-hal sambil lalu, tetapi ketika saya menulis kode saya akan menggunakan alat listrik atau menekan tombol perintah untuk memformat teks agar lebih mudah dibaca, dan dalam SVN ini muncul sebagai sebuah modifikasi.

Jadi saya bertanya, apakah selalu memformat kode sebenarnya adalah hal yang buruk? Apakah kekhawatirannya lebih valid daripada memastikan kode dapat dibaca?


8
dia benar, jadi mengapa tidak meminta semua tim untuk menggunakan alat format-on-save juga, maka Anda semua akan mendapatkan kode yang diformat dengan baik yang mudah dibaca, dan mudah untuk melihat komit diff.
gbjbaanb

12
Sebagian besar alat pembanding file yang baik memiliki filter untuk "perbedaan tidak penting" atau "abaikan spasi putih". Beberapa, seperti Beyond Compare, dikirimkan dengan filter khusus bahasa prebuilt. Gunakan untuk keuntungan Anda jika Anda memilikinya.
Michael K

7
Pemformatan kode sama pentingnya dengan perubahan yang dibuat. Keterbacaan harus menjadi salah satu prioritas tertinggi ketika Anda berada di tim. VP Anda harus tahu itu dan khawatir tentang hal itu.
Edgar Gonzalez

@ Edgar: +1. VP terlalu pemilih. Keterbacaan pertama ... dan opsi abaikan spasi berarti ini bukan masalah besar. Dan itu juga berarti ada masalah yang lebih besar karena anggota tim lainnya tidak peduli. Wakil Presiden harus lebih peduli tentang itu.
cepat,

Jawaban:


41

Pertama, tim Anda perlu memilih konvensi pemformatan dan mematuhinya. Anda harus mencapai kesepakatan dan meminta semua orang untuk menaatinya sehingga Anda tidak memiliki orang yang mempermasalahkan seperti apa jadinya. Ini seharusnya tidak hanya menjadi sesuatu yang Anda lakukan sendiri.

Adapun pertanyaan Anda yang sebenarnya. Memformat kode bukanlah hal yang buruk. Apa yang buruk adalah membuat perubahan pemformatan besar dalam komit yang sama dengan perubahan kode. Ketika tim Anda mencapai konsensus tentang bagaimana hal-hal harus diformat, buat satu pass melalui kode dan format semuanya. Periksa dengan sendirinya. Pesan komit akan memperjelas bahwa perubahan itu hanya ruang putih dan tidak berfungsi. Kemudian ketika Anda perlu membuat perubahan fungsional, mereka berada dalam komit yang berbeda sehingga mereka dapat terlihat dengan jelas.


itu masih tidak membantu jika Anda ingin membandingkan perubahan dari beberapa revisi yang lalu, tetapi lebih baik daripada perubahan kode + perubahan format dalam 1 go. Tentu saja, jawaban ini juga berlaku untuk refactoring.
gbjbaanb

1
+1: Selain itu, ada baiknya menggunakan sesuatu seperti Stylecop atau alat lain yang melakukan autoformats dan memberlakukan gaya. Kemudian, sinkronkan pengaturan antara semua anggota tim sehingga pemformatan konsisten di semua orang dan Anda tidak harus mengingat apa aturan format "benar".
Ryan Hayes

3
Jika OP ditegur karena mencoba memformat satu dokumen, sesuatu memberitahu saya dia tidak akan bisa menyarankan menggunakan StyleCop.
Wayne Molina

3
@ gbjbaanb: Ya. Inilah sebabnya mengapa yang terbaik adalah membuat keputusan semacam ini di awal. Proyek saya sekarang memiliki pengaturan formatter Eclipse diperiksa ke dalam repositori sehingga kita tahu semua orang memiliki pengaturan yang sama.
unholysampler

1
@quickly_now: Inilah sebabnya kami memiliki manajer dengan hak veto. Jika orang tidak bisa setuju, mereka bisa membuat keputusan.
unholysampler

29

Tidak, memformat kode sangat penting . Namun, komitmen harus dilakukan dalam dua kelompok:

  1. Perubahan kosmetik - apa pun yang membuat kode lebih mudah dibaca.
  2. Perubahan lainnya - segala sesuatu yang mempengaruhi kode.

Gunakan pesan komit untuk menandakan bahwa hanya kosmetik yang telah diubah. Ini dapat dengan mudah dilewati saat mencari modifikasi yang lebih substansial.


3
Selain itu, ini juga merupakan praktik yang baik untuk memutuskan konvensi pemformatan tertentu antara tim Anda. Jangan hanya memformat kode dari orang lain tanpa mendiskusikan hal ini terlebih dahulu.
Steven Jeuris

Ya .. Tapi Anda tahu, kadang-kadang sangat menggoda untuk memformat kekacauan sialan itu "saat Anda sedang melakukannya". Selain itu, mencoba memisahkan perubahan kosmetik dari perubahan fungsional dapat menjadi masalah jika Anda menggunakan VS dan memformat sesuatu secara otomatis. Oh, dan tidak ada yang akan mengatakan bahwa Anda melakukan beberapa pemformatan bodoh saat Anda memiliki Tugas Sangat Penting yang harus dilakukan dengan melihat riwayat commit
Dyppl

10

Anda berdua benar, tetapi Anda berdua bisa mendapatkan apa yang Anda inginkan. Format kode terlebih dahulu, periksa perubahan itu saja. Selanjutnya, buat perubahan fungsional Anda dan periksa itu sebagai langkah kedua.


3
Saya pikir ini adalah solusi terbaik untuk situasi Anda saat ini, tetapi Anda harus membicarakannya dengan tim Anda. Namun, Anda memiliki masalah yang lebih besar, yaitu kurangnya standar pengkodean.
Thomas Owens

2
Sepakat. Saya bertanya-tanya apakah lingkungan OP adalah salah satu tempat koboi di mana standar dihindarkan untuk "mempercepat segalanya".
Wayne Molina

4

Saya juga pemformat nit, jadi di sini beberapa kiat:

  • Langkah pertama yang diperlukan: minta tim untuk menyetujui beberapa standar format dasar, seperti tab vs spasi, posisi brace, gaya komentar, dll. Sekarang perubahan format Anda tidak akan mengejutkan semua orang, dan Anda tidak akan melangkah pada setiap jari kaki.

  • Bersihkan pemformatan hanya di sekitar kode yang Anda ubah. Jika Anda melakukan perubahan hanya pada satu fungsi, maka bersihkan fungsi itu. Setidaknya seiring waktu Anda akan memiliki kode yang lebih tampan.

  • Lakukan overhaul pemformatan besar sebagai komit terpisah, tanpa perubahan kode lainnya. Anda hanya harus melakukan ini ketika Anda cenderung tidak ingin membandingkan kode setelah perubahan sebelum perubahan, karena membandingkan di seluruh diff seperti itu bisa mengganggu. Saya biasanya melakukan pembersihan sebagai hal pertama sebelum pengembangan besar pada kode itu.

  • Dapatkan alat diff yang baik yang dapat melakukan penandaan bahasa terhadap perubahan signifikan dan perubahan tidak signifikan. Perbedaan favorit saya juga Beyond Compare menandai perubahan kode aktual dalam satu warna dan hanya perbedaan spasi / komentar pada warna lain.

edit untuk satu tip lagi:

  • Ini bervariasi dari bahasa ke bahasa, tetapi untuk sebagian besar perubahan kosmetik pada kode, Anda harus dapat membandingkan biner yang dikompilasi sebelum dan sesudah pembersihan besar untuk memastikan Anda tidak mengacaukannya.

Selama Anda tidak menyertakan tag VC dalam biner (atau membuat informasi).
Vatine

2

Anda seharusnya tidak memformat ulang dan melakukan perubahan pada kode orang lain kecuali:

  • Anda adalah manajer yang berusaha untuk menetapkan standar pengkodean tim
  • manajer Anda telah meminta Anda untuk membersihkan kode agar mematuhi standar pengkodean tim
  • Anda sedang membersihkan kode dari pengembang tidak lagi di tim Anda untuk mematuhi standar pengkodean tim.

Anda akan melihat dalam semua kasus saya merujuk pada standar pengkodean tim. Saya sangat percaya pada standar pengkodean yang masuk akal dan disepakati untuk tim. Jika Anda memilikinya, maka pengembang asli harus kembali dan membersihkan kodenya untuk mematuhi standar tim, Anda tidak boleh melakukan itu di belakang mereka. Jika Anda tidak memiliki standar (dan Anda harus), maka Anda tidak boleh memodifikasi kode anggota tim lain untuk mematuhi filosofi Anda, terutama di belakang mereka. Ingat, Anda adalah bagian dari tim dan sementara standar pengkodean itu penting, begitu juga kepercayaan dan rasa hormat di antara anggota tim.


"Di belakang punggung mereka": ini kembali ke masalah psikologis kepemilikan kode (atau perang wilayah pengembangan).
rwong

2
"Kode orang lain" adalah cara yang menarik untuk mengatakannya. Saya mengerjakan produk perusahaan saya, yang disusun dari kode yang dimiliki perusahaan saya, yang saya dan anggota tim saya kerjakan. Itu tidak di belakang mereka dengan cara apa pun untuk memperbaikinya ke standar saat mengerjakannya. Namun, saya setuju bahwa solusi yang ideal adalah membuat pengembang asli membersihkannya sesuai standar.
Caleb Huitt - cjhuitt

@ Caleb: Mendapat hard jika mereka hanya menolak mentah-mentah.
cepat,

Dengan "kode orang lain" yang saya maksud bukan kepemilikan, maksud saya sesuatu yang mereka tulis dan percaya mereka masih bertanggung jawab untuk mendukung. Dengan tidak adanya standar pengkodean, jika saya menerapkan kelas dengan 1.000 baris kode dan Anda membuat perubahan pada 2 baris untuk memperbaiki beberapa perilaku dan memformat ulang seluruh file, saya akan sangat terkejut ketika saya membuka file. Sebagai anggota tim kita tidak boleh melakukan itu satu sama lain. Jika Anda memeriksa file itu dengan memformat ulang penuh dan bahkan tidak memberi saya kepala, itu tidak terlalu ramah tim.
cdkMoose

Dalam diskusi awal OPs, saya membaca bahwa menjadi sebuah lingkungan tanpa standar pengkodean (atau tidak ditegakkan dengan baik), itulah sebabnya saya menjawab demikian. Dalam lingkungan itu, satu pengembang tidak boleh memaksakan standarnya pada orang lain.
cdkMoose
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.