Apakah menerapkan format kode yang sama untuk semua pengembang adalah ide yang bagus?


88

Kami sedang mempertimbangkan untuk memaksakan format kode standar tunggal dalam proyek kami (format otomatis dengan tindakan simpan di Eclipse). Alasannya adalah bahwa saat ini ada perbedaan besar dalam format kode yang digunakan oleh beberapa (> 10) pengembang yang membuat lebih sulit bagi satu pengembang untuk bekerja pada kode pengembang lain. File Java yang sama terkadang menggunakan 3 format berbeda.

Jadi saya percaya keuntungannya jelas (keterbacaan => produktivitas) tetapi apakah itu ide yang baik untuk memaksakan ini? Dan jika tidak, mengapa?

PEMBARUAN
Kita semua menggunakan Eclipse dan semua orang mengetahui rencananya. Sudah ada format kode yang digunakan oleh sebagian besar tetapi tidak ditegakkan karena beberapa lebih suka tetap pada format kode mereka sendiri. Karena alasan di atas beberapa orang lebih suka untuk menegakkannya.


2
apakah semua pengembang Anda menggunakan Eclipse? Apakah Anda berbicara dengan mereka tentang rencana ini? Tanpa mengetahui hal ini, pertanyaan Anda sulit dijawab, orang harus menebak terlalu banyak
nyamuk

9
Apakah itu benar - benar membuat lebih sulit bagi satu pengembang untuk bekerja pada kode yang lain, atau apakah pengembang hanya alergi terhadap membaca kode yang sedikit berbeda?
Joris Timmermans

27
Saat Anda menggunakan Sistem Kontrol Kode Sumber (seperti svn), pastikan bahwa perubahan pemformatan kode dilakukan secara terpisah dari perubahan semantik - jika tidak, akan sulit untuk menemukan perubahan semantik tersebut.
Martin Schröder

4
Saya tidak setuju dengan Martin di sini, semacam itu. Aturan praktis saya adalah jika Anda membuat perubahan logis / semantik, maka Anda diizinkan untuk mengubah format garis yang Anda ubah, jika tidak, Anda tidak boleh mengubah format garis hanya karena Anda suka. Jangan menyumbat log kontrol versi Anda dengan perubahan format ulang kecil.
Benedict

3
Di sisi lain: jika semua orang menggunakan format yang sama, hanya komitmen pertama untuk memformat ulang semuanya akan tersumbat dengannya. Yang lainnya hanya akan menyentuh perubahan lokal yang dibuat, yang menurut saya dapat diterima.
Jeroen Vannevel

Jawaban:


107

Saat ini saya bekerja di tempat di mana format kode standar diberlakukan dan kode secara otomatis diformat saat menyimpan file, sama seperti yang akan Anda lakukan. Sebagai anggota baru perusahaan saya menemukan bahwa aturan format umum memberi saya perasaan hangat dan kabur bahwa "orang-orang ini tahu apa yang mereka lakukan", jadi saya tidak bisa lebih bahagia. ;) Sebagai catatan samping yang terkait, dengan aturan pemformatan umum kami juga menerapkan pengaturan peringatan compiler tertentu yang agak ketat di Eclipse, dengan sebagian besar diatur ke Kesalahan, banyak yang diatur ke Peringatan, dan hampir tidak ada yang diatur ke Abaikan.

Saya akan mengatakan ada dua alasan utama untuk menegakkan format kode tunggal dalam suatu proyek. Pertama-tama berkaitan dengan kontrol versi: dengan semua orang yang memformat kode secara identik, semua perubahan dalam file dijamin bermakna. Tidak hanya menambahkan atau menghapus spasi di sini atau di sana, apalagi memformat ulang seluruh file sebagai "efek samping" dari benar-benar mengubah hanya satu atau dua baris.

Alasan kedua adalah bahwa itu semacam menghilangkan ego programmer dari persamaan. Dengan setiap orang memformat kode mereka dengan cara yang sama, Anda tidak dapat lagi dengan mudah mengatakan siapa yang telah menulis apa. Kode menjadi lebih anonim dan milik umum, jadi tidak ada yang perlu merasa tidak nyaman untuk mengubah kode "orang lain".

Itulah alasan utama, ada alasan lain juga. Saya merasa nyaman bahwa saya tidak perlu repot memikirkan memikirkan pemformatan kode, karena Eclipse akan melakukannya untuk saya secara otomatis ketika saya menyimpan. Ini bebas perawatan, seperti menulis dokumen dengan LaTeX: diformat setelahnya dan Anda tidak perlu khawatir tentang hal itu saat menulis. Saya juga pernah bekerja di proyek-proyek di mana setiap orang memiliki gaya mereka sendiri. Maka Anda harus memikirkan masalah-masalah bodoh dan tidak berarti seperti apakah boleh mengubah kode orang lain dengan gaya Anda sendiri, atau jika Anda harus mencoba meniru gaya mereka.

Satu-satunya argumen terhadap pengaturan pemformatan kode umum yang dapat saya pikirkan untuk kasus Anda adalah bahwa itu tampaknya merupakan proyek yang sedang berlangsung, sehingga akan menyebabkan banyak perubahan yang tidak perlu di semua file, mengacaukan sejarah file yang sebenarnya. Skenario kasus terbaik adalah jika Anda dapat mulai menerapkan pengaturan langsung dari awal proyek.


20
+100 untuk mengeluarkan ego (dan kepemilikan) programmer dari persamaan. Peletakan "klaim" programmer ke bagian-bagian kode tidak berkontribusi pada produktivitas karena menghambat berbagi pengetahuan dan berarti ada sinyal yang diberikan bahwa tidak semua programmer dapat bekerja pada bagian kode yang sama.
Marco

Sulit untuk memutuskan jawaban mana yang harus diterima, tetapi saya menemukan ini sebagai argumen terbaik dan juga menjawab pertanyaan yang sebenarnya.
Stijn Geukens

"Berarti ada sinyal yang diberikan bahwa tidak semua programmer dapat bekerja pada kode yang sama": Ya, tapi ini sebenarnya adalah sesuatu yang mungkin ingin Anda miliki: selama Anda tidak cukup akrab dengan sepotong kode, Anda harus tidak bekerja / memodifikasinya. Terlalu banyak kepemilikan kode bersama dapat menyebabkan semua orang bekerja di seluruh basis kode dan tidak ada yang benar-benar menguasai bagiannya.
Giorgio

Saya akan memiliki lebih banyak waktu untuk hal semacam ini jika kode secara otomatis diformat sesuai gaya saya saat memuat. Ketika Roslyn mendarat untuk C #, saya berharap untuk melihat semua memuat, menyimpan, versi dan sebagainya bekerja di AST, bukan teks.
Mark Rendle

Peringatan dan kesalahan yang lebih ketat adalah hal yang baik.
Christophe Roussy

37

Setiap pengembang perangkat lunak profesional akan lebih memilih untuk mengadopsi standar (baik) daripada masuk ke perang evangelis atas gaya, karena alasan yang telah Anda uraikan.

Banyak pengembang perangkat lunak melakukan perang evangelis ......

Bergantung pada posisi Anda dalam tim dan dinamika tim, Anda dapat memutuskan bahwa memenangkan perang tidak dimungkinkan. Dalam hal ini, mungkin sebaiknya tidak memulai ...


Tx, saya tahu persis apa yang Anda maksud
Stijn Geukens

15
Tidak profesional untuk berperang tentang pemformatan kode. Pengembang perangkat lunak profesional akan menyelesaikan pekerjaan dengan baik tidak masalah apakah kodenya berbunyi " if( foo )" atau " if (foo)". Jika Anda benar-benar perlu menjual perubahan semacam ini kepada seseorang, Anda harus menarik fakta bahwa mereka adalah profesional. Mereka tidak dapat berbicara kembali atau mereka akan terlihat anal-retensive Jika ada yang melakukannya, saya harap demi Anda, mereka akan segera menemukan pekerjaan baru.
ZeroOne

7
Pengembang profesional juga akan menulis kode yang dapat dibaca, dan dapat membaca kode pengembang profesional lainnya dengan mudah, menghindari kebutuhan akan standar yang luas. Saya akan khawatir bahwa di sini "standar" adalah perbaikan buruk untuk masalah yang salah (Anda tidak memperbaiki devs ceroboh dengan standar pengkodean).
Joris Timmermans

2
Cara terbaik untuk mencoba dan menghindari sebagian besar perang suci ini adalah dengan menerima default bahasa di mana mungkin. Ya itu berarti gaya pengkodean Anda akan bervariasi di berbagai bahasa (misalnya kode C # akan memiliki {pada baris terpisah java akan memilikinya pada baris sebelumnya, dan apa yang PascalCased atau camelCased akan bervariasi); tetapi setiap sumber bahasa individual akan terlihat 'normal' ketika Anda membawa pengembang baru ke proyek.
Dan Neely

1
@ruakh Lihatlah contoh kode MSDN C #, lihat bagaimana Visual Studio memformat ulang C # secara default: {ada pada baris itu sendiri. Ulangi latihan untuk Java dalam dokumentasi Oracle dan default Eclipse ketika memformat ulang kode: {ada pada baris di atas.
Dan Neely

30

Ya, itu bagus untuk memiliki satu gaya format kode untuk semua pengembang.

Rancang format gaya kode dan impor itu ke semua pengembang gerhana.

Ini akan membantu ketika kita membuat mergingkode untuk sistem 'Versi control'.


5
+1 untuk menyebutkan alat penggabungan dan berbeda. Sungguh menyusahkan untuk mencoba menemukan perbedaan antara dua versi basis kode ketika pemformatan tidak konsisten antar pengembang.
pgras

1
+1, saya sangat mendukung argumen sistem kontrol versi. (Tapi itu sebagian besar karena aturan lekukan. Hal-hal seperti konvensi penamaan tidak memiliki banyak dampak)
BiAiB

Konvensi penamaan membantu ketika Anda perlu mencari tahu apa metode yang Anda tahu ada di kelas disebut.
Dan Neely

1
@Iorgio Memang ada pengembang yang melakukan itu. Saat bercampur dengan perubahan lain juga (misalnya, perbaikan bug kritis). Beberapa hal dikirimkan untuk mencoba kami ...
Donal Fellows

1
@Donal Fellows: Anda benar. Saya mengikuti prinsip bahwa setiap karakter yang Anda ketikkan dalam file sumber adalah (1) kesalahan potensial (2) memperkenalkan perubahan yang membuat kode sulit dikenali setelahnya. Jadi menurut saya setiap perubahan harus sekecil mungkin. Tapi, ya, ada pengembang yang mengubah kode tanpa berpikir terlalu banyak. Saya ingin tahu apakah pemformatan ulang otomatis kode dapat memecahkan masalah. Saya lebih suka mendukung kepemilikan kode (lihat misalnya poin 7 di paulgraham.com/head.html ).
Giorgio

16

Apa yang ingin Anda peroleh, seberapa besar Anda akan menerapkan anal dalam menegakkannya (dan pada tingkat detail "aturan" Anda akan ditetapkan), apakah Anda akan mencoba untuk menegakkannya pada kode yang ditulis dalam berbagai bahasa, Anda akan mencoba memberlakukannya secara surut pada kode yang ada?

  1. tampilan dan nuansa yang umum terhadap kode memang dapat membantu membuat kode lebih mudah dibaca, tetapi juga dapat memperburuk keadaan jika itu adalah tampilan dan nuansa yang salah. Notasi _hUngarian_lpfstr menjadi contoh utama :)
  2. Saya telah melihat "standar kode" menegakkan jumlah ruang spasi putih di antara di blok komentar, urutan abjad nama metode, dan omong kosong lainnya. Jangan lakukan itu.
  3. Bahasa yang berbeda memiliki standar yang berbeda yang digunakan orang yang berpengalaman dalam menggunakannya. Beberapa bahkan mengamanatkan standar ini (berpikir Python, Cobol, Visual Studio secara otomatis memaksakan konvensi penahan gaya C ++ sementara Java menggunakan gaya C oleh konvensi, dll.).
  4. jangan pernah mengubah kode yang ada demi mengubahnya, Anda hanya memperkenalkan masalah baru seperti itu. Dan itu berarti bagian kode serta seluruh file sumber. Jadi jangan pergi memformat ulang kode yang ada ketika seseorang mengubah satu baris dalam file 1000 baris.
  5. programmer berpengalaman bisa jauh lebih produktif jika mereka tidak perlu berpikir setengah waktu apakah apa yang mereka tulis akan "terlihat benar" untuk sistem persetujuan otomatis, atau pengulas. Mereka juga akan terbiasa menulis kode bersih hanya karena itulah yang berhasil, bahkan jika ada perbedaan kecil antara gaya alami mereka.



Jadi, meskipun ada alasan bagus untuk memaksakan gaya dan standar tertentu, ada alasan bagus untuk tidak melakukannya (terlalu) secara ketat.


1
1-2-3: Ini Java dan format kode adalah dari Sun; itu hanya memformat jadi tidak memesan metode atau nama variabel; 4-5: Ya, idenya adalah untuk secara otomatis memformat pada save (Eclipse save actions) sehingga tidak ada pekerjaan tambahan (Anda bahkan tidak perlu memikirkan format saat coding) tetapi tentu saja juga file yang ada akan diformat ulang (the pertama kali).
Stijn Geukens

1
+1 untuk KISS. @Stijn Mengapa memformat ulang kode lama? Tekan saja ketika Anda perlu memodifikasinya.
Erik Reppen

3
Sebenarnya, kami sedang merencanakan beberapa refactoring besar dan akan memformat ulang semua kode pada saat itu karena penggabungan akan menjadi hampir tidak mungkin karena refactoring. Jika kita hanya memformat ulang pada perubahan maka kita masih akan menghadapi masalah penggabungan karena perubahan format setahun dari sekarang.
Stijn Geukens

4
Saya biasanya setuju dengan @StijnGeukens; bukan hanya karena alasan penggabungan, tetapi karena pembersihan pemformatan skala besar akan membuat mengikuti riwayat perubahan dalam alat menyalahkan yang menyulitkan. Jika semua perubahan kebisingan Anda berada di satu lokasi, Anda hanya dapat selalu menyalahkan untuk memulai sebelum titik itu awalnya dan kemudian melakukan putaran kedua berhenti sebelum itu jika Anda perlu melihat sejarah yang lebih tua.
Dan Neely

2
Anda lupa alasan lain Dan: perubahan pemformatan skala besar dapat dengan mudah memperkenalkan bug baru di tempat yang tak terduga.
jwenting

11

Ya, konsistensi adalah ide yang baik, untuk alasan lain telah disebutkan .

Saya hanya ingin menambahkan beberapa poin yang belum pernah digunakan di tempat lain:

  • Oracle telah menerbitkan serangkaian konvensi untuk Java, yang merupakan standar de facto.
    • Menggunakan ini akan membantu Anda menghindari argumen tentang gaya mana yang harus diikuti.
    • Banyak perpustakaan umum dan proyek sumber terbuka cenderung menggunakan konvensi ini, jadi ketika Anda perlu melihatnya, formatnya harus familier.
    • Formatter Eclipse memiliki aturan bawaan untuk mencocokkan konvensi ini, yang juga dapat membantu.
  • Anda mungkin ingin mempertimbangkan untuk membangun kait ke pengaturan kontrol sumber Anda sehingga kode diformat secara otomatis sebelum masuk ke cabang utama.
    • Anda dapat menghindari pertempuran dengan programmer yang keras kepala yang menolak untuk mengikuti standar. Mereka bahkan dapat menggunakan format mereka sendiri saat mereka bekerja, yang akan distandarisasi nanti!
    • Jika Anda akhirnya menggunakan pengaturan pemformatan khusus (mis. Banyak orang mengabaikan konvensi "maks 80 karakter per baris"), Anda hanya perlu melakukan perubahan di satu tempat.

9

Saya berada di tim yang menggunakan plugin Checkstyle . Daripada menggunakan fitur out-of-the-box, kami membentuk sebuah komite kecil pengembang yang tertarik. Kami berdebat tentang apa yang tampaknya hilang, apa yang tampak berlebihan, dan menyelesaikan berbagai hal. Kami semua belajar sesuatu dalam proses itu, dan memperkuat otot-otot pengembang itu.

(Contoh keputusan kami: Lebar 72 karakter terlalu kecil, tetapi 120 lebih baik; lebih baik menggunakan _ALLCAPS untuk final statis; menegakkan keluar tunggal dari suatu fungsi adalah ide yang bagus.)

Ketika kami mendapat ulasan kode, salah satu pertanyaan pertama adalah: "Sudahkah Anda menjalankannya melalui Checkstyle?" Mematuhi standar pengkodean sebagian besar otomatis, dan itu menarik perhatian dari resensi yang pilih-pilih. Sangatlah mudah untuk memiliki Checkstyle menyoroti tanda tangan metode, klik kanan, dan ubah variabel menjadi final. Itu juga bisa memperbaiki lekukan dan kawat gigi sehingga kode semua orang memiliki tampilan dan nuansa yang sama. Kehilangan Javadoc untuk fungsi publik? Checkstyle akan menandai fungsi tersebut.

(Menghapus bau kode lebih penting daripada pemformatan yang konsisten. Ini adalah manfaat alat otomatis.)

Saya akan menempatkan alat otomatis seperti Checkstyle kurang memaksakan format yang sama dan lebih pada mendorong tampilan dan nuansa yang sama. Dan saat Anda menggembalakan kucing, alat otomatis dapat membantu mempertajam keterampilan dan mengurangi bau kode tanpa memar ego yang rapuh.


5
Satu titik keluar? Ada prinsip gaya tertentu yang saya benar-benar tidak setuju dengannya. (Jika beberapa pintu keluar adalah masalah, fungsi / metode terlalu lama di tempat pertama ...)
Donal Fellows

@DonalFellows, Checkstyle memberi kami titik referensi dari mana kami bisa beralih ke preferensi komite. Ada banyak tanda seru dari alam, "Saya tidak mengerti mengapa mereka menerapkan standar ini!" Sementara OP bertanya tentang pemformatan yang konsisten, saya pikir alat otomatis memberi lebih banyak tanpa rasa sakit tambahan.
rajah9

6

Jika Anda akan tetap menggunakan IDE yang sama dan menggabungkan beberapa alat format, itu ide yang bagus karena Anda tidak membutuhkan terlalu banyak usaha. Buat aturan tetap sederhana dengan fokus pada keterbacaan dan bukan retensi anal . Itu harus menjadi tongkat pengukur.

Meskipun bola lumpur yang diformulasikan secara konsisten lebih baik dari pada hanya bola lumpur, waktu Anda akan lebih baik dihabiskan untuk membersihkannya daripada menjadi terlalu pilih-pilih tentang arah kurung. Jangan berubah menjadi manajer berkepala pin yang merasa seperti sedang melakukan pekerjaan mereka dengan menghitung ruang indentasi selama tinjauan kode bersama dengan memastikan bahwa lembar-lembar sampul yang baru ada di Laporan TPS .

Preferensi pribadi hanya itu dan jarang meningkatkan produksi: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Jika ya, lupakan dan lakukan sesuatu.


6

Saya sangat merekomendasikan bahwa manusia menegakkan pemformatan kode, dan bahwa pelanggaran kecil diabaikan atau disentuh. Alasan untuk ini adalah, secara singkat,

  1. Mesin melakukan kesalahan pada waktu yang paling buruk, dan biasanya ketika Anda menggunakan fitur bahasa baru. Bagaimana cara menangani penutupan di Jawa, dll? Jalopy memiliki masalah dengan enum dengan fungsi anggota.
  2. Saya pikir ini adalah beban yang sangat masuk akal untuk memakai programmer untuk menghasilkan kode untuk perusahaan yang terlihat seperti kode perusahaan. Saya merasa sangat membantu untuk menyebutkan bahwa ini adalah bagaimana kode diformat "di sini," bukan bagaimana semua kode harus diformat di mana-mana. Perusahaan mereka sebelumnya mungkin telah memilih jalur yang berbeda, dan itu tidak masalah. Tidak seperti bahasa sehari-hari, ada idiom khusus untuk budaya kode Anda yang ingin Anda sampaikan.
  3. Penegakan sintaksis kode paling baik dilakukan dengan ulasan kode:
    1. Jika pemformatan itu penting, maka itu menarik organisasi Anda untuk melakukan tinjauan kode. Ini sangat bermanfaat.
    2. Jika aturan pemformatan dilanggar, manusia dapat melihatnya dan menilai lebih baik daripada mesin jika tujuannya disampaikan lebih bersih. Ini sangat jarang, tetapi kadang-kadang terjadi.

Mengenai "keterbacaan => produktivitas", struktur kode (seperti kelas dan fungsi tanggung jawab tunggal) akan memberi Anda jauh lebih cepat daripada pemformatan kode. Pemformatan kode bisa membantu, tetapi pikiran yang berbeda menguraikan pernyataan secara berbeda - tidak semua orang akan "lebih produktif." Saya ingin melakukan double-down pada struktur kode di atas pemformatan karena itu adalah sesuatu yang juga akan menarik Anda untuk melakukan tinjauan kode dan membuat tim berpikir tentang bagaimana program bekerja, bukan bagaimana satu loop terlihat.

Saya bukan penggemar berat Domain Driven Design, tetapi ini adalah salah satu model terbaru yang memiliki ide yang SANGAT jelas tentang bagaimana kode harus terstruktur dan konvensi pemformatan kode mengalir secara alami dari program terstruktur Domain Driven Design. Sekali lagi ... Saya tidak suka DDD, tetapi ini adalah contoh yang bagus karena sangat terdefinisi dengan baik.

Saya kira tema dari jawaban ini adalah, Lakukan review kode dan biarkan aliran format dari budaya dan keluar dari proses review.


Tx, bukan sudut pandang yang buruk. Tapi sekali lagi, ini pekerjaan tambahan jika selama setiap tinjauan resensi harus memeriksa formatnya juga.
Stijn Geukens

3
Ini klik ekstra untuk memanggil-milih baris dalam sesuatu seperti Fisheye sebagai, "indentasi tidak konsisten" atau "open-brace on line dengan sendirinya," jadi, ya, ini lebih dari nol upaya. Namun, jika ini memperpanjang ulasan kode lebih dari 1 menit secara harfiah ada masalah besar. Setelah seminggu tim meninjau kode mereka sendiri, mereka semua harus sangat cepat memperhatikan kode "salah" dan menyentuhnya.
Sam

4

Secara umum, dengan asumsi Anda mempekerjakan pengembang yang masuk akal, itu adalah ide yang buruk untuk memaksakan format kode universal. Namun itu adalah ide yang baik untuk mengadopsi pedoman kode .

Saya belum pernah melihat seperangkat aturan pemformatan kode yang mengoptimalkan keterbacaan dalam semua kasus. Demikian juga tidak ada 100% aturan tata bahasa yang berlaku dalam bahasa Inggris: otak kita tidak terhubung dengan kabel seperti itu. Jadi gunakan pedoman, tetapi beri pengembang kebebasan untuk menimpanya sesuai keinginan mereka.

Yang sedang berkata, aturan yang lebih sulit dari "mengikuti konvensi kode yang sudah ada dalam file / proyek" adalah yang bagus.

Namun perlu diingat bahwa pemformatan berkontribusi jauh lebih sedikit terhadap keterbacaan daripada sekadar bagaimana kode diatur secara logis. Saya telah melihat banyak kode spaghetti yang tidak dapat dibaca dengan format sempurna!


2

Saya tidak berpikir ada jawaban sederhana untuk ini. Itu bukan pertanyaan ya atau tidak. Meskipun saya percaya bahwa gaya dan konvensi penamaan penting sampai batas tertentu, juga cukup mudah untuk membuang waktu untuk memikirkannya. Jawaban terbaik adalah dengan memberi contoh.

Pada satu proyek khusus saya, tidak ada konvensi sama sekali. Setiap pengembang melakukan sesuatu dengan caranya sendiri. Karena kurangnya pengalaman tim ini, pergi dari satu kelas ke kelas berikutnya benar-benar menggelegar. Gaya itu kurang dari masalah daripada masalah konvensi penamaan. Satu pengembang akan mereferensikan elemen UI dengan notasi Hungaria yang mengerikan (praktik konyol di zaman IDE modern), satu akan menamai anggota pribadi dengan satu cara, yang lain akan menamai mereka secara berbeda. Anda tidak pernah tahu apa yang Anda lihat.

Sebaliknya, satu tim menggunakan StyleCop (ini adalah proyek .Net) sebagai bagian dari proses pembangunan mereka. Yang lebih buruk, adalah bahwa mereka juga menggunakan sebagian besar aturan default. Jadi Anda akan melakukan sesuatu yang benar-benar normal dalam hal penspasian garis atau penempatan braket keriting, dan build akan muntah karenanya. Begitu banyak waktu yang terbuang hanya dengan menambah spasi dan garis pada barang, dan semua orang, termasuk dudes yang bersikeras menggunakan StyleCop, akhirnya melakukannya hampir setiap komit. Itu buang-buang waktu dan uang.

Jadi yang saya maksudkan di sini adalah menjadi tidak fleksibel bukanlah jawabannya, tetapi berada di Wild West juga tidak. Jawaban sebenarnya adalah menemukan tempat yang paling masuk akal, yang menurut saya adalah tidak memiliki alat otomatis memeriksa barang-barang, tetapi juga tidak membuang konvensi ke angin.


2

Argumen utama saya terhadap gaya pengkodean yang umum adalah bahwa seorang programmer yang berpengalaman digunakan untuk membaca gayanya sendiri. Anda dapat melatih tangan untuk menulis gaya tertentu tetapi hampir tidak mungkin untuk melatih mata untuk memahami gaya yang Anda benci. Seorang programmer menulis beberapa kode sekali dan kemudian membacanya berulang kali selama pengembangan dan debugging. Jika setiap kali dia membaca kode sendiri, dia berjuang untuk memahaminya karena dia dipaksa untuk menulisnya dengan gaya BAD, dia akan sangat tidak bahagia dan kurang produktif. Ini dari pengalaman saya.

Saya tidak terlalu terbiasa dengan Eclipse tetapi format otomatis pada save terdengar seperti ide yang mengerikan. Pengembang harus memiliki kontrol penuh atas kode-nya terlepas dari apakah gaya pengkodean diberlakukan atau tidak. Operasi 'save' tidak boleh mengubah satu karakter tanpa persetujuan eksplisit dari pengguna.

Jika perusahaan Anda menjual kode sumber maka gaya pengkodean lebih penting tetapi jika Anda menjual kode yang dikompilasi maka itu jauh kurang relevan.

Berharap bahwa gaya pengkodean akan membuat pembuat kode asli kurang dapat dibedakan dan mencegah perang ego adalah omong kosong dalam kasus terbaik dan jelas bodoh dalam kasus terburuk. Pemrogram yang hebat akan selalu menghasilkan kode elegan terlepas dari gaya.

Saya juga sangat pro memberikan setiap pengembang kepemilikan unit kode tertentu dan melarang semua orang menyentuh setiap bagian kode secara bebas. Mengembangkan seluruh unit dalam kode dan bertanggung jawab atas hal itu memungkinkan pengembang menumbuhkan kebanggaan pada pekerjaannya dan mencegahnya mengembangkan kode jelek mengetahui bahwa bug akan kembali untuk memburunya.

Akhirnya, siapa pun yang pro gaya pengkodean selalu menganggap bahwa gaya pengkodeannya sendiri akan dipilih dan semua orang akan mengikuti. Bayangkan bahwa gaya pengkodean yang paling tidak Anda sukai dari semua co-developer Anda dipilih sebagai standar. Apakah Anda masih mendukung penerapan gaya pengkodean?


2

Satu format untuk mengatur semuanya ... apakah ini benar-benar optimal?

Ini seperti mengendarai mobil orang lain ...

Tentu Anda dapat masuk dan mengendarai mobil apa pun, tetapi Anda akan lebih aman, lebih nyaman, dan lebih kecil kemungkinannya untuk menabrak jika Anda meluangkan waktu untuk menyesuaikan kursi, setir dan cermin sesuai keinginan ANDA .

Dengan kode, pemformatan memengaruhi kenyamanan Anda dalam membaca dan memahami kode. Jika terlalu jauh dari apa yang Anda terbiasa maka akan membutuhkan lebih banyak upaya mental. Apakah perlu untuk menimbulkan ini pada pengembang?

+1 untuk semua manfaat yang disebutkan sejauh ini, tetapi ...

Penegakan otomatis datang dengan biaya yang perlu dipertimbangkan:

-1 pada kenyataan bahwa pemformat kode tidak memahami estetika pemformatan kode. Berapa kali Anda memiliki pemformat kode menghancurkan blok komentar yang disejajarkan dengan baik dalam bentuk tabel? Berapa kali Anda dengan sengaja menyelaraskan ekspresi kompleks dengan cara tertentu untuk meningkatkan keterbacaan, hanya dengan memformatnya secara otomatis, mengubahnya menjadi sesuatu yang "mengikuti aturan", tetapi jauh lebih mudah dibaca?

Kadang-kadang ada solusi untuk hal-hal ini, tetapi pengembang memiliki hal-hal yang lebih penting untuk dipikirkan daripada bagaimana menjaga formatter otomatis dari mengacaukan kode.

Memiliki aturan pemformatan, tetapi memungkinkan beberapa kebebasan untuk menerapkan akal sehat.


2
Saya sangat setuju! Autoformatt bodoh.
Łukasz Wiktor

1

Pengembang yang baik adalah orang-orang kreatif, memberi mereka beberapa lisensi artistik. "Keep it simple" harus menjadi mantra pemrogram. Saya punya dua aturan:

Aturan 1: Berikan variabel / kursor / objek / prosedur / apa pun NAMA YANG DAPAT DITERIMA. Nama yang tidak ambigu yang membawa arti dan pemahaman pada kode Anda.

Aturan 2: Gunakan lekukan untuk menunjukkan struktur kode Anda.

Itu dia.


1
Bisakah Anda menjelaskan mengapa demikian? Bagaimana cara membiarkan setiap pengembang memiliki lisensi artistik (yang berbeda di antara pengembang pada proyek yang sama) menghasilkan ide yang lebih baik daripada meminta mereka semua memiliki format yang sama? Adakah masalah yang Anda pecahkan bahwa alternatifnya tidak? Dan sebaliknya?

Saya kira poin yang saya coba (dan gagal) untuk membuat adalah bahwa menggunakan nama yang masuk akal dan indentasi kode Anda dengan baik jauh lebih penting berkaitan dengan keterbacaan / pemeliharaan daripada aturan lain yang mungkin ingin Anda ciptakan. Saya tidak mengatakan semua orang di tim harus memiliki gaya mereka sendiri, hanya saja jika mereka melakukannya maka apa.
Jonesi

Pertimbangkan jika saya memiliki pemformat kode di gerhana yang mengatur satu cara dan saya selalu memformat ulang kode saya ... dan Anda memiliki satu pengaturan yang sedikit berbeda ... dan kami terus memodifikasi kode yang sama. Apakah 'lisensi artistik' ini menimbulkan masalah di diff?

Sementara saya mengerti maksud Anda, saya pikir masalah dengan sudut pandang Anda adalah ketika Anda memiliki gaya yang sangat berbeda (perhatikan, tidak salah hanya berbeda). Ini dapat menyebabkan masalah nyata dan keterlambatan saat menggabungkan gaya yang berbeda ini.
Daniel Hollinrake

1
Ya, saya mengerti maksud Anda Daniel. Saya harus menambahkan aturan ketiga: Saat memodifikasi kode yang ada, sesuaikan agar sesuai dengan gaya kode yang Anda edit. Inilah yang secara alami akan saya lakukan jika saya memperbaiki program yang lama.
Jonesi

0

Bagi saya, keuntungan utama dari format umum yang diterapkan secara otomatis adalah membantu pelacakan perubahan & ulasan kode kami. git (dan sebagian besar alat kontrol sumber lainnya) dapat menunjukkan perbedaan dari versi file-file sebelumnya. Dengan menerapkan gaya umum, ini meminimalkan perbedaan preferensi programmer.



-1

Bahasa bukan kode. Kami manusia memiliki lebih dari 6000 bahasa, jadi kami menerjemahkannya. Jadi, jika Anda ingin "kode" Anda berkomunikasi, Anda harus melakukan penyesuaian. Anda lihat kami pengguna harus mengubah format data kami sehingga kami tidak akan kehilangan data kami.


-2

Saya akan mengatakan tidak. Struktur / format kode umum di antara tim jelas merupakan hal yang baik, tetapi secara otomatis menegakkannya bukan. Ini harus dilakukan oleh manusia, bukan oleh komputer.

Masalah terbesar saya dengan konsep tersebut adalah

  1. Jika saya menulis kode dalam satu format dan secara otomatis diformat ulang, insentif apa yang ada untuk benar-benar mempelajari format itu?
  2. Mengikuti poin sebelumnya, jika Anda tidak mempelajari formatnya, seluruh titik autoformatting (untuk membuat kode lebih mudah dibaca dan dimodifikasi) benar-benar hilang. Anda masih harus meluangkan waktu untuk mengetahui format saat Anda membaca kode karena Anda belum mempelajari format itu
  3. Saya pikir itu akan menjadi pengalaman yang menggelikan sebagai dev untuk menulis kelas suatu hari, menutupnya, dan kembali pada hari berikutnya untuk melihat itu benar-benar berbeda. Itu berarti bahwa tidak hanya orang lain yang harus mempelajari kode Anda , Anda harus mempelajari kode Anda.
  4. Itu juga bisa mendorong pengkodean malas. Alih-alih mendorong dev untuk mempelajari format, mereka dapat menulis dalam format apa pun di bawah matahari dan itu akan secara otomatis terlihat seperti yang diinginkan semua orang. Ini kembali ke # 2 di mana Anda tidak mempelajari gaya dan masih tidak dapat membacanya dengan benar.

Sekarang, saya mungkin cenderung mengatakan bahwa menjalankan format-otomatis pada proyek yang sudah selesai akan menjadi ide yang baik. Ini akan memulai setiap dev dengan kaki yang sama untuk proyek ketika Anda pergi untuk memperbaiki / menambah fitur nanti. Namun, selama pengembangan aktif, saya pikir itu adalah pilihan yang sangat buruk.

Pada dasarnya: Taruh tanggung jawab pada karyawan untuk mempelajari gaya perusahaan, jangan memaksakan kode mereka menjadi sesuatu yang bukan.


+1: Poin bagus, meskipun saya tidak yakin mereka lebih penting daripada alasan memformat ulang otomatis. Mengapa downvote (s)?
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.