Gaya Jawa yang bertentangan dalam Tim

12

Saya bagian dari tim pengembang Java dengan tenggat waktu 6 minggu. Ini mengharuskan penulisan banyak kode dengan sangat cepat. Namun tim pengembangan kami memiliki gaya pengkodean yang berbeda. Semuanya, mulai dari konvensi nama hingga metode abstraksi berbeda di antara tim kami. Apakah ada yang tahu ada dokumen yang menentukan "standar" untuk java?

Untuk memperjelas, saya bertanya-tanya apakah ada organisasi yang akan menentukan konvensi penamaan yang tepat untuk variabel dan fungsi misalnya. Ini sangat penting karena dengan tenggat waktu yang singkat kami tidak dapat menghabiskan waktu untuk mencoba memahami kode satu sama lain.

java coding-standards

— Daniel Gratzer
sumber

18

Ada organisasi seperti itu: Sun / Oracle sendiri. Dokumen ini disebut Konvensi Kode untuk Bahasa Pemrograman Java , dan menjelaskan sebagian besar konvensi yang Anda butuhkan. Hanya minta semua orang setuju untuk membacanya dan ikuti rekomendasinya.

— Andres F.
sumber

3

Ini adalah std terkenal, tetapi jangan takut untuk menyimpang dari itu di mana tim setuju. Menjadi terbatas pada 80 karakter lebar bisa menyakitkan misalnya.

— Martijn Verburg

1

@ MartijnVerburg, batas dapat mendorong refactoring ke dalam metode dan kelas untuk menghindari lekukan yang dalam.

Ini adalah konvensi, dan mungkin merupakan fallback yang masuk akal, jika Anda tidak dapat menemukan perjanjian sendiri, tetapi seperti namanya, itu tidak menentukan - itu adalah konvensi.

— pengguna tidak dikenal

@ penggunaunknown Anda benar. Saya bahkan tidak setuju dengan semua konvensi. Tetapi itu adalah kompromi yang baik mengingat jangka waktu OP.

— Andres F.

8

Saya benar-benar menandai jawaban Andres , dan fokus pada aspek seragam memformat kode java.

Jika Anda menggunakan Eclipse, Anda dapat mengatur formatter Java-nya untuk secara otomatis memformat ke standar Java. Formatter Eclipse juga memiliki pengaturan bermanfaat lainnya, seperti karakter per baris (yaitu berapa banyak karakter per baris sebelum dipecah menjadi baris baru), dan banyak lainnya. Standarisasi karakter per baris membuat lebih mudah untuk diff kode yang ditulis oleh pengembang yang berbeda tanpa banyak perbedaan hanya dari jarak dan line break.

Terakhir, dengan Eclipse, setelah Anda mengatur semua pengaturan yang Anda inginkan, kemudian ekspor formatter Anda sebagai file yang dapat diimpor oleh setiap anggota tim. Jadi jika Anda menggunakan Eclipse, saya sangat merekomendasikan sepenuhnya mengeksplorasi semua opsi itu akan memformat otomatis dan mengedit kode untuk Anda, dan kemudian berbagi pengaturan dengan seluruh tim.

Saya akan menganggap IDE java utama lainnya (IntelliJ dan Netbeans) memiliki fitur serupa untuk mengekspor pengaturan format.

— Sam Goldberg
sumber

2

+1 Jawaban yang bagus juga! Anda juga dapat menginstal plugin seperti Checkstyle dan membuatnya memperingatkan Anda ketika Anda melanggar konvensi.

— Andres F.

Kami juga melakukan ini. Preferensi -> Java -> Editor -> Simpan opsi dan aktifkan format di save. Alasan utama adalah untuk memastikan bahwa baris sumber yang dipengaruhi oleh format terjadi sesegera mungkin untuk mendapatkan riwayat kontrol versi sebersih mungkin (beda lagi).

Ya, saya mulai melakukan ini baru-baru ini juga. Satu-satunya hal yang saya tidak yakin, adalah bahwa saya memilih "hapus variabel pribadi yang tidak digunakan" pada opsi simpan. Jadi ketika saya sedang melakukan TDD, saya menemukan itu sering, variabel saya menghilang karena kode disimpan sebelum saya menggunakannya ... tetapi selain itu, opsi ini sangat bagus.

— Sam Goldberg

6

Ini [berbagai gaya pengkodean] sangat penting karena dengan tenggat waktu yang begitu singkat kami tidak dapat menghabiskan waktu untuk mencoba memahami satu sama lain kode.

Sebenarnya. Itu bukan yang terpenting.

Setelah 30 tahun sebagai konsultan, saya telah membaca banyak kode dari banyak pelanggan. Penting untuk dicatat bahwa setiap pelanggan (dan sering dalam organisasi pelanggan) ada gaya yang berbeda-beda.

Setelah membaca begitu banyak gaya, saya belajar ini.

Gaya Tidak Peduli

Harap fokus pada penulisan kode yang selalu berfungsi, dan penulisan unit test yang membuktikan bahwa itu selalu berhasil.

Setelah Anda mengirimkan kode kerja, Anda dapat mendandaniya jika Anda kehabisan bug untuk diperbaiki dan perangkat tambahan untuk dipasang.

— S.Lott
sumber

mungkin tidak masalah, tetapi juga sangat baik untuk dimiliki, dan sangat mudah dilakukan.

— Kevin

1

Gaya tidak penting, tetapi konsistensi penting. Gaya yang tidak konsisten membuat pemeliharaan perangkat lunak jauh lebih sulit.

— Jesper

5

@Jesper: "Gaya yang tidak konsisten membuat pemeliharaan perangkat lunak menjadi" sedikit "lebih sulit". Tidak terlalu sulit dengan peregangan apa pun. Kode buram, buruk, kereta jauh lebih sulit untuk dipelihara. Gaya yang tidak konsisten dalam kode kerja hanyalah gaya yang tidak konsisten. Beberapa orang memiliki aksen, dan Anda harus mendengarkan dengan lebih cermat. Gaya yang tidak konsisten sedikit lebih dari aksen regional (atau nasional) yang berbeda.

— S.Lott

1

Gaya tidak penting dalam arti global, tetapi gaya yang konsisten dalam satu tim tidak masalah. Itu tidak akan membuat atau menghancurkan suatu proyek, tetapi jika itu mudah untuk konsisten seperti tidak, mengapa tidak melanjutkan dan konsisten? Kode Anda setidaknya sedikit lebih baik.

— Bryan Oakley

1

"Kode Anda akan" terbaik "sedikit lebih baik". Dan ya, hampir tanpa biaya dan tentu saja tanpa risiko. Tapi. Cakupan tes 100% jauh, jauh lebih berharga daripada konsistensi.

— S.Lott

2

Jangan khawatir tentang memilih standar universal yang sempurna. Yang Anda butuhkan hanyalah tim Anda menyetujui satu standar dan berpegang teguh pada itu. Rias sendiri jika Anda mau, tetapi tetaplah konsisten.

Konsistensi meningkatkan kolaborasi, kolaborasi meningkatkan kode.

Sekalipun konsistensi yang sebenarnya tidak membantu, fakta bahwa tim Anda bekerja bersama untuk mencapai kesepakatan adalah Hal Baik. Ketidakmampuan mereka untuk menyetujui sesuatu yang sederhana seperti konvensi pengkodean mengatakan mungkin ada masalah kerja tim yang lebih besar bersembunyi di bawah permukaan.

— Bryan Oakley
sumber

0

Sun Java CC yang disebutkan di atas tidak hanya berusia 13 tahun dan beberapa aturannya sudah usang (seperti 80 karakter per baris), tetapi juga tidak mendefinisikan konvensi penamaan, kecuali yang paling umum (selubung unta untuk kelas, blok huruf besar) untuk variabel akhir statis dan sejenisnya).

Anda perlu mendefinisikan standar Anda sendiri untuk berbagai jenis kelas, seperti DAO, EJBs, entitas, apa pun yang Anda gunakan. Sun Java CC seperti kelas dasar abstrak yang dimaksudkan untuk memperluas :)

— MaDa
sumber

Saya setuju bahwa Java CC milik Sun sudah agak tua, tetapi itu hanya dimaksudkan sebagai titik awal. Saya berasumsi OP tidak punya banyak waktu untuk membuang definisi CC sendiri, atau dia akan mengatakan itu! (BTW, tempat saya bekerja saat ini, mereka menggunakan plugin Sonar yang dikonfigurasi untuk menegakkan batas 80 karakter - jadi aturan ini masih hidup dan menendang di beberapa toko).

— Andres F.

Selain alasan lain, keterbacaan adalah faktor. Harus memindai jarak jauh melintasi garis jauh lebih efisien daripada memindai turun. Dengan kode yang diformat dengan baik, Anda dapat dengan cepat memindai kode yang tidak relevan.

— BillThor

Jika Anda mengalami masalah dengan 80 karakter per baris, baik Anda memiliki pengidentifikasi panjang yang luar biasa atau Anda menempatkan banyak pada baris tunggal. Yang pertama konyol (tidak bisakah Anda menyaring intinya menjadi kurang dari itu?) Dan yang kedua merupakan indikasi kebutuhan mendesak untuk refactoring. Pemformatan otomatis saat menyimpan sangat bagus karena Anda tidak perlu lagi khawatir tentang pemformatan sama sekali; perangkat lunak menanganinya untuk Anda.

— Donal Fellows

@DonalFellows Ya, di hari ini dan usia, batas 80 karakter ada untuk mengingatkan Anda untuk refactor, bukan karena layar terminal kecil.

— Andres F.

0

Seperti yang disebutkan oleh orang lain di sini, Anda dapat mencari secara online 1 dari beberapa 'panduan gaya' populer untuk Jawa dan membujuk semua orang di tim untuk menaatinya. Beberapa alat pengecekan kode di IDE favorit Anda mungkin dapat membantu mengingatkan Anda ketika Anda tidak melakukannya.

Namun, terkadang politik terlibat. Saya pernah berada dalam situasi di mana pengembang paling senior dalam tim terus melakukannya dengan caranya sendiri bahkan setelah seseorang menyebutkan perlunya standarisasi. Dalam situasi seperti itu, mungkin lebih baik untuk mengamati gaya kodenya dan mengikutinya karena dia mungkin memiliki pengetahuan paling banyak tentang basis kode dan persyaratan dan Anda mungkin tidak ingin membuang waktu menginjak jari kakinya meskipun ia sedang sulit. Itulah yang kami lakukan dalam situasi khusus itu dan dengan enggan saya ikuti.

Jadi, penting untuk mempertimbangkan situasi Anda juga.

— snowpolar
sumber

Negara apa ini? Kedengarannya seperti hal budaya.

@ ThorbjørnRavnAndersen Dia bermaksud mengatakan bahwa orang bisa tahan terhadap perubahan ketika "apa yang telah mereka lakukan untuk kerja yang begitu lama". Politik dalam pengertian ini hanyalah "politik kantor"

— Robotnik

0

Paman Bob menunjukkan gaya pengkodean yang lebih modern dan terkini dalam bukunya "Clean Code". Sayangnya tidak mengandung daftar item. Anda harus membacanya. Dia mengatakan pada dirinya sendiri bahwa untuk melihat konvensi, Anda harus membaca kode-nya. Paman Bob tidak diragukan lagi semacam institusi. Buku ini adalah bacaan yang sangat bagus, jadi meskipun sudah terlambat untuk membacanya sekarang, bacalah segera.

— Peter Kofler
sumber

0

Yang benar-benar penting dalam kode adalah kompleksitas siklomatik yang rendah, cakupan kecil, kohesi tinggi dan pilihan pengidentifikasi ekspresif. Mengingat itu, kode menjadi mudah dipahami dan kode seperti itu bagus.

Saya sarankan Anda melihat Pemrograman Spartan .

Kebanyakan standar pengkodean memberi tahu Anda cara membuat kode yang ditulis dengan buruk terlihat cantik dan sebagian besar diskusi tentang "gaya pengkodean" sebenarnya tentang pemformatan. Pemformatan kode adalah tentang yang secara visual mewakili struktur kode Anda. Itu sepele dan otomatis dan hampir tidak melakukan apa pun dengan gaya pengkodean, karena gaya pengkodean bukan tentang bagaimana Anda mewakili struktur kode, tetapi tentang bagaimana Anda menyusun kode.
Ada juga banyak perang agama tentang konvensi penamaan, meskipun sebenarnya itu hanya hack untuk mengatasi desain yang buruk. Nama itu baik, jika dikatakan apa artinya. Semakin kecil dan semakin jelas cakupan Anda, semakin mudah untuk memilih nama tersebut.

— back2dos
sumber