Değişken adları web sitelerinin performansını etkiler mi?


10

Değişken adları web sitesi performansını etkiler mi? Bunun çok düşük bir sayı olacağını biliyorum, ama yine de herhangi biri performans açısından uzun bir değişken adı seçmemenin nedenlerini sağlayabilir mi?


2
Lütfen sorunuzu netleştirin - bu değişken nerede ve hangi dilde yazılıyor?
Luke Graham

16
Eğer akıl yürütmeniz (şüpheli) performans ise ASLA kısa ve mantıksız değişken isimleri seçmemelisiniz. Kaynak kodu, bilgisayarları ve mikroskopik performans kazançlarını tatmin etmek için değil, başkalarının okuması için vardır.
Michael JV

PHP kullanıyorum ..
Avinash

2
... Ve xpertdeveloper.com sahibi misiniz?
Jim G.

3
Merhaba Avinash, sorunuzun bunun böyle olabileceğini düşünme gerekçenizi açıklayabilir misiniz?

Yanıtlar:


17

herhangi biri performans açısından uzun değişkenli bir isim seçmemenin nedenlerini sağlayabilir mi?

Michael cevabı ele aldı (yani Hayır), ancak değişken adları programcı performansını etkiler . Yeni bir geliştirici veya kodu bilmeyen bir kişi getirirseniz, uzun ve / veya kafa karıştırıcı değişken adlarına sahip olmak dikkat dağıtıcı olabilir ve anlama sürecini yavaşlatabilir.

Genel olarak, okunması daha kolay olduğu için kısa, açıklayıcı değişken adları kullanmak istersiniz. Kodunuzu 10 yıl boyunca görmezden gelmeniz ve ardından her şeyi tekrar anlamanız gerektiğini düşünün. "GetInput" veya "getInputFromUserWhoInputsStringOrElseInformReaderOfError" yazmayı mı tercih edersiniz? (elbette abartı: P)

Bununla birlikte, biraz daha uzun bir isme sahip olmanın yararlı olabileceği zamanlar vardır. Örneğin, getBirthdayInput () yöntemi, getInput () yönteminden çok daha açıklayıcı olacaktır. Bir noktaya sadeleştirmek istiyorsunuz, ancak aşırı basitleştirme de sorunlu olabilir.


6
uzun isimleri okumak için daha iyidir, eğer "getInputFromUserWhoInputsStringOrElseInformReaderOfError" bulursanız, "getInput" ifadesini bulursanız, bu fonksiyonun ne olduğunu belgelemeniz gerekmez. Ve 10 yıl sonra dokümantasyon yanlış veya eksik veya eksik olacaktır. getInputFromUserWhoInputsStringOrElseInformReaderOfError kesinlikle uzun, ama ne kadar uzun olduğunu anlamak daha iyidir (ve kadınların boyutun önemli olmadığını söylemesi umurumda değil).
Dainius

Bu davaya katılmıyorum. Sadece kodu okuyarak özellikle "geçersiz giriş" veya hemen ardından bir şey yazdırırsa, getInput () ne yaptığını anlamak oldukça kolay olacağını düşünüyorum. Kesinlikle daha uzun bir adın daha iyi olabileceği zamanlar vardır - bunu düzenleyeceğim!
BlackJack

ofc içeriğe bağlıdır, ancak benim deneyimime göre daha uzun isim daha iyidir (ancak getInputFromUserWhoInputsStringOrElseInformReaderOfError olduğu sürece). Ve file.read () dosyası file.readAllFileAsByteArray () 'dan daha hızlı olduğu için bağlam gerçekten önemlidir. Ama dediğim gibi genellikle IMHO uzun ismi daha fazla bilgi sağlar.
Dainius

1
Dokümantasyon yanlış, eksik veya eksikse, kod tabanı yine de mahkumdur.
Christopher Mahan

2
Bu sorulmamış bir soruyu cevaplıyor.

16

Hayır, olmayacak. Genel olarak, kod derlendiğinde, değişken isimlerinin yerine geçtikleri bellek adresi geçer. Bilgisayarlar değişken isimleri hakkında hiçbir şey bilmez; sadece değerlerin nerede saklandığını bilmek isterler.

Değişkenler sembollerdir, başka bir şey değildir. Onaltılık değerleri adlarla değiştirirler, böylece programcılar ne yaptıklarını anlamak için daha kolay bir zamana sahip olurlar. Bu nedenle, daha kısa değişken adları seçerek performans artışı olmayacaktır.

Bununla birlikte, derleme sürelerinde ve JIT ilk yorumunda minik (ve mikroskobik konuşuyorum) iyileştirmeler alabilirsiniz, ancak bunun nedeni, ayrıştırıcının değişken adını okumak için birkaç CPU döngüsünün daha az zaman almasıdır. Bu bir kerelik bir maliyettir ve performans konusunda endişelenirken istatistiksel olarak önemsizdir.


11
Cevabınız uygulama programlaması için doğru olsa da, OP Web Sitelerine atıfta bulunmaktadır ve bu nedenle yorumlanmış bir dil kullanma şansı vardır. Böyle bir durumda, kodun dosyadan okunması ve yorumlanması gerekir. Bu durumda, daha uzun bir değişken adının yüklenmesi ve ayrıştırılması daha uzun sürer. Bununla birlikte, performans kazancı önemsiz olacak ve programcıya kodu okuma ve anlama konusundaki ekstra güçlükle büyük ölçüde dengelenecektir.
Gavin Coates

1
@Gavin Bu, yorumlanan diller için de geçerlidir - "JIT ilk yorumlama". Yorumlanan çoğu dil, satır satır yürütme yerine, AFAIK yerine yürütüldükçe derlenmektedir.
Michael K

1
Michael - derlemek için, önce dosyanın belleğe okunması gerekir. Bu işlem dosyanın uzunluğuna bağlı olarak daha uzun sürer. Daha uzun değişken adları = daha uzun dosyalar.
Gavin Coates

Soru PHP olarak etiketlendi. PHP'nin henüz JIT'si yok - bu, bu yılın sonlarında planlanan 8.0 sürümünün yeni bir özelliği olacak. Yürütmeden önce bayt kodunu derler ve bayt kodu genellikle birden çok istekte kullanılmak üzere web sunucularında önbelleğe alınır.
bdsl

8

Op-kod önbelleği ("PHP hızlandırıcıları" olarak da bilinir) kullanmıyorsanız , gerçekten bir etkisi vardır. Ancak bu etki o kadar düşük ki ihmal edilebilir. Op-kodu önbelleğini kullanırsanız, sıfır etki olur.


1
ve performansı o kadar çok önemsiyorsanız, değişken adlarını birkaç döngü elde etmek için kısaltmayı düşünürseniz, op-kod önbelleği kullanmamak suçlu olur ... ve C gibi derlenmiş bir dile geçmeniz önerilir.
SF.

Ama açıkçası bu etki biriktiricidir, dolayısıyla uygulama ne kadar büyük olursa, etki de o kadar büyük olur, değil mi?
n00dles

Zend Opcache birkaç yıldır PHP ile birlikte gönderildi, bu yüzden herkes onu kullanıyor olmalı. Genelde varsayılan olarak etkin olduğunu düşünüyorum.
bdsl

3

Michael, uygulama programlaması için doğru olsa da, sorunuz, yorumlanmış bir dil olan PHP ile web geliştirmeye atıfta bulunuyor. Böyle bir durumda, kodun dosyadan okunması ve yorumlanması gerekir. Bu durumda, daha uzun bir değişken adının yüklenmesi ve ayrıştırılması daha uzun sürer.

Bununla birlikte, performansın vurulması önemsiz olacak ve muhtemelen tüm komut dosyası için milisaniyenin kesirleri bölgesinde olacaktır. Her zaman örnek bir komut dosyasıyla deneyebilir ve http://www.developerfusion.com/code/2058/determine-execution-time-in-php/ adresinde açıklanan gibi bir zamanlama yöntemi kullanabilirsiniz, ancak bu muhtemelen zamanlama, dosya okunduktan sonraya kadar başlatır. Ayrıca, yeniden denemeler arasındaki yürütme süresi, değişken ad uzunlukları arasındaki farktan çok daha fazla değişir, bu nedenle önemli sayıda yeniden deneme gerçekleştirmeniz ve yapabilmeniz için her birinin ortalamasını almanız gerekir. uzaktan anlamlı bir ortalama elde etmek.

BlackJack'in işaret ettiği gibi, daha uzun isimlerin anlaşılması çok daha zor olabilir ve yazmak için çok fazla çaba sarf edebilir (ve yazım hatalarına daha yatkındır). Küçük bir performans artışı olsa da, bu programcı için yaratılan ekstra güçlüğü haklı çıkarmaz. Bu nedenle kısa, özlü ve anlaşılması kolay değişken isimleri tercih edilir.

Kısacası, değişken uzunluk adı hakkında endişelenmeyin, bunun yerine temiz ve anlamlı bir kod yazmaya odaklanın.


1

Belki :

Sunucu kodu genellikle derlenir ve değişken adı uzunluğu belirtilen nedenlerle bu kodu etkilemez. Ancak, değişken adı biçimlendirme oluşturmak için kullanılırsa çeşitli dize işlemleri. HTTP yanıtı (biçimlendirme / döndürülen json / döndürülen verileri içeren) daha büyük olduğundan, fark göz ardı edilebilir olsa da, biraz daha uzun sürer . JavaScript küçültülmezse, istemciye gitmesi daha uzun süren daha büyük bir dosya olacaktır.

JavaScript dosyalarını küçültmek dışında, bir web uygulaması / web sitesi için yapılan tüm optimizasyon çabaları diğer yönlere daha iyi harcanacaktır.


1

Evet, olacak, ama düşündüğünüz anlamda değil.

Kötü değişken adları ile, geliştiriciler kaynak kodunda kolayca karışırlar. Okumak ve anlamak zor olacak.

Sonunda, kaynak kodun bakımı zor olacak ve gelişmesini sağlamak neredeyse imkansız olacaktır. Bu kaçınılmaz olarak daha yüksek bakım maliyetleri, daha yüksek geliştirme maliyetleri, daha fazla hata ve daha düşük performansa yol açacaktır .

Değişken adının çalışma zamanında kesinlikle hiçbir etkisi olmaz ve derleme zamanında tamamen göz ardı edilebilir. Ancak kötü isimler kaçınılmaz olarak kötü performansa yol açacaktır, çünkü hiç kimse kodu anlamıyor ve her birini daha da kötüleştiren bir diğerini hacklemekle sonuçlanıyor.

İyi değişken adı hakkında bilgi için bunları okuyun: http://tottinge.blogsome.com/meaningfulnames

Çok uzun değişken adının gerekli olduğunu düşünüyorsanız, kodunuzun çok iyi yapılandırılmadığı anlamına gelir. Bir değişken adı her zaman bir bağlamda ifade edilir: ad, sınıf adı, dosya adı, klasör, işlev adı, vb Böylece, uzun olacak şekilde adı ihtiyacı açık olması durumunda, bu araçlar o adlandırabilir çalıştığınız o şey gelmez' T BURADA . Bu durumda, bu kodu uygun yere koymayı düşünün veya henüz yoksa bu yeri oluşturun.


0

Cevap php ile ilgili açıkçası evet.

Bir fark yaratmayacağını söyleyen cevaplar mutlaka doğru değildir. Örneğin, küçük bir php betiğim var, sadece birkaç satır var, ancak işini bitirmeden önce yaklaşık 1.950.000 kez döngü yapması gerekiyor, bu yüzden betiğin tek bir çalışması fark edilmese de, bir saniyenin bu bölümleri önemli ölçüde toplandığında birçok kez döngü.


1
Ama yanılıyorsun. Herhangi bir iyi php yorumlayıcı sadece bir kez kodu ayrıştıracaktır. Php tercümanlar yazan çocuklar aptal değil.
gnasher729

@ gnasher729 Tercümanın veya sunucunun tamamının nasıl çalıştığı hakkında varsayımlar yapıyorsunuz ve bunu asla yapmamalısınız. Her çalıştırmada yalnızca bir kez ayrıştırsa bile, her çalıştırmada yeniden ayrışabilir ve ayrıştırılmış bir temsili önbelleğe alamaz (diğer sistemler bunu yapar, ancak önceden bilemezsiniz). Ve genellikle bir komut dosyası ne kadar bayt olursa ayrıştırma süresi o kadar uzun olur. Diorthotis genellikle yanlış değildir, sadece belirli bir sistemle ilgili yanlış olabilir.
Mecki

0

Kodunuzu daha az okunabilir hale getiren kısa adlar kullanabilirsiniz. Bir ya da iki mikrosaniye tasarruf edeceksiniz. Ancak kod daha az okunabilir olduğundan, kodu geliştirmek ve daha hızlı hale getirmek daha zordur. Böylece kısa isimlerle sürdürülemeyen, geliştirilemeyen kodunuz sonunda önemli ölçüde daha yavaş çalışacaktır.

Sorunuzu cevaplamak için ("performansı etkiler mi"): Evet, ancak istediğiniz şekilde değil.

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.