Kelime hem isim hem de fiil olduğunda bir değişkeni isimlendirmek


48

Genel rehberlikle bir köşe problemiyle karşılaştım:

  • değişkenler için isimler
  • fonksiyonlar için fiiller

Özellikle, kelimenin belirsiz olduğu bir durum var - bu bir fiil veya bir isim olabilir. Bazı durumlarda, uygulamayı tartışırken , aynı cümleyle her iki şekilde de kullanılacaktır .

Niyetim, aylar sonra kod bölümlerine döndüğümde programın gelecekteki geliştiricilerin yanı sıra kendim için okunabilir kalmasını sağlamak.

Örneklerden biri a battery. Bir batterybir sahiptir chargeve şunları da yapabilirsiniz charge()pil.

Ben her ikisine birden sahip olduğunu düşünüyorum Battery.Chargeve Battery.Charge(value)gelecek geliştiricilerine kafa karıştırıcı olacaktır.

Şu andaki çözümüm bu davaların biri veya her ikisi için (değişken ve fonksiyon) basitçe farklı bir kelime seçmek. Bu yaklaşımla ilgili sorunum, Batterynesnenin değişkeni ve işlevidir ve chargebununla ilgili tasarım tartışmalarına uymayacaktır Battery.

Benim sorum, adlandırma sözleşmesinde bu çatışmanın üstesinden gelmek için başka / daha iyi bir yol mu var?


Konuyla ilgili bazı ek okumalar. Hiçbiri sorumun özelini ele almadı.


3
şarj fonksiyonu addCharge yeterince kolay ve net yapmak
cırcır ucube

2
İsim değişkenini "Current-" ile ön ekler misiniz? Yani "CurrentCharge" vs "Charge ()"?
Brian Snow

6
ya da sadece ChargeLevel mevcut ücret almak için
cırcır ucube

5
Bir kelime hazırla. WordNet enqueuebir kelime olduğunu düşünmüyor , ancak Java'da bir fiil. Ne dersiniz doCharge? Yine de simetri testinde başarısız olacak çünkü diğer yöntemleriniz bu ön
eke

5
"Geçerli" = şimdi veya "geçerli" = ücret akışı. Tek gerçek çözüm İngilizce'yi daha mantıklı bir dille değiştirmek!
DarenW

Yanıtlar:


38

Benzer durumlarda eş anlamlı bulmaya çalışıyorum. Bu durumda fiil için "şarj" kullanırım. "Yeniden" biraz gereksizdir, ancak anlamı açıktır. Pilde kalan şarj için basit "şarj" kullanımı, herhangi bir fiziksel birim belirtmediği için belirsizdir. "AvailableAmpHours", "hoursUntilRecharge" veya benzer bir şeyi tercih ederim. Üniteler, uygulama için uygun olana bağlı olacaktır.

Kişisel tercihim, fiilleri yalnızca durumu değiştiren işlevler için kullanmaktır. Değişmeyen fonksiyonlar için isimler kullanırım. Sanırım sizin bakış açınıza bağlı. Makine düzeyinde, mutasyona uğramayan işlevler bir şey yapar, ancak model düzeyinde, yapmazlar.


2
Birimler üzerinde mükemmel nokta. Bu durumda birimler açıkça bırakılır, çünkü çalıştırdığımız analize bağlı olarak değişebilirler. Başka bir deyişle, farklı zaman ölçekleri kullanıyoruz ve Pil çalışmalarını analiz ölçeğine göre ayarlar.

1
Pahalı, mutasyona uğramayan işlevler için fiilleri tercih ederim. Örneğin, bir veritabanında bir sorgu çalıştıran işlevler.
Brian

20

Sadece bunu dışarıya atmak, ama belki de bu adlandırma belirsizliği örneği için çözüm, bu işlevi pilden tamamen çıkarmaktır. Kendimi şarj eden bir batarya hiç görmedim ve bu bir BatteryCharger sınıfına sahip olmak benim için daha anlamlı olurdu. Bu, endişelerinizin daha ayrık kalmasına ve eylemin daha açık olmasına yardımcı olacaktır.

battery.Charge(50) vs batteryCharger.Charge(battery, 50)

Bana göre, ikinci form çok daha anlaşılır ve tüm "Şarj" kodunuzu tüm akü sınıflarınızda dağıtmak yerine tek bir yerde tutuyor.


6
Kötü bir düşünce değil, ancak bu durumda Batterypil + şarj sistemi için bir soyutlamadır. Bizim uygulama iki yönü ayrı nesnelere bölmeyi gerektirmez, bu yüzden Batterykolaylık sağlamak için bir (aka ) olarak yuvarlanırlar . Sonuçta, bir şarj edilebilir pilin fiziği, şarjı kabul etmek için bir çeşit işleve sahip olduğunu belirtir.

Bu durumda, Kevin Cline'in cevabını aradığınızı söylüyorum. Netlik açısından, mutasyon işlevleri için Şarj Et ve Deşarj'ı ve özellik adı için Şarj'ı kullanırdım. Belki de ChargePercent de iyi olabilir.
mortalapeman

Belki bir Java programcısı mısın? Bu açıkça Kendini Tekrar Etme ihlalidir. Aslında, "50" parametresi dışında HERŞEYİ tekrarlıyorsunuz. Eğer deneseydim, daha kötü bir DRY ihlali örneği bulamadım.
kutulu

@ boxed Benim örneğimi alıyor musunuz? Çünkü hiçbir uygulamam olmadığında DRY'yi ihlal ettiğimi nasıl iddia edebileceğinizi bilemiyorum. SOLID ilkelerinin büyük bir savunucusuyum ve bu sonuca nasıl geldiğinizi göremiyorum.
mortalapeman

Bir şekilde Pilde durum değişikliğine neden olacak gereksiz bir BatteryCharger sınıfı oluşturarak DRY'yi ihlal ediyorsunuz. Böylece, BatteryCharger bir an önce kabul görecek ve ardından hemen Pili açacaktır.
kevin cline

9

Çift Anlamdan Kaçının

Kasten bir anlamı birden fazla olan bir kelime seçtiniz ve ilk karar sorun. Programcılar için sorunlu olan bir sürü kelime var. Başka bir örnek olacaktır phone. Birini yapabilirsin phoneya da phonecebinde bir tane olabilir .

Alıcıları ve Ayarlayıcıları Kullan

Çoğu nesne için standart adlandırma, özelliklerin alıcıları / ayarları yöntemleridir.

Battery.Charge            // would be a property
Battery.setCharge(value)  // would set the property
Battery.getCharge()       // would get the property

Mülkler İsim Değil Durumlardır

Bence nesne özelliklerini isimler olarak sınıflandırarak yanılıyorsunuz ve değişkenler de durumları düşünebilir. Yerel varlıklarının yerel kapsamı ile ilgili devletlerdir.

Bir isim olarak sahip oldukları değeri tanımlayabilirsiniz, ancak bunun her durumda doğru olduğundan emin değilim.

OOP'de terminoloji nesne özellikleri o nesnenin durumunu tanımlar. Senin durumunda bu Batterybir nesne ve Chargebir durum. Bu, nesnenin bir özelliği olacaktır, ancak bu, nasıl kullanıldığı bağlamına bağlıdır.

ChargeBataryaya ihtiyacınız varsa ve bunun ne olduğunu bilmeniz gerekiyorsa Charge, o zaman bir sorununuz olur.

Bağlam Uygulamak için Kapsam Kullanma

Bağlam, bir sözcüğün hangi anlamını iletmek istediğiniz bir yöntem veya özellik düşündüğünüzü açıklığa kavuşturmaktır. Kapsam bir özelliğin / yöntemin erişilebilirliğini nesnenin dışından ayarlıyor.

Batter._charge            // a hidden private property
Battery.setCharge(value)  // would set the private property
Battery.getCharge()       // would get the private property
Battery.Charge()          // would perform the Charge action

Yöntemler Fiillerdir

Bir nesnenin yöntemini bir fiil olarak tanımlayabilirsiniz, ancak eylem kelimesi daha uygundur. OOP terminolojisinde nesnelere yöntemlerini kullanarak eylemler gerçekleştirirsiniz. Bir nesnenin özelliğini nesnenin dışından değiştirmek kötü bir formdur. Durumunun değişmesine neden olan gerekli işlemleri yapan bir yöntem aramak tercih edilir.

Kelime Chargebir fiildir, ama aynı zamanda bir isimdir. Bir eylemin yöntemini çağırmak için kullanıldığında fiilin kullanılmakta olduğu anlaşılır hale gelir Battery.Charge(....).

Ancak, bağlam çok önemlidir. Kelime Charge()bir fiil olsa da, bu kadar anlamlı değildir startCharging().

İçin geçerli yöntemler Batteryiçerebilir Charging, Discharging, setCharge, getCharge, hasCharge, Dischargeve Charged.

Basit bir tek kelime yöntemi genellikle eylemlerini açıkça açıkça ifade etmemektedir, ancak bunun gibi openve closeçok az açıklamanın gerekli olduğu bazı durumlar vardır .

Bu nedenle, bu tür özellik / yöntemlerin nasıl adlandırılacağına dair doğru bir cevap yoktur. Bunun dışında, karışıklık olmamasını sağlamak için yukarıdaki teknikleri akıllıca kullanmanız gerekir.


2
Kayıt için, belirsiz terminolojiyi kullanan müşteridir. Bu karışıklığı ben yaratmadım. :-) Böyle bir duruma giren tek kişi olamayacağımı düşündüğümden soruyu gündeme getirdim. Cevabınızda bazı geçerli noktalar var. Bu özel durumda, o zaman StartCharge()ve EndCharge()ima edeceğiniz zamanın küçüklüğünde çalışmıyoruz . Aslında, bu terminoloji batarya sistemini kullanmaya önemli bir ek yük getirecektir. Her aralıkta Charge()veya olabilir Discharge().

1
Birincil mücadele, iç programlama anlamını müşterinin kullandığı terminoloji ile senkronize etmektir. Chargebu etki alanı için en kolay anlaşılır belirsiz kelimedir. Birkaç tane daha var.

6

Onlara bir fiil ya da bir isim yapacak fiillere dayan.

Battery.doCharge()

Battery.getCharge()

4

Fiil davası için bence Chargetamam. İsim davası getCurrentChargeLeveliçin sizin için çalışır mı?


Bundan emin değilim. C # kullandığımızdan, ayrı fonksiyonlara ihtiyaç duymak yerine, özelliği aldıklarını belirledik. Buna bakılmaksızın, ne yazdığımı unuttuğumda bakım ve nasıl görüneceği konusunda endişeliyim. Olmaz getCurrentChargeLevel()hala bir iç değişken başvurmak gerekir Batteryve bu değişkenin adı ne olurdu?

gerilim veya yüzde nedir?
mhoran_psprep

1
@ GlenH7: Ah, anlıyorum. C # belirtmediniz ve beynim Java modunda. Her iki durumda da, şu anda bataryadaki şarj miktarını temsil eden isim için, çizgileri boyunca bir şeyin Battery.currentChargeLevelişe yarayabileceğini düşünüyorum. Kullanmayı deneyebilirsin Battery.coloumbsveya Battery.ampereHoursbu kadar açık olmayabilir ...
FrustratedWithFormsDesigner

1
@mhoran_psprep - ikisi de değil. ;-) Chargeolan Energyolan Power(Volt * Amper == Watt) süresi ile çarpılır. Yani bu durumda, ücret bir sayıdır. Yüzde olan bir şarj durumu da var.

@FrustratedWithFormsDesigner - evet, daha geniş köşe kılıfının dilden bağımsız olarak uygulanabileceğini düşündüğümden C # 'yı bıraktım. Watt*timekesinlikle tasarım konuşmalarıyla aynı hizaya ChargeLevelgelmezdim ama olurdum.

0

Çoğu durumda, yardım fiili, zarf veya sıfat eklenmesi, onları ayırt etmek için yeterince iyidir ve aslında anlamada yardımcı olabilir. Bir batarya üzerinde Charge and Charge () olması durumunda DeltaCharge (), bunun şarj etme veya boşaltma yapabilecek bir işlev olduğunu gösterebilir.

Delta (bir değişikliğin fakat belirsizliğin olduğu durumlarda), devlette değişiklik yapmak için her zaman başkalarına önerdiğim ve önerdiğim bir değiştiricidir (fiil yarı belirgin olsa bile).


0

Kurtarmaya Macar Notasyonu. Sen olabilir intChargeve fcnCharge(value)böylece karışıklığı önlemek ve üç harf sadece para cezası çalışacaktır zaman çılgın uzun adını ekleyerek değil.

Ya da sadece aynı ismi kullanabilir ve IDE'nin bunu yönetmesine izin verebilirsin. Daha uzun veya farklı bir ad oluşturmak, yine de uzun vadede kafa karıştırıcı olabilir.


Cevap üzerine benzersiz bir bakış açısı için +1. Maalesef, Macar gösterimi, kod stili yönergelerimize göre açıkça belirtilmiştir. Bu, cevabınızın potansiyel değerini değiştirmez, sadece gerçek çözümüm olarak kullanamam.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.