Kullanılmayan bir değişkeni tek bir alt çizgi ile adlandırmak kötü bir uygulama mıdır?

Genellikle, dilin sözdizimi, hiç kullanılmamış bir değişkeni ismemi istediğinde, onu isimlendiririm _.

Aklımda bu karmaşayı azaltır ve koddaki anlamlı değişkenlere odaklanmama izin verir. Göze çarpmayan, böylece “görüş dışı, akıl dışı” bir etki yarattığını görüyorum.

Bunu yaptığım yerin yaygın bir örneği, SQL'deki alt sorguları adlandırmaktır.

SELECT *
FROM
(
    SELECT *
    FROM TableA
    JOIN TableB
        ON TableA.ColumnB = TableB.ColumnB
    WHERE [ColumnA] > 10
) _ --This name is required, but never used here
ORDER BY ColumnC

Başka bir örnek, kullanılmayan bir döngü değişkenidir.

array = [[] for _ in range(n)] # Defines a list of n empty lists in Python

Bu tekniği çok dikkatli kullanıyorum, sadece açıklayıcı bir ismin koda hiçbir şey katmadığını hissettiğimde ve bir anlamda hatırlamak için daha fazla isim ekleyerek ondan uzaklaştığını hissediyorum. Bazı açılardan var, C # 'daki anahtar kelimeye benzer şekilde kullanıyorum, bu da çok kullanıyorum.

İş arkadaşlarım aynı fikirde değil. Tek bir (alfabetik) karakter ismine sahip olmaktan bile daha iyi olduğunu söylerler _.

Yanlış mıyım? Bunu yapmak kötü bir uygulama mı?

Bütün isimler anlamlı olmalı. Eğer _şirketinizde veya daha geniş toplumda iyi bilinen standart, o zaman "önemli değil adı" şeklinde anlamlı olur. Olmazsa kötü bir uygulama olduğunu söyleyebilirim. Özellikle isminiz gelecekte önemli olabileceğinden, neye atıfta bulunduğunuz için açıklayıcı bir ad kullanın.

Bunun kabul edilebilir bir uygulama olduğunu söyleyebilirim. Bu, çoğunluğun yanlış olduğunu düşündüğüm ve son programlama fikirleri hakkındaki bilgilerini güncellemesi gereken nadir bir durum. Pek çok dilde, özellikle Haskell ve OCaml gibi ML tabanlı işlevsel diller, _"kullanılmayan" bir değişken olarak kullanımı oldukça yaygındır . Açıkça dil desteği sağlamayan Lua bile, _sözleşmeyle yer tutucu olarak kullanılmasını teşvik ediyor .

Birkaç dil (Haskell, Lua ve DI başımın üstünden geliyor) aynı zamanda bir alt çizgi ile çıkan değişkenlerin, _en kısa kullanılmayan değişken adını veren "kullanılmayan yerel değişken" hakkında derleyici uyarıları oluşturmadığı bir kongre sunar . Gibi bir şey kullanabilirsiniz _unusedama bunun sadece karışıklık yarattığı konusunda katılıyorum.

Python'da _kesinlikle kabul edilebilir. Ancak gettexttakma adla çatışabilir _().

Diğer yaygın sözleşmeler dummy, unused; tek başına veya ön ek olarak.

Bazı kod analiz araçları bu kuralların farkındadır ve kullanılmayan değişken uyarılar yayınlamaz:

• PyLint için _veyadummy
• Pydev her değişken için başlayarak _, unusedya dadummy

Bu kodun yaşayacağı ekosisteme bağlıdır. Eğer _"kukla değişken" / "kullanılmayan çıktı" yı göstermek için kabul edilmiş bir standartsa, o zaman elbette, buna bağlı kalın. Değilse, ne olduğunu bulun ve kullanın.

Bazı programlama dilleri (örneğin Haskell), sözde tam anlamıyla belirtilen sözdiziminde yerleşik olarak bu 'özel' tanımlayıcıya sahiptir.

Dikkat et, _ zaten bazı dillerde içsel bir anlama sahip

Python'da:

9.6. Özel Değişkenler ve Sınıf-Yerel Referanslar

link tanımını buraya girin , Python'da bir nesnenin içinden erişilemeyen “Özel” örnek değişkenleri yoktur. Bununla birlikte, çoğu Python kodunun izlediği bir kural vardır: alt çizgi (örneğin _spam) ile önceden yazılmış bir ad, API'nin halka açık olmayan bir parçası olarak değerlendirilmelidir (bir işlev, bir yöntem veya veri üyesi) . Bir uygulama detayı olarak düşünülmeli ve önceden bildirilmeksizin değiştirilebilir.

PEP 8'de (Python Kodu için Stil Kılavuzu) bir başka ifade daha var:

Tanımlayıcı: Stilleri Adlandırma

_single_leading_underscore: zayıf "dahili kullanım" göstergesi. Örneğin, M import *, adı alt çizgi ile başlayan nesneleri içe aktarmaz.

C # 'da:

Genelde, genel / dahili özelliklere sahip özel değişkenleri işaretlemek için kullanılır. Ancak uygulama genellikle bu günlerde inceleniyor .

JavaScript’te:

Standart olmayan prototip uzantıları için alt çizgiyi önek olarak kullanan, undercore.js adlı bir kütüphane var.

Örnek:

var object = { some:'stuff' };
var newObject = _.clone(object);

Bu beni hedefime götürüyor. Klasik yer tutucu değişken kurallarında yanlış olan ne?

var i, j, k, l; // iterator placeholders
var x, y, z, xx, yy, zz // value placeholders
var foo, bar, bas, fixx, buzz, qux, etc... // demonstration placeholders

Halihazırda birçok ortak sözleşme mevcutken, bazılarının yanlış anlayabileceği özel bir kongre neden kullanılmalı?

Böyle bir şey için "kukla" kullanıyorum. Ya da "bok", eğer sadece bir şeyi deniyorsam :) Değişkenlerinizi ne olduklarını açıklamak için adlandırın. Sahte ve kullanılmayan değişkenler varsa, bunları öyle adlandırın.

Bunu kötü bir uygulama olarak buluyorum çünkü

• kodunuzda görünmez değişken olmamalıdır. Eğer hissetmeniz gerekiyorsa sebebi muhtemelen tartışılabilir.

• Go dili bu anahtar kelimeyi, hiçbir değişkenin, bir fonksiyonun çoklu dönüşlerinden birinin hedefi olmadığını belirtmek için kullanır. Dilinizde birden fazla dönüş yoksa, buna gerek yoktur. Adlandırma kuralınız, standart dil gösterimi olarak _ kullanarak bir dili kullanacağınız gün size zarar verecektir.

(Python'u tanımıyorum: bu yapı gerçekten gerekli mi?)

Sözdizimsel olarak geçerli olabilir ve standardın bir parçası olarak Tamam olabilir.

Bununla birlikte, bir kod incelemesinde değişiklik yapmasını isteyeceğim bir şey olduğunu söyledi. Ayrıca hiçbir zaman bir kodlama standardına koymuyordum ve onu mevcut olandan kaldırmaya çalışırdım. Okumak daha zor ve süper anlamlı değil.

Yanlış olduğunu düşünüyorum çünkü:

1) Çok fazla piksel olmadığı için bunu görmek zor.

2) Birden fazla varsa _, hangisini biliyorsunuz? - ya da yeni bir geliştiricinin 'kurallara uyduğunu' ve kullanımlarını son derece yerel olarak koruduğunu mu?

3) Yardımcı olmayan bir uygulamadır. Tek harfli değişken isimleri kullanmak çok eski bir okul (yani benim asıl eğitimim!) Onları göreceğim ... ve sonra kodun ne yaptığını ve bugünün dünyasında kötü bir uygulama olduğunu söylemek için eklenen yorumları göreceğim. Uzun değişken isimlerini mümkün olduğu kadar kullanıyorum, bu yüzden herkes, programlama seviyesine veya kod aşina olmasına bakılmaksızın, neredeyse ingilizce gibi "okuyabilir". 1 harf adının kullanılması, daha eski kodlarda ve daha eski programcılarda (yine beni içerir) son derece yaygın bir uygulamadır, ancak bu tamam değildir.

Ad alanı çakışmalarını önlemek ve hata ayıklamaya izin vermemek için, değişken adın tek ipucunuz olması durumunda, "join_ab_unused" olarak adlandırmanız daha iyi olabilir.

Birfl'ten ilham alındı.

Evet, iki nedenden dolayı kötü bir uygulama:

1. Kullanılmayan bir değişkeni alt çizgi ile öneklemek, yaygın olarak kabul edilen bir standart değildir. Muhtemelen "başlatılmamış" göz ardı edilecektir.
2. Bazı kişilerin özel üye değişkenlerinin altını çizdiğini gördüm ve standartlarınız bu tür insanları çok şaşırtıyor.

Yapmaya çalıştığınız, işe yaramaz bir şey için bir isim icat etmeye zorlamayan, daha güzel bir SQL sürümünde kodlamaktır.

Alt çizgi neredeyse görünmez, bu yüzden o dilde gibi görünüyorsun. Tanımlayıcı olarak yalnızca boşluk kullanılabilirse, mükemmel olurdu, değil mi?

Ancak farklı bir dilde değilsiniz ve yaptığınız şey bir dil uzatması yapmanın temiz bir yolu değil.

Dile bağlıdır. In java , evet bu, kötü ve Kodunuza eklemek için tehlikeli bir eğilim olabilir büyük nedeni onlar java değişken adlandırma kuralları dışında olduğundan kullanım yansıma, çok iyi alt çizgi tutmamaları araçları. In piton , bu da kötü değil ama bad gibidir. In Clojure , onun% 100 tamam ve aslında, deyimsel bir izin açıklamada yer tutucular olarak _ 's kullanmak.

Her dilin kendine has bir sözdizimine ve deyim kümesine sahip olduğunu unutmayın; bu nedenle mutlak terimler yerine, bu deyimler açısından iyiyi / kötüyü değerlendirmek zorundasınız.

Bu, $ _ (ve bazen _) 'i özel bir değişken olarak kullanan perl için kötü olurdu.

Genel olarak, ondan uzak dururdum çünkü _, belirli bir dili belirleyici görünüyor. Eğer kodunu görseydim, sadece bir aptal olduğunu farkedene kadar _'in ne olduğunu bulmak için belgelerde olurdum. DUMMY, $ DUMMY, neyse yanlış bir şey yok.

Belirli bir dilde veya ağır kullanımda bir çerçevede başka bir şey belirtme eğiliminde olmadıklarından emin olmadıkça vars başlangıcında alt çizgilerden kaçınırdım. Örneğin, Python'da, çift alt çizgi sihirli bir değişkeni gösterme eğilimindedir. JQuery ve diğer JS kütüphanelerinde, tek bir alt çizgi, ad alanının üzerine yazmak için bir geri dönüş var gösterme eğilimindedir. Aynı zamanda popüler bir adlandırma kuralı olup, sırayla ele alma işleminin var biçiminde kodlama biçimine geçme eğiliminde olan dosyaları içerir.