Apa yang harus dilakukan jika rekan kerja mengedit kode Anda hanya untuk mengubah tampilan?

16

Apa yang harus Anda lakukan, jika rekan kerja mengedit kode Anda?

Tanpa tujuan menambahkan fungsionalitas atau memperbaiki bug, hanya untuk mengubah tampilannya ...

— Tamara Wijsman
sumber

9

Saya menganggap Anda memiliki masalah dengan ini. Jika demikian, mengapa? Apakah itu membuat kode lebih buruk ?

— Zaz

3

@ Josh: Ya, sebenarnya itu membuat kode lebih buruk, karena lebih sulit untuk dipelihara oleh beberapa programmer lain daripada orang yang menulisnya.

— Robert Koritnik

4

beri dia lebih banyak pekerjaan untuk dilakukan

— Oscar Cabrero

4

@Robert - Saya pikir Anda merindukan titik @ Josh. Mengubah tampilan kode mungkin membuatnya lebih mudah dipertahankan ... terutama jika formatnya buruk.

— Stephen C

4

Apakah itu benar - benar kode Anda , atau apakah itu milik tim?

— Eric King

28

Bicaralah dengan mereka tentang hal itu. Pergilah ke percakapan dengan sikap "Mereka tidak melakukan ini untuk mengganggu saya atau karena mereka memiliki semacam gangguan obsesif-kompulsif; mereka berusaha membuat kode saya lebih baik."

Karena kamu bisa saja salah. Itu bisa menjadi perbaikan bug halus dan Anda tidak menemukannya.

Atau, bisa jadi ada standar pengkodean yang Anda tidak tahu tentang yang Anda langgar, dan mereka hanya memperbaikinya.

Atau, bisa jadi mereka mencoba mengganggu Anda, atau mereka memiliki semacam gangguan obsesif-kompulsif. Jika itu masalahnya, mintalah mereka dengan baik untuk berhenti, dan jika itu tidak berhasil, bawalah bersama bos Anda.

Tetapi Anda tidak akan pernah tahu kecuali jika Anda bertanya.

— BlairHippo
sumber

17

Perlu dicatat bahwa banyak IDE memiliki fitur pemformatan otomatis. Saya menggunakannya sepanjang waktu tanpa memikirkannya. Beberapa bahkan akan memformat semua file dalam proyek Anda atau semua file yang Anda buka, tergantung pada bagaimana hal itu dikonfigurasi. Dapat dengan mudah memformat otomatis.

— Matt Olenik

@ Mat: Poin luar biasa.

— BlairHippo

1

"Mereka tidak melakukan ini ... karena mereka memiliki semacam gangguan obsesif-kompulsif;" Berbicara tentang diri saya sendiri, itu tidak selalu terjadi! Ketika datang ke kode saya dua hal: perfeksionis dan aneh yang rapi. Meskipun begitu, saya biasanya berusaha untuk tidak menerapkan mentalitas ini pada pekerjaan rekan-rekan saya.

— Nathan Taylor

5

Oh, aku tidak mengatakan kolega Tom TIDAK OCD-rapi aneh dengan rasa batas yang buruk. Saya hanya mengatakan bahwa melakukan percakapan dengan pola pikir "Apa yang SALAH dengan Anda ?!" bukan cara yang baik untuk melakukan percakapan yang produktif. :-)

— BlairHippo

1

@ Chris tidak perlu khawatir tentang pembenaran, saya selalu Ctrl + K + D!

— Nathan Taylor

16

Saya tidak begitu menikah dengan bagaimana kode saya terlihat mengganggu saya. :) Saya mencoba belajar dari perubahan. Apakah rekan kerja saya menyesuaikan nama variabel? Tulis loop yang lebih efisien? Membuat kode lebih mudah dibaca?

Jika saya tidak dapat melihat bagaimana perubahan meningkatkan apa yang sudah ada di sana, saya biasanya bertanya kepada rekan kerja yang membuat perubahan apa motivasi di balik mereka. Mungkin saja keuntungannya tidak jelas bagi saya. Dan jika saya benar dan mereka salah, maka mungkin saya bisa menjelaskan mengapa saya menulisnya seperti yang saya lakukan.

Jika semuanya gagal, kembalikan check-in. ;)

Sunting: Semua taruhan dibatalkan jika keinginan untuk melakukan perubahan kosmetik memperkenalkan bug.

— Adam Lear
sumber

9

Bagaimanapun, Anda dan tim Anda harus menggunakan standar pengkodean. Jika demikian, maka pertanyaannya adalah 'apakah kode asli Anda sesuai dengan standar?' Jika 'ya' maka kolega Anda tidak boleh menyentuh kode Anda kecuali mengubahnya secara fungsional. Jika 'tidak' maka saya khawatir kolega Anda memiliki hak untuk merapikan kode Anda. Sebagai pemimpin proyek saya mendapati diri saya melakukannya sepanjang waktu.

Jika Anda tidak menggunakan standar pengkodean maka seluruh argumen dari apa yang merupakan 'kode yang baik' menjadi terlalu subyektif. Karenanya mengapa Anda harus menggunakan standar pengkodean :)

8

Sebagai salah satu dari orang - orang itu (orang-orang yang sesekali memformat ulang kode orang lain), alasan utama saya melakukannya adalah keterbacaan. Beberapa orang hanya sangat ceroboh dengan lekukan mereka atau dengan tab dan spasi pencampuran.

Hal utama yang saya punya kebiasaan untuk mengubah adalah mengurangi garis panjang sehingga saya bisa membaca semuanya tanpa menggulir secara horizontal. Saya akan memecah pernyataan kompleks menjadi pernyataan terpisah atau memformat ulang pemanggilan / pernyataan metode untuk membuat daftar satu parameter per baris jika tidak semua cocok dengan nyaman pada satu baris. Saya juga akan mengedit komentar, baik untuk memperbaiki kesalahan bahasa Inggris atau hanya untuk membuat semuanya lebih jelas.

Ya, saya bisa membiarkannya sendiri, tetapi saya lebih suka mengurangi upaya mental yang diperlukan untuk membaca kode.

Apa yang harus Anda lakukan? Pertama, pertimbangkan bahwa mungkin orang ini membuat kode Anda lebih baik. Juga, Anda harus memastikan bahwa Anda memiliki beberapa konsensus di tim Anda tentang bagaimana kode harus diformat. Jika setiap orang memiliki kebiasaan yang berbeda, itu akan memperlambat semua orang. Jika mereka tidak membuat kode Anda lebih baik dan mereka menentangnya, maka Anda perlu menghadapi mereka tentang hal itu. Jika itu tidak berhasil maka Anda mungkin perlu melibatkan orang lain.

— Dan Dyer
sumber

Itulah keterbacaan Anda, saya menemukan kode SQL tidak terindentasi menjadi lebih mudah dibaca karena saya membaca cepat dan kode indentasi memperlambat saya dan membuat saya lebih sulit untuk fokus.

— HLGEM

6

Tanyakan kepada mereka mengapa mereka melakukannya; penjelasan yang valid dapat mengurangi frustrasi Anda, tetapi Anda harus memberi tahu mereka betapa hal itu mengganggu Anda. Siapa tahu, mungkin mereka mengira mereka melakukan sesuatu untuk Anda dan akan berhenti ketika mereka tahu itu menyinggung Anda. Atau Anda mungkin berurusan dengan seseorang yang benar-benar menderita kondisi medis.

— JeffO
sumber

"Atau mereka menderita OCD dan mungkin perlu obat." - sebaiknya tidak menyebutkan bagian itu jika Anda ingin tetap ramah

— Zaz

Saya akan membuat amandemen.

— JeffO

5

Apakah dia diizinkan? Apakah perubahan meningkatkan kode? Jika demikian, telan harga diri Anda. Jika Anda merasa kualitas kode diperburuk, bawalah bersama rekan kerja dan tanyakan kepada mereka mengapa mereka merasa perlu mengubah kode Anda tanpa manfaat yang jelas. Jika itu dilakukan karena dendam atau karena orang itu secara keliru merasa mereka lebih baik daripada Anda, dan Anda tidak bisa menyelesaikannya dengan mereka, bawalah itu dengan bos Anda.

— Chinmay Kanchi
sumber

5

IDE Studio seperti Visual memiliki opsi yang disebut Format Documentyang akan memformat kode sesuai dengan aturan yang telah ditetapkan pengguna dalam IDE. Bisa jadi rekan kerja Anda menggunakan ini (baik secara otomatis tanpa mengetahui, atau dengan aplikasi yang disengaja). Mungkin IDE mereka menggunakan spasi alih-alih tab, atau sebaliknya, dan ini diterapkan secara otomatis tanpa sepengetahuan? Tetapi Anda perlu berbicara dengan mereka untuk mengetahuinya.

Kebetulan, saya akan sering memformat ulang kode rekan kerja jika jelas tidak mengikuti semacam skema format (yaitu semuanya ada di mana-mana). Semoga cara halus membuat mereka memperhatikan. (Namun, saya tidak akan memformat ulang jika rapi, tetapi tidak sesuai dengan keinginan saya).

— Dan Diplo
sumber

1

"(Namun, saya tidak akan memformat ulang jika itu rapi, tetapi tidak sesuai dengan keinginan saya)" - aturan yang sangat penting untuk diikuti, +1

— Zaz

Pedoman pengembangan kami cenderung menempatkan gaya kode lebih di sudut 'direkomendasikan'. Saya memformat kode secara otomatis ke rekomendasi di tingkat file jika saya merasa sulit untuk membaca.

— Joeri Sebrechts

3

Jika dia mengubahnya sehingga memenuhi standar pengkodean tim Anda, Anda harus mengikuti standar di waktu berikutnya.

Jika dia mengubahnya sedemikian rupa sehingga tidak lagi mengikuti standar pengkodean tim Anda, beri tahu dia apa yang dia lakukan salah dan minta dia mengubahnya kembali.

... Tim Anda memang memiliki seperangkat standar pemformatan kode yang digunakan oleh semua orang, bukan?

— Daenyth
sumber

2

Saya sesekali menyusun ulang kode yang ditulis oleh rekan kerja yang berantakan (atau memperbaiki kesalahan ketik dalam komentar). Mereka tahu bahwa saya terobsesi dalam memformat dan memesan kode dan karena itu mereka membiarkan saya melakukan itu tanpa mengeluh terlalu banyak. Terkadang mereka juga memberi saya soda atau kue gratis.

Tentu saja ini adalah pekerjaan sesekali , karena melanggar fungsi "menyalahkan" di SVN.

Ini juga merupakan cara yang sangat mendasar untuk melakukan semacam review kode (saya biasanya membaca sebagian besar kode yang dilakukan oleh rekan kerja saya di modul yang saya kerjakan).

— Wizard79
sumber

2

Konvensi kode adalah yang jawabannya. Anda harus punya satu di tempat kerja. Jika tidak, mulailah sekarang (titik awal yang baik adalah panduan gaya google ). Ketika ada aturan tertulis (atau paling tidak diketahui secara umum), jawaban untuk pertanyaan Anda sepele.

— Ilia K.
sumber

1

Saya merasa Anda berpikir itu ofensif untuk melakukannya ...? Sebagai contoh, saya sendiri akan segera memperbaiki kode ini

int myFunction( ) {

    int i ;
  return  0;

}

untuk menjadi

int myFunction() {
    int i;
    return 0;
}

jadi ... haruskah saya dihukum karena tindakan saya? Dalam kehidupan nyata, saya sebenarnya memiliki banyak log SVN yang membaca 'Format'. ;-)

— tia
sumber

0

Gunakan alat pengecekan gaya

Mulai menggunakan StyleCop atau yang serupa dan menegakkan aturan gaya kode dan juga menjadikannya kewajiban bagi semua pengembang untuk menggunakannya. Semua kode akan terlihat sama tanpa kecuali. Dan bertemu dengan orang bijak untuk membahas aturan paling tepat untuk organisasi Anda. Meskipun aturan default sudah sangat mirip dengan kode kerangka kerja bersih itu sendiri.

Ini cara termudah untuk melakukannya. Saya menemukan diri saya memperbaiki kode orang lain di salah satu majikan saya sebelumnya karena orang ini sedang menulis kode dengan jumlah baris kosong yang berlebihan dan tidak ada aturan lekukan sama sekali. Kode sebenarnya tidak dapat dibaca oleh pengembang rata-rata. Jika StyleCop akan ada kembali maka itu akan membuat banyak dari kita benar-benar bahagia.

— Robert Koritnik
sumber

Saya harus memilih ini. StyleCop adalah implementasi mengerikan dari ide yang layak. 1) Ini berjalan setelah membangun yang membuatnya menjadi pembunuh waktu utama pada proyek-proyek besar 2) Ini aturan standar sebenarnya bertentangan dengan standar VS dalam beberapa kasus 3) Beberapa aturan murni murni tidak waras. Ia mengeluh tentang "//" tanpa spasi tambahan dan kemudian memberitahu Anda untuk menggunakan "////" Sekali lagi, setelah membangun. Itu bagian terburuk. Itu tidak akan buruk, tetapi bagian setelah pembangunan benar-benar membunuh Anda pada proyek besar dengan waktu pembangunan yang lama.

— MIA

Saya akan tidak setuju dengan Anda tentang banyak aspek yang telah Anda tunjukkan. Anda dapat mengonfigurasi cara pemeriksaan gaya berfungsi. Saya bahkan telah mengimplementasikan beberapa aturan saya sendiri yang menyediakan format yang saya inginkan. Mengenai kecepatan saya tidak bisa mengatakan itu hebat. tetapi pada mesin yang layak harus bekerja dengan baik. Bayangkan saja kecepatan C ++ copiler di awal tahun 90-an di mana Anda sebenarnya bisa pergi dan menyiapkan secangkir teh untuk sementara. Sementara bangunan Anda gagal !!!!!! ;)

— Robert Koritnik

Saya baru saja mulai menggunakan StyleCop untuk melihat bagaimana kelanjutannya dan sementara itu sedikit mengganggu kadang-kadang juga membantu menemukan banyak kesalahan yang kalau tidak akan diketahui. Anda tidak harus menjalankannya sebagai bagian dari build dan hanya dapat menjalankannya di mesin lokal Anda, juga hanya untuk file tunggal. Jadi Anda bisa menggunakannya tanpa mengganggu sesama pengembang. Plus, jika Anda tidak menyukai aturan, Anda bisa menonaktifkannya, jadi tidak ada kerugian yang terjadi.

— Anne Schuessler

+1 Ini tidak secara eksplisit tentang StyleCop .. (StyleCop atau yang serupa ). Dan itu ide yang sangat bagus. Tetapkan seperangkat aturan, konfigurasikan alat pilihan Anda, dan selesaikan selamanya.

— Bruno Schäpper

Saat ini kami memiliki Grunt, Gulp dll yang dapat melakukan langkah ini seperti StyleCop yang melakukannya di masa lalu.

— Robert Koritnik

0

ini adalah pemikiran yang saya lihat di internet berbicara tentang refactoring dan mungkin menjelaskan mengapa seseorang menyentuh kode Anda untuk membuatnya lebih baik:

Mengapa?

Ada dua alasan utama untuk refactor:

Untuk meningkatkan kode / desain sebelum membangun di atasnya: Sangat sulit untuk membuat kode yang bagus pada upaya pertama. Percobaan pertama untuk mengimplementasikan desain awal apa pun akan menunjukkan kepada kita bahwa kita salah menafsirkan atau melupakan beberapa logika.
Untuk beradaptasi dengan perubahan persyaratan. Perubahan terjadi dalam pengembangan perangkat lunak; untuk responsif terhadap perubahan lebih baik memiliki basis kode yang baik. Kami memiliki dua opsi untuk kedua skenario, jalur kode atau refactor itu. Menambal kode akan membawa kita ke kode yang tidak dapat dipelihara, dan akan meningkatkan hutang teknis kita, selalu lebih baik untuk melakukan refactor.

Kapan?

Semakin cepat semakin baik semakin mudah.
lebih cepat dan lebih tidak berisiko untuk melakukan refactor terhadap kode yang baru saja di-refactored daripada menunggu refactor agar kode tersebut hampir selesai.

Apa?

Semua kode dan semua desain adalah kandidat untuk refactoring.
Pengecualian untuk tidak refactoring sesuatu bisa menjadi potongan kode kerja yang kualitasnya rendah, tetapi karena mendekati tenggat waktu, kami lebih memilih untuk menjaga hutang teknis kami daripada mempertaruhkan rencana.

Anda hanya harus membiarkan dia melakukan yang terbaik, jika itu akan bagus untuk keduanya dan menghemat waktu Anda di masa depan!

Bersulang

— Junior M
sumber