Dulu ada alasan yang sangat baik untuk menjaga instruksi / daftar nama pendek. Alasan itu tidak lagi berlaku, tetapi nama samar pendek masih sangat umum dalam pemrograman tingkat rendah.

Kenapa ini? Apakah hanya karena kebiasaan lama sulit dihilangkan, atau adakah alasan yang lebih baik?

Sebagai contoh:

• Atmel ATMEGA32U2 (2010?): TIFR1(Bukan TimerCounter1InterruptFlag), ICR1H(bukan InputCapture1High), DDRB(bukan DataDirectionPortB), dll.
• Set instruksi NET CLR (2002): bge.s(bukan branch-if-greater-or-equal.short), dll.

Bukankah lebih lama, nama non-samar lebih mudah untuk digunakan?

Saat menjawab dan memberikan suara, harap pertimbangkan yang berikut ini. Banyak penjelasan yang mungkin disarankan di sini berlaku sama untuk pemrograman tingkat tinggi, namun konsensus, pada umumnya, adalah menggunakan nama-nama non-rahasia yang terdiri dari satu atau dua kata (akronim yang dipahami secara umum dikecualikan).

Juga, jika argumen utama Anda adalah tentang ruang fisik pada diagram kertas , harap pertimbangkan bahwa ini benar-benar tidak berlaku untuk bahasa assembly atau CIL, plus saya akan sangat menghargai jika Anda menunjukkan kepada saya diagram di mana nama-nama singkat cocok tetapi yang mudah dibaca membuat diagram lebih buruk . Dari pengalaman pribadi di perusahaan semikonduktor yang luar biasa, nama yang dapat dibaca cocok dengan baik, dan menghasilkan diagram yang lebih mudah dibaca.

Apa hal inti yang berbeda tentang pemrograman tingkat rendah sebagai lawan dari bahasa tingkat tinggi yang membuat nama samar samar diinginkan dalam pemrograman tingkat rendah tetapi tidak pemrograman tingkat tinggi?

Alasan perangkat lunak menggunakan nama-nama itu adalah karena lembar data menggunakan nama-nama itu. Karena kode pada tingkat itu sangat sulit untuk dipahami tanpa lembar data, membuat nama variabel yang tidak dapat Anda cari sangat tidak membantu.

Itu memunculkan pertanyaan mengapa lembar data menggunakan nama pendek. Itu mungkin karena Anda sering perlu menyajikan nama-nama dalam tabel seperti ini di mana Anda tidak memiliki ruang untuk pengidentifikasi 25 karakter:

Juga, hal-hal seperti skema, pin diagram, dan PCB silkscreens sering sangat sempit untuk ruang.

Hukum Zipf

Anda sendiri dapat mengamati dengan melihat pada teks ini bahwa panjang kata dan frekuensi penggunaan, secara umum, berhubungan terbalik. Kata-kata yang digunakan sangat sering, seperti it, a, but, you, dan andsangat pendek, sementara kata-kata yang kurang sering digunakan seperti observe, comprehension, dan verbositylebih panjang. Hubungan yang diamati antara frekuensi dan panjang ini disebut Hukum Zipf .

Jumlah instruksi dalam set instruksi untuk mikroprosesor yang diberikan biasanya nomor dalam puluhan atau ratusan. Sebagai contoh, set instruksi Atmel AVR tampaknya berisi sekitar seratus instruksi berbeda (saya tidak menghitung), tetapi banyak dari mereka adalah variasi pada tema umum dan memiliki mnemonik yang sangat mirip. Sebagai contoh, instruksi multiplikasi termasuk MUL, MUL, MULSU, FMUL, FMULS, dan FMULSU. Anda tidak harus melihat daftar instruksi untuk waktu yang lama sebelum Anda mendapatkan ide umum bahwa instruksi yang dimulai dengan "BR" adalah cabang, instruksi yang dimulai dengan "LD" adalah beban, dll. Hal yang sama berlaku untuk variabel: bahkan prosesor yang kompleks hanya menyediakan sejumlah tempat terbatas untuk menyimpan nilai: register kondisi, register tujuan umum, dll.

Karena ada begitu sedikit instruksi, dan karena nama yang panjang membutuhkan waktu lebih lama untuk dibaca, masuk akal untuk memberi mereka nama pendek. Sebaliknya, bahasa tingkat yang lebih tinggi memungkinkan pemrogram untuk membuat sejumlah besar fungsi, metode, kelas, variabel, dan sebagainya. Masing-masing akan digunakan jauh lebih jarang daripada kebanyakan instruksi perakitan, dan lebih lama, nama yang lebih deskriptif semakin penting untuk memberi pembaca (dan penulis) informasi yang cukup untuk memahami apa itu dan apa yang mereka lakukan.

Selain itu, set instruksi untuk prosesor yang berbeda sering menggunakan nama yang mirip untuk operasi yang sama. Sebagian besar set instruksi termasuk operasi untuk ADD, MUL, SUB, LD, ST, BR, NOP, dan jika mereka tidak menggunakan nama-nama persis mereka biasanya menggunakan nama yang sangat dekat. Setelah Anda mempelajari mnemonik untuk satu set instruksi, tidak perlu waktu lama untuk beradaptasi dengan set instruksi untuk perangkat lain. Jadi nama-nama yang mungkin tampak "samar" kepada Anda adalah tentang akrab sebagai kata-kata seperti and, or, dan notuntuk programmer yang terampil dalam seni pemrograman tingkat rendah. Saya pikir sebagian besar orang yang bekerja di tingkat majelis akan memberi tahu Anda bahwa belajar membaca kode bukanlah salah satu tantangan besar dalam pemrograman tingkat rendah.

Secara umum

Kualitas penamaan bukan hanya tentang memiliki nama deskriptif tetapi juga harus mempertimbangkan aspek-aspek lain, dan itu mengarah pada rekomendasi seperti:

• semakin global cakupannya, semakin deskriptif namanya
• semakin sering digunakan, semakin pendek nama seharusnya
• nama yang sama harus digunakan dalam semua konteks untuk hal yang sama
• hal yang berbeda harus memiliki nama yang berbeda walaupun konteksnya berbeda
• variasi harus mudah dideteksi
• ...

Perhatikan bahwa rekomendasi ini saling bertentangan.

Instruksi mnemonik

Sebagai programmer bahasa assembly, menggunakan short-branch-if-greater-or-equalfor bge.smemberi saya kesan yang sama daripada ketika saya melihat, sebagai programmer Algol melakukan geometri komputasi, SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSbukan dx := p2.x - p1.x. Saya hanya tidak setuju bahwa yang pertama lebih mudah dibaca dalam konteks yang saya pedulikan.

Daftarkan nama

Anda memilih nama resmi dari dokumentasi. Dokumentasi mengambil nama dari desain. Desain menggunakan banyak format grafis di mana nama yang panjang tidak memadai dan tim desain akan hidup dengan nama-nama itu selama berbulan-bulan, jika tidak bertahun-tahun. Untuk kedua alasan, mereka tidak akan menggunakan "Bendera interupsi penghitung waktu pertama", mereka akan menyingkatnya dalam skema mereka serta ketika mereka berbicara. Mereka mengetahuinya dan mereka menggunakan singkatan sistematis seperti TIFR1sehingga ada sedikit kemungkinan kebingungan. Satu hal di sini adalah bahwa TIFR1itu bukan singkatan acak, itu adalah hasil dari skema penamaan.

Terlepas dari alasan "kebiasaan lama", kode Legacy yang ditulis 30 tahun yang lalu dan masih digunakan sangat umum. Terlepas dari apa yang dipikirkan oleh beberapa orang yang kurang berpengalaman, refactoring sistem ini sehingga mereka terlihat cantik datang dengan biaya yang sangat tinggi untuk keuntungan kecil dan tidak layak secara komersial.

Sistem tertanam yang dekat dengan perangkat keras - dan mengakses register, cenderung menggunakan label yang sama atau serupa dengan yang digunakan dalam lembar data Perangkat Keras, untuk alasan yang sangat baik. Jika register disebut XYZZY1 dalam lembar data perangkat keras, masuk akal Variabel yang mewakili kemungkinan XYZZY1, atau jika programmer sedang bersenang-senang, RegXYZZY1.

Sejauh ini bge.s, ini mirip dengan assembler - untuk beberapa orang yang perlu mengetahuinya nama yang lebih panjang kurang dapat dibaca. Jika Anda tidak dapat mengarahkan Anda bge.sdan berpikir branch-if-greater-or-equal.shortakan membuat perbedaan - Anda hanya bermain dengan CLR dan tidak mengetahuinya.

Alasan lain Anda akan melihat nama variabel pendek adalah karena kami menyebarkan singkatan dalam domain yang ditargetkan oleh perangkat lunak.

Singkatnya - diharapkan nama variabel pendek yang mencerminkan pengaruh eksternal seperti norma industri dan lembar data perangkat keras. Nama variabel pendek yang bersifat internal untuk perangkat lunak biasanya kurang diinginkan.

Ada begitu banyak ide berbeda di sini. Saya tidak bisa menerima salah satu jawaban yang ada sebagai yang jawabannya: pertama, ada kemungkinan banyak faktor yang berkontribusi terhadap ini, dan kedua, saya tidak mungkin tahu mana yang paling signifikan.

Jadi, inilah ringkasan jawaban yang diposting oleh orang lain di sini. Saya memposting ini sebagai CW dan niat saya adalah untuk akhirnya menandainya diterima. Harap edit jika saya melewatkan sesuatu. Saya mencoba untuk mengulangi setiap ide untuk mengungkapkannya dengan singkat namun jelas.

Jadi mengapa pengidentifikasi pendek samar begitu umum dalam pemrograman tingkat rendah?

• Karena banyak dari mereka cukup umum di domain masing-masing untuk menjamin nama yang sangat pendek. Ini memperburuk kurva belajar, tetapi merupakan tradeoff yang berharga mengingat frekuensi penggunaannya.
• Karena biasanya ada satu set kecil kemungkinan yang diperbaiki (programmer tidak dapat menambah set).
• Karena keterbacaan adalah masalah kebiasaan dan praktik. branch-if-greater-than-or-equal.shortadalah awalnya lebih mudah dibaca daripada bge.s, tetapi dengan beberapa latihan situasi menjadi terbalik.
• Karena mereka sering harus diketik secara penuh, dengan tangan, karena bahasa tingkat rendah sering tidak disertai dengan IDE yang kuat yang memiliki pelengkapan otomatis yang baik, atau a / c tidak dapat diandalkan.
• Karena kadang-kadang diinginkan untuk mengemas banyak informasi ke dalam pengidentifikasi, dan nama yang dapat dibaca akan terlalu panjang bahkan oleh standar tingkat tinggi.
• Karena seperti itulah lingkungan tingkat rendah secara historis. Menghentikan kebiasaan membutuhkan upaya sadar, berisiko mengganggu orang-orang yang menyukai cara lama, dan harus dibenarkan sebagai orang yang berharga. Tetap dengan cara yang mapan adalah "default".
• Karena banyak dari mereka berasal dari tempat lain, seperti skema dan lembar data. Mereka, pada gilirannya, dipengaruhi oleh kendala ruang.
• Karena orang-orang yang bertanggung jawab atas penamaan hal-hal bahkan tidak pernah dianggap mudah dibaca, atau tidak menyadari bahwa mereka menciptakan masalah, atau malas.
• Karena dalam beberapa kasus nama-nama telah menjadi bagian dari protokol untuk pertukaran data, seperti penggunaan bahasa assembly sebagai representasi perantara oleh beberapa kompiler.
• Karena gaya ini langsung dikenali sebagai level rendah dan dengan demikian terlihat keren untuk Geeks.

Saya pribadi merasa bahwa beberapa di antaranya tidak benar-benar berkontribusi pada alasan mengapa sistem yang baru dikembangkan akan memilih gaya penamaan ini, tetapi saya merasa akan salah untuk menyaring beberapa ide dalam jenis jawaban ini.

Aku akan melemparkan topiku ke dalam kekacauan ini.

Konvensi dan standar pengkodean tingkat tinggi tidak sama dengan standar dan praktik pengkodean tingkat rendah. Sayangnya, sebagian besar dari mereka adalah peninggalan dari kode lama dan proses pemikiran lama.

Namun, beberapa di antaranya memang memiliki tujuan. Tentu BranchGreaterThan akan jauh lebih mudah dibaca daripada BGT , tetapi ada konvensi di sana sekarang, itu adalah instruksi dan karena itu telah mendapatkan sedikit daya tarik dalam 30 tahun terakhir digunakan sebagai standar. Mengapa mereka mulai dengan itu, mungkin beberapa batas lebar karakter acak untuk instruksi, variabel dan semacamnya; mengapa mereka menyimpannya, itu standar. Standar ini sama dengan menggunakan int sebagai pengenal, akan lebih mudah dibaca untuk menggunakan Integer dalam semua kasus, tetapi apakah perlu bagi siapa saja yang telah memprogram lebih dari beberapa minggu ... tidak. Mengapa? Karena ini adalah praktik standar.

Kedua, seperti yang saya katakan dalam komentar saya, banyak interupsi dinamai INTG1 dan nama-nama samar lainnya, ini melayani tujuan juga. Dalam diagram sirkuit, itu BUKAN konvensi yang baik untuk memberi nama baris Anda dan secara lisan itu mengacaukan diagram dan merusak keterbacaan. Semua verboseness ditangani dalam dokumentasi. Dan karena semua diagram pengkabelan / sirkuit memiliki nama-nama pendek untuk garis interupsi, interupsi itu sendiri juga mendapatkan nama yang sama untuk menjaga konsistensi bagi desainer yang disematkan dari diagram sirkuit hingga kode untuk memprogramnya.

Seorang desainer memiliki kontrol atas hal ini, tetapi seperti bidang / bahasa baru, ada konvensi yang mengikuti dari perangkat keras ke perangkat keras, dan dengan demikian harus tetap sama di setiap bahasa assembly. Saya dapat melihat potongan perakitan dan bisa mendapatkan inti dari kode tanpa menggunakan set instruksi karena mereka tetap pada konvensi, LDA atau beberapa hubungan dengannya mungkin memuat register. MV mungkin memindahkan sesuatu dari suatu tempat ke tempat lain. di tempat lain, ini bukan tentang apa yang Anda anggap baik atau merupakan praktik tingkat tinggi, itu adalah bahasa tersendiri dan karena itu memiliki standar sendiri dan berarti bahwa Anda sebagai perancang harus mengikuti, ini sering tidak hampir sewenang-wenang seperti mereka sepertinya.

Saya akan meninggalkan Anda dengan ini: Meminta komunitas tertanam untuk menggunakan praktik tingkat tinggi verbose adalah seperti meminta ahli kimia untuk selalu menulis senyawa kimia. Ahli kimia menulisnya singkat untuk diri mereka sendiri dan siapa pun di lapangan akan memahaminya, tetapi mungkin butuh pendatang baru sedikit waktu untuk menyesuaikan diri.

Salah satu alasan mereka menggunakan pengidentifikasi pendek samar adalah karena mereka tidak samar untuk pengembang. Anda harus menyadari bahwa mereka bekerja dengannya setiap hari dan nama-nama itu benar-benar nama domain. Jadi mereka hafal apa sebenarnya arti TIFR1.

Jika pengembang baru datang ke tim, ia harus membaca lembar data (seperti yang dijelaskan oleh @KarlBielefeldt) sehingga mereka akan merasa nyaman dengan itu.

Saya percaya pertanyaan Anda menggunakan contoh buruk karena memang pada kode sumber semacam itu Anda biasanya melihat banyak pengidentifikasi crypt yang tidak perlu untuk hal-hal non-domain.

Saya akan mengatakan sebagian besar mereka melakukan itu karena kebiasaan buruk yang ada ketika kompiler tidak secara otomatis melengkapi semua yang Anda ketik.

Ringkasan

Initialism adalah fenomena yang meluas di banyak kalangan teknis dan non-teknis. Karena itu tidak terbatas pada pemrograman tingkat rendah. Untuk diskusi umum, lihat artikel Wikipedia tentang Akronim . Jawaban saya khusus untuk pemrograman tingkat rendah.

Penyebab nama samar:

1. Instruksi tingkat rendah sangat diketik
2. Perlu mengemas banyak jenis informasi ke dalam nama instruksi tingkat rendah
3. Secara historis, kode satu karakter disukai untuk mengemas informasi jenis.

Solusi dan kelemahannya:

1. Ada skema penamaan tingkat rendah modern yang lebih konsisten daripada yang historis.
   • LLVM
2. Namun, kebutuhan untuk mengemas banyak jenis informasi masih ada.
   • Dengan demikian, singkatan samar masih dapat ditemukan di mana-mana.
3. Pembacaan garis-ke-garis yang ditingkatkan akan membantu programmer tingkat rendah pemula mengambil bahasa lebih cepat, tetapi tidak akan membantu memahami potongan besar kode tingkat rendah.

Jawaban penuh

(A) Nama yang lebih panjang dimungkinkan. Sebagai contoh, nama-nama intrinsik C ++ SSE2 rata-rata 12 karakter dibandingkan dengan 7 karakter dalam majelis mnemonik. http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(B) Pertanyaan kemudian beralih ke: Berapa lama / non-samar seseorang perlu dapatkan dari instruksi tingkat rendah?

(C) Sekarang kami menganalisis komposisi skema penamaan tersebut. Berikut ini adalah dua skema penamaan untuk instruksi tingkat rendah yang sama :

• Skema penamaan # 1: CVTSI2SD
• Skema penamaan # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) Instruksi tingkat rendah selalu diketik dengan kuat. Tidak boleh ada ambiguitas, inferensi jenis, konversi tipe otomatis, atau kelebihan muatan (penggunaan kembali nama instruksi berarti operasi yang serupa tetapi tidak setara).

(C.2) Setiap instruksi tingkat rendah harus menyandikan banyak jenis informasi ke dalam namanya. Contoh informasi:

• Keluarga Arsitektur
• Operasi
• Argumen (Input) dan Output
• Jenis (Integer Masuk, Integer Tanpa Tanda, Float)
• Presisi (Lebar Bit)

(C.3) Jika setiap informasi dijabarkan, program akan lebih bertele-tele.

(C.4) Skema pengkodean tipe yang digunakan oleh berbagai vendor memiliki akar sejarah yang panjang. Sebagai contoh, dalam set instruksi x86:

• B berarti byte (8-bit)
• W berarti kata (16-bit)
• D berarti dword "kata ganda" (32-bit)
• Q berarti qword "quad-word" (64-bit)
• DQ berarti dqword "double-quad-word" (128-bit)

Referensi sejarah ini tidak memiliki makna modern apa pun, tetapi masih ada. Skema yang lebih konsisten akan memasukkan nilai bit-width (8, 16, 32, 64, 128) ke dalam namanya.

Sebaliknya, LLVM adalah langkah yang tepat dalam arah konsistensi dalam instruksi tingkat rendah: http://llvm.org/docs/LangRef.html#functions

(D) Terlepas dari skema penamaan instruksi, program tingkat rendah sudah verbose dan sulit dimengerti karena mereka fokus pada detail menit pelaksanaan. Mengubah skema penamaan instruksi akan meningkatkan keterbacaan pada level line-to-line, tetapi tidak akan menghilangkan kesulitan memahami operasi dari sepotong kode besar.

Manusia kadang-kadang membaca dan menulis majelis, dan sebagian besar itu hanyalah protokol komunikasi. Yaitu, ini paling sering digunakan sebagai representasi berbasis teks serial antara antara kompiler dan assembler. Semakin jelas representasi ini, semakin banyak overhead yang tidak perlu dalam protokol ini.

Dalam kasus opcode dan mendaftarkan nama, nama panjang sebenarnya membahayakan keterbacaan. Mnemonik pendek lebih baik untuk protokol komunikasi (antara kompiler dan assember), dan bahasa assembly adalah protokol komunikasi hampir sepanjang waktu. Mnemonik pendek lebih baik untuk programmer, karena kode kompiler lebih mudah dibaca.

Sebagian besar idiom. Seperti @TMN katakan di tempat lain, sama seperti Anda tidak menulis import JavaScriptObjectNotationatau import HypertextTransferProtocolLibrarydengan Python, Anda tidak menulis Timer1LowerHalf = 0xFFFFdalam C. Itu terlihat sama konyolnya dalam konteks. Semua orang yang perlu tahu sudah tahu.

Perlawanan terhadap perubahan mungkin timbul, sebagian, dari kenyataan bahwa beberapa vendor kompiler C untuk sistem embedded menyimpang dari standar bahasa dan sintaks untuk mengimplementasikan fitur yang lebih berguna untuk pemrograman tertanam. Ini berarti bahwa Anda tidak dapat selalu menggunakan fitur autocomplete dari IDE atau editor teks favorit Anda saat menulis kode tingkat rendah, karena penyesuaian ini mengalahkan kemampuan mereka untuk menganalisis kode. Karenanya utilitas nama register pendek, makro dan konstanta.

Sebagai contoh, kompiler C HiTech menyertakan sintaks khusus untuk variabel yang perlu memiliki posisi yang ditentukan pengguna dalam memori. Anda mungkin menyatakan:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

Sekarang satu-satunya IDE yang ada yang akan menguraikan ini adalah HiTech's IDE sendiri ( HiTide ). Di editor lain mana pun, Anda harus mengetiknya secara manual, dari memori, setiap kali. Ini menjadi tua dengan sangat cepat.

Lalu ada juga fakta bahwa ketika Anda menggunakan alat pengembangan untuk memeriksa register, Anda akan sering memiliki tabel yang ditampilkan dengan beberapa kolom (nama register, nilai dalam hex, nilai dalam biner, nilai terakhir dalam hex, dll). Nama panjang berarti Anda harus memperluas kolom nama menjadi 13 karakter untuk melihat perbedaan antara dua register, dan bermain "spot the difference" di puluhan baris kata yang diulang.

Ini mungkin kedengarannya seperti quibbles kecil yang konyol, tetapi tidakkah setiap konvensi pengkodean dirancang untuk mengurangi ketegangan mata, mengurangi pengetikan berlebihan atau mengatasi salah satu dari sejuta keluhan kecil lainnya?

Saya terkejut bahwa tidak ada yang menyebutkan kemalasan dan bahwa ilmu-ilmu lain tidak dibahas. Pekerjaan saya sehari-hari sebagai programmer menunjukkan kepada saya bahwa konvensi penamaan untuk segala jenis variabel dalam suatu program dipengaruhi oleh tiga aspek berbeda:

1. Latar belakang ilmiah programmer.
2. Keterampilan pemrograman programmer.
3. Lingkungan programmer.

Saya pikir tidak ada gunanya membahas tentang pemrograman tingkat rendah atau tingkat tinggi. Pada akhirnya itu selalu bisa dijabarkan ke tiga aspek sebelumnya.

Penjelasan tentang aspek pertama: Banyak "programmer" bukan programmer di tempat pertama. Mereka adalah ahli matematika, ahli fisika, ahli biologi atau bahkan psikolog atau ekonom tetapi banyak dari mereka bukan ilmuwan komputer. Sebagian besar dari mereka memiliki kata kunci dan singkatan khusus domain khusus yang dapat Anda lihat di "konvensi" penamaan mereka. Mereka sering terjebak dalam domain mereka dan menggunakan singkatan yang dikenal tanpa memikirkan pembacaan atau panduan pengkodean.

Penjelasan tentang aspek kedua: Karena sebagian besar programmer bukan ilmuwan komputer, keterampilan pemrograman mereka terbatas. Itulah sebabnya mereka sering tidak peduli tentang konvensi pengkodean tetapi lebih pada konvensi khusus domain sebagaimana dinyatakan sebagai aspek pertama. Juga jika Anda tidak memiliki keterampilan seorang programmer Anda tidak memiliki pemahaman tentang aturan pengkodean. Saya pikir sebagian besar dari mereka tidak melihat kebutuhan mendesak untuk menulis kode yang dapat dimengerti. Seperti api dan lupakan.

Penjelasan tentang aspek ketiga: Tidak mungkin untuk rem dengan konvensi lingkungan Anda yang bisa menjadi kode lama yang Anda harus mendukung, standar pengkodean perusahaan Anda (dijalankan oleh ekonom yang tidak peduli tentang pengkodean) atau domain tempat Anda berada. Jika seseorang mulai menggunakan nama samar dan Anda harus mendukungnya atau kode-kodenya, Anda tidak mungkin mengubah nama samar itu. Jika tidak ada standar pengkodean di perusahaan Anda, saya yakin hampir setiap programmer akan menulis standar mereka sendiri. Dan terakhir jika Anda dikelilingi oleh pengguna domain Anda tidak akan mulai menulis bahasa lain daripada yang mereka gunakan.