Saya seorang programmer amatir di kelas CS yang mencoba mempelajari keterampilan pemrograman yang tepat. Ini adalah bagaimana kode saya terlihat, ujung-ujungnya meluas ke 103 kolom.
int extractMessage(char keyWord[25], char cipherText[17424],
int rowSize, char message[388])
{
int keyColumn = 0;
int cipherColumn = 0;
int offset = 1;
int nextWord = 1;
int lengthOfWord = 0;
int lengthOfCipher = 0;
lengthOfWord = length(keyWord);
lengthOfCipher = length(cipherText);
while (keyWord[keyColumn] != cipherText[cipherColumn]) {
cipherColumn++;
if (keyWord[keyColumn + offset] != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
cipherColumn++;
continue;
}
}
Sebelum saya memiliki nama-nama variabel yang sangat panjang itu, saya memiliki sesuatu seperti i, j, k, tetapi profesor saya bersikeras bahwa kita tidak boleh menggunakan variabel seperti itu di "dunia profesional" dan bahkan variabel yang diperpendek seperti lenWord tidak cukup karena orang mungkin berasumsi itu singkatan dari "Lennard's World Literature". Dia mengatakan untuk memilih nama variabel yang bermakna tetapi dengan melakukan itu saya merasa seperti saya telah melanggar Aturan Emas pengkodean untuk menyimpannya di bawah 80 kolom. Bagaimana saya mengatasi ini?
sumber
cipherColumn + (rowSize*nextWord) + nextWord
bahwa merek itu jelas apa perhitungan yang untuk , misalnya? Saya bertaruh nama itu lebih pendek dari perhitungan, sehingga Anda mendapatkan manfaat keterbacaan dan panjang garis yang dikurangi. Juga jangan menyelaraskan tugas, atau Anda harus memindahkan semuanya jika Anda mengganti nama variabel terpanjang.Jawaban:
Biasanya ketika saya melihat kode diposting di sini seperti milik Anda, saya mengeditnya, karena kami benci gulir horizontal. Tetapi karena itu adalah bagian dari pertanyaan Anda, saya akan menunjukkan kepada Anda hasil edit di sini:
Istirahat yang mungkin mengejutkan, tapi lebih mudah dibaca daripada versi dengan scroll horisontal, dan itu lebih baik daripada memperpendek nama untuk
i
,j
, dank
.Ini bukan berarti bahwa Anda tidak harus menggunakan
i
,j
dank
. Itu adalah nama yang bagus saat mengindeks 3for
loop bersarang . Tapi di sini nama-nama itu adalah satu-satunya petunjuk saya tentang apa yang Anda harapkan terjadi. Terutama karena kode ini tidak benar-benar melakukan apa pun.Aturan terbaik untuk mengikuti panjang nama variabel adalah cakupan. Semakin lama sebuah variabel hidup, semakin banyak variabel sesama namanya harus bersaing. Nama CandiedOrange unik pada pertukaran tumpukan. Jika kami sedang mengobrol, Anda bisa memanggil saya "Permen". Tetapi sekarang, Anda berada dalam ruang lingkup di mana nama itu dapat dikacaukan dengan Candide , Candy Chiu , atau Candyfloss . Jadi semakin panjang cakupannya, semakin lama namanya. Semakin pendek cakupannya, semakin pendek namanya.
Panjang garis tidak boleh mendikte panjang nama. Jika Anda merasa seperti itu maka cari cara lain untuk mengeluarkan kode Anda. Kami memiliki banyak alat untuk membantu Anda melakukan itu.
Salah satu hal pertama yang saya cari adalah kebisingan yang tidak perlu untuk dihilangkan. Sayangnya contoh ini tidak melakukan apa-apa, jadi itu semua kebisingan yang tidak perlu. Saya perlu sesuatu untuk dikerjakan, jadi mari kita membuatnya melakukan sesuatu.
Di sana, sekarang ia melakukan sesuatu.
Sekarang ia melakukan sesuatu, saya bisa melihat apa yang bisa saya singkirkan. Barang panjang ini bahkan tidak digunakan. Ini
continue
juga tidak melakukan apa-apa.Mari kita membuat sedikit ruang putih kecil, karena kita hidup di dunia kontrol sumber dan itu bagus ketika satu-satunya alasan garis dilaporkan sebagai diubah adalah karena itu melakukan sesuatu yang berbeda, bukan karena sebagian dari itu harus berbaris dalam kolom.
Ya, saya tahu itu sedikit kurang dapat dibaca tetapi jika tidak Anda akan membuat orang gila yang menggunakan alat vdiff untuk mendeteksi perubahan.
Sekarang mari kita perbaiki jeda garis konyol yang kita miliki ini karena kita berusaha untuk tetap berada di bawah batas panjang garis.
Di sana, sekarang logika dalam loop difokuskan pada perubahan apa dalam loop. Bahkan, segala sesuatu kecuali
cipherColumn
bisa ditandaifinal
. Dan hei! Lihat itu. Kami sekarang memiliki ruang untuk melakukannya.Yang saya lakukan adalah menambahkan 3 variabel lagi, mengganti nama satu, dan mengatur ulang mereka sedikit. Dan hasilnya kebetulan membuat garis cukup pendek agar pas tanpa linebreak konyol
!=
.Tentu nama-nama
key
dankeyNext
tidak deskriptif, tetapi masing-masing hanya digunakan sekali, tidak hidup selama itu, dan yang paling penting tidak melakukan sesuatu yang menarik dalam lingkaran. Jadi mereka tidak perlu seperti itu. Dengan memperkenalkan variabel tambahan, kami sekarang memiliki ruang untuk membuat nama mereka panjang jika perlu. Banyak hal berubah, jadi pada akhirnya kita mungkin perlu. Jika kita melakukannya, itu bagus bahwa kita memiliki ruang bernapas.Saya juga mengambil kebebasan untuk menunjukkan kepada Anda bentuk 6 varian gaya Jeff Grigg dari meletakkan parameter input untuk menghormati batasan panjang garis.
sumber
Yang lain telah membuat beberapa saran yang berguna, izinkan saya meringkas:
Saya ingin menambahkan rekomendasi lain: Jangan bersikap dogmatis tentang nama panjang! Semakin besar cakupan variabel, semakin banyak informasi yang harus dimasukkan ke namanya. Dan umumnya itu adalah ide yang baik untuk menjaga ruang lingkup variabel kecil.
Misalnya, jika Anda memiliki variabel untuk kolom tabel enkripsi kata kunci Anda dan jelas bahwa hanya ada satu tabel ini yang digunakan dalam lingkup variabel Anda, tidak masalah untuk menyebutnya
column
atau bahkancol
. Jika ruang lingkup lebih besar dan ada beberapa tabel yang terlibat, masuk akal untuk menyebutnyakeyWordEncryptionTableColumn
.Contoh lain: Jika Anda memiliki loop dengan tubuh yang mencakup dua atau tiga baris dan harus menggunakan indeks untuk mengakses elemen array, tidak ada yang salah dengan memanggil indeks
i
. Dalam konteks ini lebih mudah dibaca (bagi kebanyakan orang setidaknya) daripada, katakanlaharrayIndexOfMyVerySpecialDataSet
.sumber
Saya biasanya setuju dengan Anda guru. Namun, jika Anda memiliki variabel yang akan Anda gunakan banyak dalam sepotong kode faily besar, bisa lebih baik menggunakan bentuk steno untuknya setelah secara eksplisit tentang artinya. Seperti ketika Anda memiliki banyak ekspresi dan tugas aritmatika yang kompleks, yang tidak dapat membaca dengan baik dengan nama variabel yang panjang.
Tentang menguraikan:
Ini tidak ada gunanya, hanya membatasi panjang garis tidak membuatnya lebih mudah dibaca. Jika Anda ingin ini dapat dibaca, lakukan ini:
Dan kemudian Anda bahkan mungkin ingin menyelaraskan pengenal tipe (tambahkan spasi setelah int). Namun, berhati-hatilah / membatasi dengan menguraikan initalizations atau daftar argumen seperti ini:
Masalahnya adalah ketika Anda mengubah nama atau menambahkan variabel, Anda mungkin harus memformat ulang seluruh blok untuk mempertahankan tampilan yang cantik. Ini bukan untuk pekerjaan sebanyak perubahan yang tidak berarti yang Anda perkenalkan, itu akan terlihat mengerikan dalam sistem kontrol versi. Rekan kerja Anda akan melihat Anda mengubah file dan melakukan perbedaan dengan versi sebelumnya untuk melihat apa yang Anda lakukan. Kemudian setiap baris akan menyala seperti yang diubah, mengaburkan perubahan nyata. Ini akan sedikit bergantung pada kualitas alat pembanding yang digunakan seberapa buruk ini sebenarnya tetapi secara umum itu bukan ide yang baik untuk membuat kode terlalu pribadi dan / atau memiliki format satu baris bergantung pada yang lain.
Kadang-kadang garis besar dapat melayani tujuan, jika Anda memiliki puluhan baris berturut-turut yang hampir sama akan mudah untuk menemukan di mana mereka berbeda jika Anda menguraikannya.
Perhatikan bahwa tempat kerja mungkin memiliki beberapa pemformatan otomatis yang terjadi yang hanya akan menghapus pemformatan mewah yang Anda lakukan pada kode Anda sebelum mengirimkannya ke sistem kontrol versi.
sumber
Penafian: Saya sedikit melebih-lebihkan di sini untuk membuat poin saya lebih jelas. Jadi, minumlah superlatif dengan sebutir garam.
Guru Anda 100% benar: Tidak ada "aturan emas" tentang 80 karakter lagi (kecuali jika Anda menulis kode linux, itu adalah). Aturan itu dibuat karena ukuran terminal pada saat itu, tetapi saat ini, Anda dengan mudah menjejalkan lebih dari 150 karakter di jendela enditor Anda. Dan bahkan jika Anda melebihi batas itu, editor Anda diharapkan akan membungkus baris sehingga Anda tidak perlu menggulir. Dan satu-satunya alasan untuk tidak melampaui 80 karakter adalah perlunya bergulir .
Yang mengatakan, memang ada kebutuhan untuk tidak membiarkan garis Anda tumbuh tanpa batas. Semakin panjang garis, semakin sulit bagi manusia untuk mengurai. Tapi nama variabel pendek bukan obat untuk masalah garis panjang .
Obatnya adalah dengan membagi ekspresi Anda secara logis dengan memperkenalkan variabel yang lebih tepat namanya . Jangan mencoba menjadi pintar dengan ruang kosong. Identifikasi saja subekspresi yang dapat dinamai dengan tepat, dan buat variabel untuknya. Itu menyederhanakan kode menghitung variabel, dan kode menggunakan variabel itu .
Bukan bagian dari pertanyaan Anda, tetapi saya tetap ingin mengomentarinya: Ini adalah ide yang sangat buruk untuk menyelaraskan
=
operator Anda secara vertikal .Ada tiga alasan untuk itu:
Mengedit blok yang berisi operator bertanda vertikal adalah PITA. Kapan pun panjang perubahan variabel terbesar (ganti nama, penambahan, penghapusan), Anda harus memperbaiki semua baris di blok untuk mendapatkan kembali tata letak "bagus" Anda.
Tentu saja, masalah ini dapat dikurangi sedikit dengan menggunakan editor yang kompeten, jadi itu alasan kecil. Alasan sebenarnya adalah yang kedua:
Perubahan spasi putih palsu yang diperkenalkan dengan menyelaraskan kembali tidak bermain dengan baik dengan sistem kontrol versi modern seperti
git
. Mereka cenderung menciptakan sejumlah besar konflik gabungan di mana tidak ada konflik nyata yang terjadi, dan di mana tidak ada konflik akan ditandai jika keberpihakan tidak digunakan. Setiap konflik palsu ini akan menghabiskan waktu Anda yang berharga tanpa biaya .Penjajaran membawa nol makna semantik . Tidak ada gunanya. Tidak ada yang bisa Anda pahami dengan lebih baik dengan perataan. Setiap baris di blok Anda perlu membaca sendiri untuk memahami apa yang dilakukannya, koneksi ke baris di atas dan di bawah ini murni bersifat sintaksis.
Karena penyejajaran tidak memiliki makna semantik apa pun, tetapi menghasilkan biaya yang signifikan, Anda harus menghapus kebiasaan sebelum menghabiskan waktu lagi.
Jika Anda sangat menyukai batas 80 karakter, cobalah beberapa pemrograman fortran. Benar, standar yang lebih baru telah meningkatkan batas garis fortran menjadi 132 karakter, tetapi tetap berlaku seperti yang selalu melumpuhkan kompilasi program apa pun yang melebihi batas. Jika Anda pandai pemrograman, Anda akan segera membenci fortran, termasuk batas panjang garisnya. Setelah itu, Anda akan disembuhkan selama sisa hidup Anda.
Saya sendiri harus melakukan pemrograman fortran secara profesional, dan saya katakan, itu telah mengajarkan saya untuk membenci batas panjang garis yang paling mahal. Sama sekali tidak ada yang lebih membuat frustrasi daripada harus memecah baris yang sederhana dan mudah dibaca menjadi beberapa bagian hanya karena kompiler tidak akan mengkompilasinya dengan benar lagi. Dan pasti ada baris kode yang paling sederhana ketika diekspresikan sebagai satu baris.
sumber
Banyak konvensi gaya (bukan aturan!) Bermunculan selama bertahun-tahun karena keterbatasan dalam lingkungan pemrograman. Kembali di hari kartu punch, Anda memiliki batas keras pada jumlah karakter yang dapat muncul pada garis sumber fisik (itulah sebabnya Fortran memesan kolom 6 untuk karakter garis-kelanjutan). Bukan beberapa dekade yang lalu bahwa saya mengerjakan terminal VT220 80x24 amber-on-black; sementara editor yang saya gunakan tidak membatasi garis hingga 80 karakter, hidup hanya jauh lebih mudah jika Anda melakukan yang terbaik untuk menghindari pengguliran horizontal.
Di bawah versi Fortran yang lebih lama (hingga '77, IINM), Anda bahkan tidak dapat memiliki pengidentifikasi yang panjangnya lebih dari 6 hingga 8 karakter. Bahkan hingga tahun 80-an, C hanya akan menjamin bahwa 8 karakter pertama dalam nama eksternal bermakna (itulah sebabnya beberapa fungsi perpustakaan memiliki nama deskriptif yang sangat disukai
strpbrk
).Tentu saja, dua dekade menuju abad ke-21, kita tidak memiliki batasan itu lagi. Tidak ada alasan untuk tidak menggunakan pengidentifikasi yang lebih deskriptif.
Masalahnya, dalam konteks yang tepat,
i
danj
dank
yang masuk akal, nama-nama bermakna . Jika saya mengulang melalui array atau vektor dalam satu lingkaran dan saya hanya perlu sesuatu untuk mengidentifikasi elemen saat ini,i
berfungsi dengan baik. Saya tidak akan menggunakan nama seperticurrentElement
- itu tidak lebih berarti dalam konteks itu , dan itu hanya menambah kekacauan visual.Karena itu, guru Anda tidak salah dalam memaksa Anda untuk berpikir dalam hal nama yang lebih panjang dan lebih deskriptif untuk segalanya - hidup akan lebih mudah bagi Anda jika Anda terbiasa dengan kebiasaan itu, dan kemudian belajar ke mana harus berhemat sesuai kebutuhan. Sebagai seseorang yang berada pada satu waktu terpaksa cocok segala sesuatu ke dalam 8 karakter atau kurang, itu jelas lebih baik untuk err di sisi informasi lebih dari kurang. Ketika Anda mendapatkan lebih banyak pengalaman, Anda akan belajar di mana Anda bisa menghemat panjang pengenal, dan di mana Anda harus sedikit lebih deskriptif.
sumber
Saya tidak yakin apakah ini berfungsi untuk c atau tidak tetapi apakah ada cara untuk membagi rumus di beberapa baris? Saya tahu sesuatu seperti itu ada untuk python.
Lihat apakah Anda dapat memulai + (rowSize * nextWord) + nextWord]) {pada baris baru. (Seperti tekan enter di IDE Anda dan lihat apakah indentasi begitu C tahu bahwa ekspresi sebelumnya sedang diselesaikan pada baris saat ini)
sumber