Daha uzun “sütunlu” kod için daha kısa değişken adlarını feda eder miyim?

Ben bir CS sınıfında uygun programlama becerilerini öğrenmeye çalışan amatör bir programcıyım. Kodum böyle görünüyor, kenarları 103 sütuna uzanıyor.

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

Bu süper uzun değişken isimlere sahip olmadan önce i, j, k gibi bir şeyim vardı, ama profesörüm "profesyonel dünyada" böyle değişkenleri kullanmamamız gerektiği ve lenWord gibi kısaltılmış değişkenlerin bile yetersiz olduğu konusunda ısrar ediyor . "Lennard'ın Dünya Edebiyatı" anlamına gelmektedir. Anlamlı değişken isimleri seçtiğini söylüyor, ancak bunu yaparak 80 sütunun altında tutmak için Altın Kodlama Kuralını kırmış gibi hissediyorum. Bunu nasıl çözebilirim?

Normalde burada sizinki gibi yayınlanan kodları gördüğümde, onu düzenlerim, çünkü yatay kaydırmadan nefret ederiz. Ancak bu, sorunuzun bir parçası olduğundan, size düzenlemeyi burada göstereceğim:

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

Bu kırılma şaşırtıcı olabilir, ancak yatay kaydırma ile sürümden daha okunabilir, ve o isimler kısaltarak daha iyi i, jve k.

Bu kullanmaması gerektiğini değil i, jve k. 3 iç içe fordöngüyü dizine eklerken bunlar iyi adlardır . Ama burada isimler gerçekten ne olmasını beklediğime dair tek ipucum. Özellikle bu kod aslında hiçbir şey yapmadığı için.

Değişken adı uzunluğunda uygulanacak en iyi kural kapsamdır. Bir değişken ne kadar uzun yaşarsa, adının rekabet etmesi gereken diğer değişkenler de o kadar fazla olur. CandiedOrange adı yığın değişiminde benzersizdir. Bir sohbette olsaydık, bana sadece "Şeker" diyebilirsin. Ama şu anda, bu ismin Candide , Candy Chiu veya Candyfloss ile karıştırılabileceği bir kapsamın içindesiniz . Yani kapsam ne kadar uzun olursa, ad o kadar uzun olmalıdır. Kapsam ne kadar kısa olursa, ad o kadar kısa olabilir.

Satır uzunluğu asla ad uzunluğunu dikte etmemelidir . Eğer öyle olduğunu düşünüyorsanız kodunuzu düzenlemek için farklı bir yol bulmak. Bunu yapmanıza yardımcı olacak birçok aracımız var.

Aradığım ilk şeylerden biri, kurtulmak için gereksiz gürültüdür. Ne yazık ki bu örnek hiçbir şey yapmaz, bu yüzden hepsi gereksiz gürültüdür. Çalışmak için bir şeye ihtiyacım var, bu yüzden önce bir şey yapalım.

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

Orada, şimdi bir şey yapıyor.

Şimdi bir şey yaptığını görebildiğim şeyden anlayabiliyorum. Bu uzunluktaki şeyler bile kullanılmıyor. Bu continueda hiçbir şey yapmıyor.

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

Bazı küçük beyaz boşluk ayarlamaları yapalım, çünkü kaynak kontrolü dünyasında yaşıyoruz ve bir satırın değiştiği bildirilmesinin tek nedeni, bir kısmının bir sütunda sıralanması gerektiği için değil, farklı bir şey yapmasıdır.

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

Evet, biraz daha az okunabilir olduğunu biliyorum, ancak aksi takdirde değişiklikleri tespit etmek için vdiff araçlarını kullanan insanları delirteceksiniz.

Şimdi sahip olduğumuz bu aptal satır sonlarını düzeltelim çünkü satır uzunluğu sınırlarının altında kalmaya çalışıyoruz.

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

Orada, şimdi döngüdeki mantık döngüdeki değişikliklere odaklanıyor. Aslında, hariç her şey cipherColumnişaretlenebilir final. Ve hey! Şuna bak. Şimdi bunu yapacak yerimiz var.

Tüm yaptığım 3 değişken daha eklemek, birini yeniden adlandırmak ve biraz yeniden düzenlemek oldu. Ve sonuç sadece çizgileri aptalca bir çizgi kırmadan sığacak kadar kısa hale getirdi !=.

Tabii isimler keyve keyNextdeğil o tanımlayıcı, ama sadece bir kez alışması her Çok uzun olmayan canlı yapmak ve en önemlisi döngü içinde ilginç olduğu bir şey yapmıyoruz. Yani olmalarına gerek yok. Ekstra değişkenler ekleyerek artık ihtiyaç duymamız halinde isimlerini uzun süre uzatabiliriz. İşler değişir, bu yüzden sonunda yapmamız gerekebilir. Eğer yaparsak, nefes alanımız olması güzel.

Ayrıca, hat uzunluğu kısıtlamalarına uymak için Jeff Grigg'in form 6 değişken giriş parametrelerini gösterme özgürlüğünü de aldım .

Diğerleri zaten bazı yararlı önerilerde bulundular, özetleyeyim:

• Satır başına 80 karakter 80'lerde altın bir kural olabilir. Günümüzde çoğu insan 100 ila 130 karakterin iyi olduğunu kabul ediyor.
• İfadelerinizin içinde satır aralıkları kullanın.
• Ara sonuçları vererek uzun ifadeleri ayırın.

Başka bir öneri daha eklemek istiyorum: Uzun isimler hakkında dogmatik olmayın! Bir değişkenin kapsamı ne kadar büyük olursa, adına daha fazla bilgi konulması gerekir. Ve genellikle değişkenlerin kapsamını küçük tutmak iyi bir fikirdir.

Örneğin, anahtar kelime şifreleme tablonuzun sütunu için bir değişkeniniz varsa ve değişkeninizin kapsamında yalnızca bu tek bir tablonun kullanıldığı açıksa, bunu çağırmak columnbile iyi olur col. Kapsam daha büyükse ve birden çok tablo varsa, onu çağırmak mantıklıdır keyWordEncryptionTableColumn.

Başka bir örnek: İki veya üç satıra yayılmış bir gövdeye sahip bir döngünüz varsa ve bir dizinin öğelerine erişmek için bir dizin kullanmanız gerekiyorsa, dizini çağırmakla ilgili bir sorun yoktur i. Bu bağlamda, (en azından çoğu insan için) söylenenden çok daha okunabilir arrayIndexOfMyVerySpecialDataSet.

Genelde sana katılıyorum öğretmenim. Ancak, çok büyük bir kod parçasında çok şey kullanacağınız bir değişkeniniz varsa, anlamı hakkında açık olduktan sonra bunun için bir steno form kullanmak daha iyi olabilir. Çok karmaşık aritmetik ifadeler ve ödevleriniz olduğunda, bunlar uzun değişken isimleriyle iyi okumaz.

Anahat hakkında:

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

Bu bir amaca hizmet etmez, sadece çizgi uzunluğunu sınırlamak daha okunabilir hale getirmez. Bunun okunabilir olmasını istiyorsanız, bunu yapın:

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

Ve sonra tür tanımlayıcılarını hizalamak isteyebilirsiniz (int'den sonra bir boşluk ekleyin). Ancak, initalizasyonları veya bunun gibi argüman listelerini ana hatlarıyla belirlerken dikkatli / kısıtlayıcı olun:

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

Sorun, bir adı değiştirdiğinizde veya bir değişken eklediğinizde, güzel görünümü korumak için tüm bloğu yeniden biçimlendirmeniz gerekebilir. Yapacağınız anlamsız değişiklikler kadar iş için değil, bir sürüm kontrol sisteminde korkunç görünecekti. İş arkadaşınız dosyayı değiştirdiğinizi görür ve ne yaptığınızı görmek için önceki sürüme göre farklılık gösterir. Sonra her çizgi değiştikçe aydınlanır, gerçek değişimi gizlerdi. Bu, aslında ne kadar kötü olduğu kullanılan karşılaştırma aracının kalitesine bağlı olacaktır, ancak genel olarak kodu çok kişisel hale getirmek ve / veya bir satırın biçimlendirmesini diğerine bağlı tutmak iyi bir fikir değildir.

Bazen ana hatlar bir amaca hizmet edebilir, neredeyse aynı olan onlarca ardışık satırınız varsa, onları ana hatlarıyla belirtirseniz farklı olduklarını tespit etmek kolay olacaktır.

Bir işyerinin, sürüm kontrol sistemine göndermeden önce kodunuza yaptığınız tüm süslü biçimlendirmeleri ortadan kaldıracak bazı otomatik biçimlendirmelerin olabileceğini unutmayın.

Feragatname: Bu konuyu daha açık hale getirmek için biraz abartıyorum. Bu yüzden herhangi bir mükemmelliği bir tane tane ile alın.

Öğretmeniniz% 100 haklıdır: Artık yaklaşık 80 karakter "altın kural" yoktur (linux kodu yazmıyorsanız, yani). Bu kural, o sırada terminallerin büyüklüğü nedeniyle oluşturuldu, ancak bugünlerde, enditor pencerenizde 150'den fazla karakteri kolayca sıkıştırıyorsunuz. Ve bu sınırı aşsanız bile, editörünüz çizgiyi yumuşak bir şekilde sarar, böylece kaydırmanıza gerek kalmaz. Ve 80 karakterin ötesine geçmemenin tek nedeni kaydırma ihtiyacıydı .

Bununla birlikte, çizgilerinizin süresiz büyümesine izin vermemeye gerçekten ihtiyaç var. Çizgi ne kadar uzun olursa, bir insanın ayrıştırılması o kadar zorlaşır. Ancak kısa değişken isimleri uzun satırlar için çözüm değildir .

Çözüm, daha düzgün adlandırılmış değişkenler ekleyerek ifadelerinizi mantıksal olarak bölmektir . Beyaz alanla akıllı olmaya çalışmayın. Uygun şekilde adlandırılabilecek herhangi bir alt ifadeyi tanımlayın ve bunun için bir değişken oluşturun. Bu, hem değişkeni hesaplayan kodu hem de bu değişkeni kullanan kodu basitleştirir .

Sorunuzun bir parçası değil, ama yine de bu konuda yorum yapmak istiyorum: =Operatörlerinizi dikey olarak hizalamak çok kötü bir fikir .

Bunun üç nedeni vardır:

1. Dikey olarak hizalanmış işleçler içeren bir bloğun düzenlenmesi bir PITA'dır. En büyük değişkenin uzunluğu değiştiğinde (yeniden adlandırma, ekleme, silme), "güzel" düzeninizi tekrar geri almak için bloktaki tüm satırları rötuşlamanız gerekir.

   Tabii ki, bu sorun yetkin bir editör kullanılarak biraz azaltılabilir, bu yüzden küçük sebep budur. Gerçek sebep ikincisidir:

2. Yeniden hizalamanın getirdiği bu sahte beyaz boşluk değişiklikleri, modern sürüm kontrol sistemleriyle iyi oynamıyor git. Gerçek bir çatışmanın olmadığı ve hizalamanın kullanılmaması durumunda hiçbir çatışmanın işaret edilmeyeceği önemli miktarda birleştirme çatışmaları yaratma eğilimindedirler. Bu sahte çatışmaların her biri, hiçbir şey için değerli zamanınıza mal olacak .

3. Hizalama sıfır anlamsal anlam taşır . Bu anlamsız. Hizalama ile daha iyi anlayabileceğiniz hiçbir şey yoktur. Bloğunuzdaki her satırın ne yaptığını anlamak için kendi başına okuması gerekir, yukarıdaki ve aşağıdaki satırlara bağlantı tamamen sözdizimsel niteliktedir.

Hizalama herhangi bir anlamsal anlam taşımadığından, ancak önemli maliyetler ürettiğinden, size daha fazla zaman harcamadan alışkanlığı öğrenmelisiniz.

80 karakter sınırını çok beğendiyseniz, bazı fortran programlamayı deneyin. Doğru, daha yeni standartlar fortran satır sınırını 132 karaktere yükseltti, ancak sınırı aşan herhangi bir programın derlenmesini her zaman sakat bıraktığı gibi geçerli olmaya devam ediyor. Programlama konusunda iyi iseniz, yakında hat uzunluğu sınırı da dahil olmak üzere fortran'dan nefret etmeye geleceksiniz. Bundan sonra, hayatınızın geri kalanında iyileşeceksiniz.

Kendimi profesyonel olarak bazı fortran programlama yapmak zorunda kaldım ve size söylüyorum, bu çizgi uzunluğu sınırından nefret etmeyi öğretti. Derleyici artık doğru şekilde derlemeyeceği için, basit ve okunabilir bir hattı parçalara ayırmaktan daha sinir bozucu bir şey yoktur. Ve kesinlikle tek bir satır olarak ifade edildiğinde en basit olan kod satırları vardır.

Programlama ortamlarındaki sınırlamalar nedeniyle yıllar boyunca birçok stilistik kural (kural değil!) Ortaya çıktı. Delikli kart günlerinde fiziksel bir kaynak satırında görünebilecek karakter sayısı konusunda kesin bir sınırınız vardı (bu yüzden Fortran satır devam karakterleri için 6. sütunu ayırdı). Onlarca yıl önce 80x24 siyah üzerine siyah bir VT220 terminali üzerinde çalışıyordum; Kullandığım editörler satırları 80 karakterle sınırlamazken, yatay kaydırmayı önlemek için elinizden gelenin en iyisini yaptıysanız hayat çok daha kolaydı.

Fortran'ın eski sürümlerinde ('77, IINM'ye kadar), 6 ila 8 karakterden daha uzun tanımlayıcılara bile sahip olamazdınız . 80'lere kadar bile olsa, C sadece harici adlardaki ilk 8 karakterin anlamlı olduğunu garanti ederdi (bu yüzden bazı kütüphane fonksiyonlarının harika açıklayıcı isimleri vardır strpbrk).

Tabii ki, 21. yüzyılda yirmi yılda artık bu sınırlara sahip değiliz. Sebep yok değil daha açıklayıcı tanımlayıcılar kullanmak.

Şey doğru bağlamlarda olduğu, ive jve kvardır mükemmel makul, anlamlı isimler . Bir dizi veya bir döngüde bir vektör üzerinden yineleme ve sadece geçerli öğeyi tanımlamak için bir şey gerekiyorsa, imükemmel iyi çalışıyor. Gibi bir isim kullanmazdım currentElement- bu bağlamda daha anlamlı değil ve sadece görsel karmaşa ekliyor.

Bunu söyledikten sonra, öğretmeniniz sizi her şey için daha uzun, daha açıklayıcı isimler açısından düşünmeye zorlamakta yanlış değil - önce bu alışkanlığa girerseniz ve sonra nerede gerektiği gibi tasarruf edeceğinizi öğrenirseniz hayat sizin için daha kolay olacaktır. Biri olarak oldu 8 karakter veya daha az içine uyum şeyi zorla bir zamanda, daha az fazla bilgi kenarında kesinlikle daha iyi err içelim. Daha fazla deneyim kazandıkça, tanımlayıcı uzunluğunda nereden tasarruf edebileceğinizi ve nerede biraz daha açıklayıcı olmanız gerektiğini öğreneceksiniz.

Bunun c için çalışıp çalışmadığından emin değilim ama formülleri birden çok satıra bölmenin bir yolu var mı? Python için böyle bir şey biliyorum.

Yeni bir satıra + (rowSize * nextWord) + nextWord]) {başlatabileceğinize bakın. (Basın gibi IDE girin ve girintili olup olmadığını görmek böylece C önceki ifade geçerli satırda tamamlandığını biliyorum)