satu programmer, banyak bahasa - nama dilema


14

Saat Anda bekerja di beberapa bahasa pemrograman, ada masalah yang Anda temui ...

Nama (pengidentifikasi) yang valid dalam satu bahasa tidak valid di bahasa lain. Sebagai contoh...

var new function thisadalah kata kunci dalam JavaScript, tetapi Anda dapat menggunakannya secara bebas dalam Python. Demikian pula list dict defdapat digunakan dalam JavaScript tanpa masalah.

Ini adalah hal yang sangat umum dan biasanya programmer dengan cepat berkenalan ketika mereka memprogram dalam berbagai bahasa.

Namun, ketika Anda bekerja dalam kolaborasi, Anda harus menetapkan beberapa aturan / pedoman untuk anggota tim Anda untuk memastikan konsistensi dan keseragaman dalam kode. Dengan tim, masalah ini menjadi lebih penting daripada sekadar mengingat apa yang valid dan apa yang tidak saat Anda memprogram.

Jadi, pertanyaan saya adalah, strategi apa yang Anda adopsi ...

  • hanya mengambil gabungan dari semua kata-kata yang disediakan hadir dalam semua bahasa yang Anda gunakan, membagikan daftar untuk semua orang dan abstain penggunaannya?
  • terima keragaman dan bersusah payah saat "switching konteks"
  • mengadopsi landasan perantara di mana satu bahasa dapat menggunakan yang lain, tetapi tidak sebaliknya

(Catatan: saya hanya berbicara tentang Python dan JavaScript dalam pertanyaan ini ... tapi tolong jawab pertanyaan lebih luas)

- PEMBARUAN -

Terima kasih atas semua jawabannya. Jadi konsensus umum yang saya lihat muncul adalah untuk membiarkan programmer menggunakan nama apa pun terlepas dari apa yang mereka lakukan bahasa lain - selama nama deskriptif, tidak ada salahnya.


1
Atau hanya mengharuskan setiap nama variabel mulai dengan a $. Ia bekerja di PHP, JavaScript, dan beberapa kompiler C / C ++ . Dalam semua keseriusan, ini adalah satu hal yang PHP benar IMHO.
Joey Adams

Jawaban:


46

Setelah diprogram dalam beberapa bahasa selama lebih dari 30 tahun pengalaman saya, saya akan mengatakan bahwa mencoba menemukan standar penamaan yang akan bekerja dalam bahasa apa pun mungkin merupakan ide yang bagus.

Di awal pengalaman saya, saya mencoba menggunakan #define macro di C untuk membuat sesuatu yang akan membuat kode C saya terlihat seperti kode Pascal yang saya gunakan sebelumnya. Saya sudah terbiasa pemrograman di Pascal sehingga saya pikir jika saya bisa membuat C berfungsi seperti Pascal, itu akan membuat saya lebih produktif. Saya segera menemukan bahwa saya salah.

Apa yang membuat saya lebih produktif adalah belajar C dan tidak mencoba memanfaatkan sintaksis Pascal ke bahasa lain hanya karena itu membuat saya lebih nyaman.

Saya pikir Anda akan berpotensi membatasi programmer Anda dengan mencegah mereka melakukan sesuatu dalam satu bahasa, hanya karena itu salah melakukannya dalam bahasa lain yang Anda gunakan.

Jika Anda membatasi konvensi penamaan Anda untuk hal-hal yang masuk akal untuk menjelaskan penggunaan variabel, maka Anda mungkin akan membuat kode yang baik, dalam bahasa apa pun.


3
Nama yang masuk akal adalah semua alasan yang Anda butuhkan.
JeffO

24

Anda tidak boleh menyebutkan nama "daftar", "baru", "var", "ini" karena mereka tidak cukup deskriptif dalam bahasa apa pun.


2
Ditto "berfungsi". Jika itu bukan kata kunci, itu tidak dimaksudkan.
MPelletier

11

Beralih dari, katakanlah, javascript ke python sudah merupakan konteks switch. Saya tidak berpikir itu buruk jika nama variabel bergeser, terutama jika perubahan nama adalah idiomatis dengan bahasa. Seseorang bahkan dapat memperdebatkan switch konteks yang lebih keras dapat membantu dalam kasus ini karena ini membantu memperkuat "bung, Anda sedang menulis javascript bukan python sekarang."


7

Saya pikir jika Anda menggunakan penamaan variabel deskriptif, masalah yang Anda jelaskan harus minimal. Dengan demikian, jika minimal, maka menerima perubahan konteks yang disebabkan oleh penamaan variabel antar bahasa juga menjadi minimal.


5

Sebagian besar kata yang dipesan (dalam bahasa apa pun) cukup umum. Saya lebih suka nama variabel / fungsi yang lebih deskriptif dan itu berarti saya hampir tidak pernah menemui masalah ini. Saya harus mengakui telah terinfeksi oleh Charles Simonyi dengan skema penamaan aslinya - ini berada di Xerox pada akhir 70-an, sebelum bahkan disebut Notasi Hongaria - dan itu juga cenderung berarti bahwa nama-nama itu adalah sesuatu yang bukan manusia biasa. akan menggunakan kata-kata yang dicadangkan.


5

Anda tidak boleh membuang waktu untuk menulis panduan sampai Anda menemukan ini adalah masalah yang sebenarnya , bukan hipotesis.

Satu situasi yang bisa saya pikirkan di mana ini bisa menjadi masalah adalah ketika Anda berbagi struktur data antara bahasa pemrograman. Misalnya, jika Anda memiliki objek Javascript di sisi klien yang tercermin dalam objek Python di sisi server, dan Anda tentu ingin mereka memiliki nama yang sama untuk anggota mereka. Dalam hal ini aturannya sederhana: Jangan gunakan nama yang dilindungi kata-kata dalam bahasa apa pun. Itu dia. Tulis itu dalam pedoman jika Anda mau. Sekarang beralihlah ke tugas yang lebih penting.

BTW, baik daftar maupun dikte adalah kata yang dilindungi undang-undang dengan Python. Mereka dapat digunakan sebagai nama variabel, meskipun yang cukup buruk.


3

Dalam pengalaman saya, perbaikan untuk ini adalah memiliki konvensi penamaan luas yang berlaku untuk semua bahasa. Entah itu JavaScript, C #, atau bahasa funky lainnya, cara variabel dan kelas dinamai bisa menjadi standar dalam basis kode yang biasanya saya lihat menyelesaikan masalah ini. Konvensi dapat disetujui oleh konsensus semua orang, hanya mayoritas yang menginginkan pedoman, manajemen mengatakan, "Ini adalah bagaimana kita melakukannya," atau beberapa kemungkinan lain yang saya bayangkan.

Saya jarang melihat masalah pengidentifikasi yang Anda uraikan karena sebagian besar waktu kelas atau nama variabel saya cukup deskriptif sehingga tidak mudah konflik. Pada saat yang sama, jika seseorang bekerja dengan orang lain daripada memiliki kejelasan tentang bagaimana tim ingin menangani ini adalah poin penting.


2

Saya tidak dapat melihat bagaimana ini bisa menjadi masalah, kecuali jika Anda berencana untuk memindahkan kode dari satu bahasa ke bahasa lain. Jika Anda secara pribadi cenderung lupa nama variabel apa yang valid, maka jangan gunakan nama variabel kecuali Anda secara pribadi yakin itu valid. Tetapi jika orang lain menggunakan nama variabel yang tidak valid, kode mereka tidak akan dikompilasi atau dijalankan. Jadi jika Anda bekerja pada kode orang lain, dan mereka menyebut sesuatu 'var', Anda bisa yakin itu adalah nama yang valid pada bahasa apa pun yang mereka gunakan.

Jika Anda mungkin berencana untuk memindahkan kode dari satu bahasa ke bahasa lain, maka Anda mungkin perlu daftar nama yang dilarang. Sebagai contoh, dokumen praktik pengkodean C saya melarang penggunaan baru atau kelas sebagai variabel karena itu membuat kode lebih sulit untuk port ke C ++. Dalam hal ini, masuk akal untuk menetapkan aturan yang memudahkan pekerjaan itu, jika memang perlu,


-2

Tetap berpegang pada CamelCase yang lebih rendah. Ini bekerja di mana-mana. Ini disebut mencari penyebut umum terendah antara sistem yang tidak kompatibel, dan Anda akan sering melakukannya!


5
Kecuali dalam beberapa bahasa kasus huruf pertama adalah sintaksis yang signifikan.
Karl Bielefeldt

1
... dan itu melanggar standar kuasi budaya yang ditetapkan dalam banyak bahasa.
tdammers

Notasi Hongaria jauh lebih membingungkan daripada CamelCase ... ;-)
Zeke Hansell

@ Kararl: sarannya jelas terbatas pada batas bahasa. Tahukah Anda bahwa Java dapat memulai nama variabel dengan tanda dolar? Saya telah melihat kode Java yang terlihat seperti PHP, sudah jelas di mana programmer sebelumnya belajar untuk memprogram!
dotancohen

@dancancohen: Saya ingat melihat program pascal di majalah hobi bertahun-tahun yang lalu, ketika pascal baru saja membuat keributan. Jelas sekali dari struktur kode (dan fakta bahwa mereka menggunakan variabel global untuk meneruskan nilai ke subrutin dan fungsi) bahwa program tersebut adalah salah satu program dasar terbaik yang pernah saya lihat tertulis Pascal. ;-)
Zeke Hansell
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.