Yerel bir değişkendeki ilk sözcük için küçük harf kullanmanın nedeni nedir (örn. WorkerCount, firstName)

Tüm değişkenlerim için tam uygun kasa kullanmam nedeniyle diğer programcılardan çok eleştiri alıyorum. Örneğin, tipik bir programcı employeeCountdeğişken adı için kullanacak , ama kullanıyorum EmployeeCount. Ben geçersiz bir yöntem, dönüş yöntemi, değişken, özellik veya sabit olsun, her şey için tam uygun kasa kullanın . Javascript'te bile bu sözleşmeyi izliyorum. Bu sonuncusu insanların jimnastiklerini gerçekten hışırtıyor.

Bu "standart dışı" muhafaza kuralına uymamamın tipik nedeni, tam uygun durumun özellikler ve geçersiz yöntemler için ayrılması gerektiğidir. Yerel değişken ve bir değer döndüren yöntemlerin ilk harfi küçük harf olmalıdır int employeeCount = getEmployeeCount().

Ancak nedenini anlamıyorum.

Bunu sorguladığımda, bunun standart olarak keyfi bir cevap aldığı anlaşılıyor . Cevabı ne olursa olsun, genellikle her zaman bu şekilde kaybolur . Sadece takip ediyorum. . Keyfi cevaplar benim için asla yeterince iyi değil.

Excel 97 makrolarını Office IDE ile programlamanın ilk günlerinden beri, bir şeyin yerel bir değişken veya özellik olup olmadığını söylemek için hiçbir zaman bir kasa kuralına ihtiyacım olmadı. Çünkü her zaman çok sezgisel bir adlandırma kuralı kullandım. Örneğin, GetNuggetCount()bir yere giden bir yöntemi açıkça gösterir ve tüm külçelerin sayısını alır. SetNuggetCount(x), külçe sayısına yeni bir değer atamanızı önerir. NuggetCounttek başına bir değeri tutan bir özellik veya yerel değişken önerir. Sonuncusu için, "Ah ha! Bu soru. Mülkiyet veya değişken? HANGİ NEDİR?" Buna, "Gerçekten önemli mi?"

Yani tl; dr ;: Değişken veya dönüş yönteminizdeki ilk sözcük için küçük harf kullanmanın objektif, mantıksal, keyfi olmayan nedenleri nelerdir?

Düzenleme: MainMa için

Bu kodu cevabınızdaki ilk kod örneğiyle değiştirin ve argümanınızın ne kadar iyi olduğunu görün:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var Snapshots = this.LiveMeasurements.IsEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!Snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var MeasurementCount = Measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in Snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Bu adlandırma kuralı, genellikle insanlar bir değişkene türüyle aynı adı vermek istediklerinde kullanılır. Örneğin:

Employee employee;

Hatta bazı diller bu büyük harf kullanımını zorunlu kılar. Gibi can sıkıcı değişken isimleri kullanmak zorunda Bu engeller MyEmployee, CurrentEmployee, EmployeeVarbir şey sadece büyük harf gelen bir türü veya değişken ise, vb Her zaman söyleyebilir. Bu, aşağıdaki durumlarda karışıklığı önler:

employee.function(); // instance method
Employee.function(); // static method

Ayrıca, İngilizce olarak, isimler genellikle büyük harfle yazılmaz, bu nedenle büyük harf kullanımınızın "uygun" olduğunu iddia edemezsiniz.

Peki bunun durumunuzla ne ilgisi var? Açıkçası kendi kodunuzu okumakta zorlanmıyorsunuz, ancak işleri olabildiğince tutarlı tutarak, kodunuzu okuması gereken başka birinin zihinsel iş yükünü azaltmış olursunuz. Yazılı kodlamada, stilinizi okuyuculara uyacak şekilde ayarlarsınız.

Hiç yok. Çoğu insanın yaptığı budur, bu yüzden standart haline gelmiştir çünkü herkes bunu yapar. Bu sözleşmeyi bir çok literatür izliyor, böylece insanlar bu alışkanlığı ediniyor.

Sözleşme, kodun tutarlılığı kadar önemli değildir. Her şeyin tutarlı bir şekilde adlandırılması şartıyla, onlara bakmaktan ne olduğunu anlayabilmem için, ilk harfin büyük harfle yazılmış olup olmaması önemli değildir.

Ben senin şekilde yazılmış kod rastlamak sarsıcı bulurdum ve ben hoşlanmadığını söyleyebilirim. Ama bu bir stil meselesi.

Şimdi bunu işyerinde yapıyorsanız, takımın tarzında kod yazmak daha iyi olur, böylece kod her yerde tutarlı kalır. Kodunuzun herkesten farklı olması yerine.

http://thecodelesscode.com/case/94

1. Standart neden var?

Sonuçta, herkesin kişisel tercihe göre kodu yazmasına izin vermek ve hangi standardın daha iyi olduğu hakkında konuşmayı bırakmak daha iyi olmaz mı?

Gerçek şu ki, bir stile alıştığınızda, farklı bir stil kullanan kodu okumak daha zordur. Beyniniz, kodun ne yaptığını anlamak yerine, sözleşmeyi (varsa) anlamaya çalışmak için daha fazla zaman harcar.

Bu iki kod parçası arasında daha okunabilir olan nedir?

public void comp_metrics ()
{
  int Count;
  List<snapshot> measurements=fromMemoryStorage();
  if (_liveMeasurements.enabled)
    measurements = GrabSnapshots(20, _cache);
    if( !measurements.Any() ) {
        this.Report(LogMessage.Measurements_Are_Empty); return;
    }

    Count = measurements.Count ();

    this.Chart.initialize(( Count + 1 )*2);

    foreach(snapshot S in measurements) {
      this.Chart.append_Snapshot ( S );
    }
}

veya:

public void ComputeMetrics()
{
    const int MaxSnapshots = 20;

    var snapshots = this.liveMeasurements.isEnabled ?
        this.GrabSnapshots(MaxSnapshots, this.cache) :
        this.LoadFromMemoryStorage();

    if (!snapshots.Any())
    {
        this.Report(LogMessage.SnapshotsAreEmpty);
        return;
    }

    var count = measurements.Count();
    this.Chart.Initialize((count + 1) * 2);

    foreach (var s in snapshots)
    {
        this.Chart.AppendSnapshot(s);
    }
}

Her iki kod parçası da benzer şekilde çalışır. Tek fark, ilk durumda, proje üzerinde çalışan her geliştiricinin kendi stilini kullanmasıdır. Bu, kodu tutarsız, okunamaz ve tehlikeli hale getirdi. Her sonrasında ekibinin üyeleri bunlardan biri kıvırcık parantez reddederek gerçeği ile birleştiğinde girinti boyutu, yaklaşık anlaşma sağlayamaması gerçeği ifkodu son derece yatkın hata yaptı: bakarak, ikinci inanıyoruz olabilir ifolduğunu sadece ilk ifdoğru olduğunda yürütülür , ki durum böyle değildir.

İkinci durumda, tüm geliştiriciler aynı standardı izledi. Bazıları belki de mutsuzdu, çünkü iki boşluk girintisini tercih ettiler ya da küçük bir harfle başlayan yöntemlere kullanıldılar. Gerçek şu ki, kod hala bu şekilde daha okunabilir ve farklı bir standart kullanıyor olsalardı.

Sıkı, tekdüze bir standarda sahip olmak, kodun okunmasını kolaylaştırır.

2. Neden kendi standart daha iyi olandan olduğunu ben şu anda icat etti?

Bir standart dünya çapında yüz binlerce geliştirici tarafından kullanılıyorsa, sadece buna uyun. Kendinizinkini icat etmeyin: Daha iyi olsa bile, yüz binlerce geliştiricinin sizinkini kullanmaya başlamaktan ziyade küresel standarda geçmeniz daha kolaydır.

Örnek: kendi şirketimde, veritabanındaki birincil ve yabancı anahtarları ve dizinleri adlandırmak için özel bir kuralım var. Bu isimler şöyle görünür:

• [FK for Application: CreatedByApplicationId],
• [IX for SessionIPAddress: SessionId] veya
• [PK for RoleOfPassword: RoleId, PasswordId].

Şahsen, bu sözleşmeyi mükemmel ve son derece açık buluyorum. Benim için. Ama tamamen berbat. Berbat, çünkü benim ve binlerce veritabanı yöneticisinden hiç kimse bunu kullanmadı. Bunun anlamı şudur ki:

• Bir DBA kiralayacağım zaman, şu anda çalışmalarına başlamak yerine yeni sözleşmeyi öğrenmek zorunda kalacak,

• İnternette kod parçalarını olduğu gibi paylaşamıyorum: bu garip görünümlü isimler kodumu okuyacak insanları bozacak,

• Kendi başıma kullanmak için dışarıdan kod alırsam, üniforma yapmak için isimleri değiştirmek zorunda kalırdım,

• Bir gün iyi bilinen bir standart kullanmaya karar verirsem, birkaç yüz ismin her birini değiştirmeye zorlanacağım.

3. Peki ya büyük harf kullanımı?

Özellikler, alanlara veya yerel değişkenlere göre daha geniş bir kapsama veya görünüme sahiptir. Özelliklerin büyük harfle başlaması, alanlar ve değişkenler - küçük bir harfle bu yönde gider.

C # düşünürseniz, bu mantık yeterince tutarlıdır.

Java'yı düşünürseniz, yöntemler mantığa uymayan küçük harflerle başlar.

Yani hayır, bu sözleşmenin sizinkinden daha iyi olduğuna dair kesin bir kanıt yoktur. Sadece küresel olarak kullanılır ve sizinki kullanılmaz. Hiçbiri daha iyi değil .

JavaScript'te, işlevler kendilerinden newönce bir tane gerektirmedikçe küçük bir harfle başlar . Diğer yoldan daha iyi olmaz mıydı? Olabilir. Gerçek şu ki, JavaScript geliştiricileri yıllardır bu standardı kullandılar, aksine değil. Her kitabı yeniden yaz ve her geliştiriciyi şimdi stili değiştirmeye zorla biraz karmaşık olur.

Teknik olarak, önemli değil (veya en azından çoğu dilde önemli değil).

Bununla birlikte, çoğu programlama topluluğu (ister belirli bir dil etrafında oluşturulmuş dünya çapında topluluklar, ister bu tür toplulukların alt grupları, bazı popüler kütüphane veya araç takımı etrafında oluşan gruplar veya sadece bireysel ekipler olsun) yerleşik kodlama standartları geliştirmiştir. (Birçok durumda, iyi bir argüman onlar için yapılabilir rağmen) tam ayrıntılar ne nispeten önemsizdir olduğunu önemli onlara sopa olmasıdır.

En iyisi oldukları için değil, herkesin kullandığı şeyler olduğu için; standarda bağlı kalırsanız, kodunuz sonunda kullanacağınız diğer kodların çoğuyla tutarlı olacaktır - kütüphaneler, takım arkadaşlarının kodu, dil yerleşikleri. Tutarlı adlandırma güçlü bir üretkenlik silahıdır, çünkü bir şeyin adını tahmin ettiğinizde genellikle doğru tahmin edeceğiniz anlamına gelir. Öyle mi file.SaveTo(), File.saveTo(), file.save_to(),FILE.save_to() ? Adlandırma kuralı size söyleyecektir.

Kişisel tercihlerinizi karşılaştığınız her dile taşımak özellikle tehlikelidir, çünkü her şeyden önce her dilin kendi kültürü vardır ve adlandırma kuralları çoğu zaman uyumsuzdur; ikincisi ise, isimlendirme konusunda diller arasında birçok ince fark vardır.

Sadece bir örnek: C # 'da, türler ve değişkenler ayrı ad alanlarında yaşar; derleyici farkı bilecek kadar zekidir. Ancak C'de her iki ad da bir ad alanını paylaşır, böylece aynı kapsamda bir tür ve aynı adda bir değişkene sahip olamazsınız. Bu nedenle, C, türleri değişkenlerden ayıran bir adlandırma kuralına ihtiyaç duyarken, C # gerekmez.

Kimsenin bunu söylemediğine şaşırdım, ancak büyük harf farkının bir nedenden dolayı inanılmaz derecede yararlı olduğunu düşünüyorum: Bir değişkenin sadece yerel olarak kapsamda olup olmadığını bilmek güzel ve kullanışlı. Değişken yerel ise, adın yeniden düzenlenmesi gibi, değiştirmenin yan etkileri hakkında endişelenmeyin. Bu yüzden sınıf üyelerini özel sınıf değişkenlerine karşı yerel değişkenlere ayıran bir sözleşmeyi seviyorum.

Modern Intellisense ile, bu gittikçe daha az önemlidir, ancak tanımı nerede bulmam gerektiğini bilmek için kodu okurken hala bazı yerler veriyor.

Ve bunun adil bir kısmı, yıllar önce, yöntemlerin bir ekrana sığması muhtemel olmadığında, daha kötü tarzımdan çıkarılabilir.

Bu, sizin özel sözleşmenizden ziyade bir sözleşmeler meselesi gibi görünüyor.

Kırdığınız her kongre için, sadece herkes için daha fazla iş ekliyorsunuz. Belki de mükemmel bir dünyada, tüm şirket hayatları boyunca tek bir ürün üzerinde çalışır ... ancak gerçekte bu doğru değildir. İnsanlar projeler arasında, bazen şirketler arasında ve hatta eğlence için atlarlar. Kod ne kadar rasgele olursa, üzerinde çalışmak o kadar zor ve pahalıdır. Bir işletme sahibi veya paydaş olarak, projenin iyiliği için değil bencilce düşünen geliştiricileri işe almak istemem.

Bu profesyonellikten kaynaklanıyor: bazen kişisel stillerimizi bir kenara koymamız ve kitlesel olarak benimsenmesi için daha verimli olan şeylere gitmemiz gerekiyor. Bu, işbirliğini teşvik eder ve ilk etapta orada olmaması gereken gereksiz engelleri kaldırır.

Gerçek kuralınıza gelince, CapitalCamelCase genellikle sınıf adları (veya Javascript, yapıcıları) için ayrılmıştır. Büyük harfli bir değişken görürsem, eğitimli bir tahmin bunu kullanmak için onu başlatmam gerekeceğini söyler. Bu yanlışsa, kodun topluluk standartlarına uymadığı için sinirleneceğim. Diğer birçok dilde bile, ilk kez ona bakan herkes anında yanıltılmaktadır. Kodun açık olmasını istiyorum, yanıltıcı değil.

"çünkü tam uygun durum özellikler ve geçersiz yöntemler için ayrılmalıdır. Bir değer döndüren yerel değişken ve yöntemler küçük harfle ilk kelimeyi içermelidir" ve standart kural olduğu için.

Diğer programcılar şu anda kodunuzu alıyor ve bunun bir özellik olduğunu ve gerçekten yerel bir değişken olduğunu düşünüyorlar, işinizi zorlaştırıyorsunuz.

Diğerlerinin söyledikleri gibi, bir adlandırma sözleşmesi pat hariç başka bir gerçek nedeni. Ekibinizin tamamını aynı sayfaya götürebilirseniz, muhtemelen biraz zaman kazanabilirsiniz. Örneğin kişisel olarak buna giren bir kodlama standardı şeyine başladım ve tüm özel varyasyonlar için camelCase'i veVal tarafından iletilen şeyleri kullandık, oysa kamuya açık şeyler ve Ref tarafından iletilen şeyler için PascalCase'i kullandık.

Korumalı veya Dışarı gibi bir şeyle uğraşırken çizgiler biraz bulanıklaşır.

Dil (biçimsel yönü ve geleneksel olanı ile) düşüncelerinizi düzenlemek için önemlidir, düşünme biçimleriniz üzerinde güce sahiptir. Yani bir tarzdan diğerine geçmek sadece bir acı.

Küçük harf ve büyük harf sembollerinin Haskell'de büyük anlamsal farklılıkları vardır, ayrıca Scala'da hafif farklılıklar gösterir ve her ikisini de kullandım. Kullandığım diğer diller, bu iki tür tanımlayıcı arasında hiçbir fark yaratmaz, ancak Haskell'in tanımlayıcıları algılama biçimini benim için farklı diller için zihnimi parçalamaktan çok daha kolay.

Benim için bu beklentidir.

Çoğu kodu okuduğumda, ben ile başlayan bir şey lowerCaseyerel bir değişken veya bir işlev (C # sadece bir değişken olurdu) olmasını bekliyoruz. Yerel bir değişken görürsemProperCaseİçinde , bir sınıf adı ya da bir özellik ya da başka bir şey olduğunu düşünerek bir süreliğine yanılıp karışırdım. Bu, kodu tekrar okumama neden olur ve beni rahatsız eder.

Muhtemelen sizin durumunuzda olan budur.

Ayrıca, bir değişkenin sadece ilk harfe bakarak hangi rolü oynadığını söyleyebilir ve bir örnek adı ile sınıf adı arasındaki çakışmaları önler.

Yazma kolaylığı için yerel değişkenler için küçük harf kullanılmalıdır (hız değiştirme / vites değiştirme tuşu yok). Büyük harf, bir ad içindeki sözcükleri ayırarak okunabilirliğe yardımcı olmak için kullanılır. Tek kelimelik yerel değişken adlarına sahip kodlar (ortak olması gerekir) hızlı ve kolay yazılır. Addaki her yeni sözcük için büyük harf kullanımı, başka bir karakter ekleyen alt çizgi kullanmaktan daha hızlıdır (ve daha az boşluktur) - buna deve-kasası da denir.

Burada OP'ye katılıyorum. camelCase yanlış görünüyor. Bunun standart olduğu gerçeğine de katılıyorum ve aynı standarda bağlı kalmalıyız veya bir standarda sahip olmanın anlamı nedir. Ayrıca PascalCaps'in yöntemler vb. İçin, kamelCase ise kendi değişkenleriniz için vb. Yöntemleri sizin için renklendiren bir IDE kullanmadığınızda farklılaştırmanın bir yolu olarak kullanılması mantıklıdır.

Etrafında dolaşmak için, her zaman nesnemin adlarını olduğu nesne türünün önüne eklerim. Yani bir dize değişkeni ise strMyVariable diyorum. Nesne bir tür ise objMyObject, vb. Diyorum. Bu şekilde standartlara göre küçük büyük harflerle başlar ve doğru görünür.