Apakah saya mengorbankan nama variabel yang lebih pendek untuk kode "kolom" yang lebih panjang?


17

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?


26
Teruskan; tambahkan lebih banyak nama berguna. Dapatkah Anda memikirkan cara untuk menggambarkan cipherColumn + (rowSize*nextWord) + nextWordbahwa 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.
jonrsharpe

2
Hmm .. jadi maksudmu saya harus membuat variabel baru dan menyimpan hasil cipherColumn + (rowSize * nextWord) + nextWord ke dalamnya sehingga saya bisa menggunakannya lebih lanjut? Apakah itu yang dilakukan pro? Saya benar-benar bertanya
RaulT

8
Ya, itulah saran saya. Saya seorang profesional dan itulah yang akan saya lakukan, jadi ... beberapa dari mereka, setidaknya.
jonrsharpe

11
Aturan emas adalah menulis kode yang dapat dibaca dan dipahami. kami menulis kode untuk orang lain (!) bukan untuk mesin. untuk mesin ada kode mesin. bagi sebagian orang, kode yang terlihat seperti yang Anda gambarkan (nama huruf tunggal dll) adalah kurangnya rasa hormat terhadap programmer lain (dan Anda di masa depan - karena Anda akan lupa dalam beberapa minggu atau bulan ke depan). tidak ada alasan untuk tetap menggunakan 80 kolom, ini bukan MS DOS di tahun 80-an.
rsm

3
@stijn ya, tapi ini terakhir kali kami membutuhkannya. sama seperti saya tidak mengkompilasi kode c saya untuk prosesor 8086 8-bit jika saya perlu menyimpannya pada kartu punch, saya juga tidak berpikir 80 kolom stardard emas memiliki arti penting dalam abad ke-21. kita harus merentangkan teknologi ini, tidak duduk di tahun 80-an dan berpikir itu membuat kita peretas yang pintar. pintar adalah kesederhanaan, keterbacaan dan mendorong teknologi secara maksimal. kami memiliki monitor full-hd, saatnya untuk menggunakannya.
rsm

Jawaban:


24

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:

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;
        }
    }
}

Istirahat yang mungkin mengejutkan, tapi lebih mudah dibaca daripada versi dengan scroll horisontal, dan itu lebih baik daripada memperpendek nama untuk i, j, dan k.

Ini bukan berarti bahwa Anda tidak harus menggunakan i, jdan k. Itu adalah nama yang bagus saat mengindeks 3 forloop 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.

int calcCipherColumn(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;
        }
    }
    return cipherColumn;
}

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 continuejuga tidak melakukan apa-apa.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn    = 0;
    int cipherColumn = 0;
    int offset       = 1;
    int nextWord     = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

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.

int calcCipherColumn(char keyWord[25], char cipherText[17424],
                     int rowSize, char message[388]) 
{
    int keyColumn = 0;
    int cipherColumn = 0;
    int offset = 1;
    int nextWord = 1;

    while (keyWord[keyColumn] != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyWord[keyColumn + offset] 
        != cipherText[cipherColumn + (rowSize*nextWord) + nextWord]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

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.

int calcCipherColumn(
        char keyWord[25], 
        char cipherText[17424],
        int rowSize, 
        char message[388]
) {
    int keyColumn = 0;
    int keyOffset = 1;

    int nextWord = 1;
    int cipherColumn = 0;
    int cipherOffset = (rowSize * nextWord) + nextWord;

    char key = keyWord[keyColumn];
    char keyNext = keyWord[keyColumn + keyOffset];

    while (key != cipherText[cipherColumn]) {
        cipherColumn++;
        if (keyNext != cipherText[cipherColumn + cipherOffset]) {
            cipherColumn++;
        }
    }
    return cipherColumn;
}

Di sana, sekarang logika dalam loop difokuskan pada perubahan apa dalam loop. Bahkan, segala sesuatu kecuali cipherColumnbisa ditandai final. 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 keydan keyNexttidak 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.


Wow itu deskriptif! Ya saya tahu kode itu tidak benar-benar melakukan apa-apa, saya mungkin harus memposting lebih dari potongan kecil itu tapi saya kira saya sedang mencoba untuk mendapatkan ide umum tentang apa yang pro lakukan dalam hal panjang kolom kode dan nama-nama variabel, tetapi jawaban Anda menunjukkan beberapa perubahan yang sangat manis, saya pasti akan menerapkannya dalam kode saya mulai sekarang! Satu pertanyaan lagi yang saya miliki adalah: di mana Anda merasa cocok untuk membuat linebreak? Sebelum operator? Apakah ada "standar" yang diterima?
RaulT

1
@RaulT meluangkan waktu membaca basis kode apa pun yang Anda gunakan. Ini akan memberi Anda gambaran tentang apa yang dapat Anda gunakan yang tidak akan mengejutkan pembuat kode lain. Ikuti dokumen standar jika Anda memilikinya. Tetapi yang terbaik adalah bertanya pada sesama programmer dan tanyakan kepada mereka seberapa mudah barang-barang Anda dibaca. Oh dan lihat codereview.stackexchange.com
candied_orange

Saya akan menambahkan komentar di bawah cipherOffset dan menjelaskan perhitungan karena rumus itu tidak jelas. Anda AKAN lupa mengapa dalam tiga minggu.
Nelson

15

Yang lain telah membuat beberapa saran yang berguna, izinkan saya meringkas:

  • 80 karakter per baris mungkin merupakan aturan emas di tahun 80-an. Saat ini kebanyakan orang setuju bahwa 100 hingga 130 karakter baik-baik saja.
  • Gunakan linebreak di dalam ekspresi Anda.
  • Pisahkan ekspresi yang panjang dengan memperkenalkan hasil antara.

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 columnatau bahkan col. Jika ruang lingkup lebih besar dan ada beberapa tabel yang terlibat, masuk akal untuk menyebutnya keyWordEncryptionTableColumn.

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, katakanlah arrayIndexOfMyVerySpecialDataSet.


1
Saya setuju dengan jawaban Anda. Di tempat kerja kami menggunakan 80 char / line untuk c / c ++ untuk alasan warisan dan karena kami menggunakan papan ulasan. Untuk karakter C # 100 / baris, kadang-kadang saya melanggar aturan dan sedikit lebih dari 100 untuk menjaga keterbacaan.
peval2727

Wow, jawaban yang bagus !! Semua jawaban ini luar biasa, terima kasih atas bantuan yang saya hargai!
RaulT

Saya sangat setuju dengan menekan ide bahwa 80 baris karakter sudah usang. Ini masih berlaku untuk proyek dan tempat tertentu (kebanyakan untuk konsistensi), tetapi bagi banyak orang, itu jelas tidak perlu. Banyak pengembang menggunakan sesuatu seperti Visual Studio atau IntelliJ pada monitor penuh dan memiliki monitor kedua untuk hal-hal lain (dokumentasi, dll). Dengan demikian mereka memiliki banyak layar real estat untuk kode mereka. Jika Anda hanya menggunakan 80 karakter per baris, Anda mungkin memiliki satu ton ruang yang tidak digunakan. Dan batas 80 karakter menyakiti Anda! Terutama ketika Anda menganggap bahwa lib standar dapat memaksa nama pantat panjang.
Kat

1
Maksud saya adalah bahwa dalam beberapa bahasa, benar-benar tidak ada menghindari fakta bahwa 80 karakter adalah batasan besar. Jadi mengapa tidak perlu? Ini juga meminta menyebutkan bahwa hampir semua editor nama besar dan IDE memiliki bungkus kata lunak pintar yang sangat baik hari ini, yang memungkinkan Anda tidak membatasi panjang garis sama sekali. Anda bisa membiarkan panjang garis menjadi apa pun yang bisa dilihat pembaca. Mereka dapat mengubah ukuran jendela mereka untuk mendapatkan hasil yang lebih optimal. Saya pribadi menemukan bahwa pendekatan ini kadang-kadang ideal. Dan saya belum kecewa dengan cara bungkus lunak ini bekerja.
Kat

Setiap kali Anda menggunakan nama variabel sederhana, Anda HARUS 100% memastikan ruang lingkup. Saya menghabiskan tiga jam untuk belajar tentang penutupan JavaScript.
Nelson

3

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:

ExtractMessage(char keyWord[25], char cipherText[17424],
               int rowSize, char message[388]) 

Ini tidak ada gunanya, hanya membatasi panjang garis tidak membuatnya lebih mudah dibaca. Jika Anda ingin ini dapat dibaca, lakukan ini:

ExtractMessage(
  char keyWord[25],
  char cipherText[17424],
  int rowSize,
  char message[388]
  )
{

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:

int keyColumn    = 0;
int cipherColumn = 0;
int offset       = 1;
int nextWord     = 1;

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.


1
Secara pribadi, blok kode pertama dalam jawaban Anda jauh lebih mudah dibaca bagi saya daripada yang kedua.
Miles Rout

1
tidak pernah melakukan yang ketiga, itu adalah mimpi buruk pemeliharaan untuk tetap seperti itu.
jwenting

3

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:

  1. 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:

  2. 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 .

  3. 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.


3

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, idan jdan kyang 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, iberfungsi dengan baik. Saya tidak akan menggunakan nama seperti currentElement- 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.


-1

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)


1
Ya, ini pasti mungkin. C mengenali baris dan baris kode sampai Anda menambahkan sesuatu seperti titik koma. Masalahnya adalah bahwa fungsi kami tidak dapat melebihi 50 baris, dan meskipun kode contoh saya tidak memiliki 50 baris, itu hanya sebagian kecil dari total fungsi saya. Saya merasa sangat terbatas untuk menulis dalam kotak 50 x 80, algoritma dengan variabel bermakna yang dapat melakukan fungsi yang saya butuhkan juga. Saya bisa terus menyimpan potongan kode yang panjang ini ke dalam fungsi-fungsi baru, tetapi saya merasa saya akan berakhir dengan begitu banyak panggilan fungsi, orang-orang akan tersesat membaca kode.
RaulT

5
"Aku merasa aku akan berakhir dengan begitu banyak panggilan fungsi, orang akan tersesat membaca kode." Justru sebaliknya! Mengekstraksi kode menjadi metode terpisah memungkinkan Anda memberi mereka nama deskriptif yang meningkatkan keterbacaan (terutama metode yang Anda gunakan untuk mengekstraksi). Jika Anda berakhir dengan terlalu banyak metode, kelas Anda mungkin melakukan terlalu banyak (prinsip tanggung jawab tunggal). Mengekstrak metode ke dalam kelas yang terpisah lagi memungkinkan Anda untuk memberikan nama deskriptif pada benda itu.
Roman Reiner

Setiap fungsi yang mendekati 50 baris mungkin terlalu panjang dan terlalu rumit, (dengan kemungkinan inisialisasi data dengan kompleksitas 1), tetapi biasanya ketika batas seperti yang dibahas adalah garis kode bukan garis teks sehingga membelah satu baris kode, yaitu ke titik koma sering tidak akan dihitung sebagai baris tambahan, tanyakan kepada Prof!
Steve Barnes
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.