Czy złą praktyką jest nazywanie nieużywanej zmiennej pojedynczym podkreśleniem?

Często, gdy składnia języka wymaga, abym nazwał zmienną, która nigdy nie jest używana, nadam jej nazwę _.

Moim zdaniem zmniejsza to bałagan i pozwala skupić się na znaczących zmiennych w kodzie. Uważam, że jest dyskretny, dlatego wywołuje efekt „poza zasięgiem wzroku, poza zasięgiem umysłu”.

Typowym przykładem tego, co robię, jest nazywanie podkwerend w SQL.

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

Innym przykładem jest zmienna pętli, która nie jest używana.

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

Używam tej techniki bardzo oszczędnie, tylko wtedy, gdy czuję, że opisowa nazwa nic nie dodaje do kodu, iw pewnym sensie odbiera ją, dodając więcej nazw do zapamiętania. Pod pewnymi względami postrzegam to jako podobne do varsłowa kluczowego w C #, którego również używam oszczędnie.

Moi współpracownicy się nie zgadzają. Mówią, że nawet posiadanie pojedynczej (alfabetycznej) nazwy znaku jest lepsze niż _.

Czy się mylę? Czy to jest złą praktyką?

Wszystkie imiona powinny mieć znaczenie. Gdyby _był dobrze znanym standardem w Twojej firmie lub w szerszej społeczności, miałby znaczenie jako „nazwa, która nie ma znaczenia”. Jeśli nie, powiedziałbym, że to zła praktyka. Używaj opisowej nazwy do tego, do czego się odwołujesz, zwłaszcza że nazwa może mieć znaczenie w przyszłości.

Powiedziałbym, że jest to dopuszczalna praktyka. Jest to rzadki przypadek, w którym uważam, że większość jest błędna i potrzebuje aktualizacji wiedzy na temat najnowszych pomysłów programistycznych. W wielu językach, szczególnie w językach funkcjonalnych opartych na ML, takich jak Haskell i OCaml, niezwykle często stosuje się je _jako „nieużywane” zmienne. Nawet Lua, która nie oferuje wsparcia dla jawnego języka, zachęca do korzystania z niego _jako symbolu zastępczego zgodnie z konwencją.

Kilka języków (Haskell, Lua i DI myślą z góry) również oferuje konwencję, w której zmienne, które prowadzą z podkreśleniem, nie generują ostrzeżeń kompilatora o „nieużywanej zmiennej lokalnej”, co czyni _najkrótszą nieużywaną nazwę zmiennej. Możesz użyć czegoś takiego, _unusedale zgadzam się z tobą, że to po prostu bałagan.

W Pythonie _jest definitywnie akceptowalny. Może jednak powodować konflikt z gettextaliasem _().

Inne częste konwencje dummy, unused; sam lub jako prefiks.

Niektóre narzędzia do analizy kodu znają te konwencje i nie wydają nieużywanych ostrzeżeń o zmiennych:

• PyLint dla _lubdummy
• PyDev dla każdej zmiennej, począwszy od _, unusedlubdummy

Zależy to od ekosystemu, w którym ten kod będzie żył. Jeśli _jest akceptowanym standardem wskazującym „zmienną fikcyjną” / „nieużywaną moc wyjściową”, to należy go trzymać. Jeśli nie, dowiedz się, co to jest i skorzystaj z niego.

Niektóre języki programowania (np. Haskell) mają nawet ten „specjalny” identyfikator wbudowany w ich składnię do dokładnie wymienionych celów.

Ostrożnie, _ ma już pewne znaczenie w niektórych językach

W Pythonie:

9,6 Zmienne prywatne i odniesienia lokalne

wprowadź opis linku tutaj Zmienne instancji „Prywatne”, do których nie można uzyskać dostępu, chyba że z wnętrza obiektu nie istnieją w Pythonie. Istnieje jednak konwencja, po której następuje większość kodu w języku Python: nazwa poprzedzona znakiem podkreślenia (np. _Spam) powinna być traktowana jako niepubliczna część interfejsu API (niezależnie od tego, czy jest to funkcja, metoda czy element danych) . Należy to uznać za szczegół implementacji i może ulec zmianie bez powiadomienia.

Jest też inna wzmianka w PEP 8 (Przewodnik po stylu dla kodu Python):

Opisowy: Style nazewnictwa

_single_leading_underscore: słaby wskaźnik „do użytku wewnętrznego”. Np. Z importu M * nie importuje obiektów, których nazwa zaczyna się znakiem podkreślenia.

W C #:

Zwykle służy do oznaczania zmiennych prywatnych, które mają właściwości publiczne / wewnętrzne. Ale w tych czasach praktyka jest ogólnie odrzucana .

W JavaScript:

Istnieje biblioteka o nazwie underscore.js, która używa podkreślenia jako prefiksu niestandardowych rozszerzeń prototypów.

Przykład:

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

Co prowadzi mnie do mojego punktu. Co jest nie tak z klasycznymi konwencjami zmiennych zastępczych.

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

Po co używać niestandardowej konwencji, którą niektórzy mogą błędnie interpretować, skoro dostępnych jest już wiele popularnych konwencji?

Używam do tego „manekina”. Lub „bzdura”, jeśli tylko coś testuję :) Nazwij swoje zmienne, aby opisać, jakie są. Jeśli są to atrapy nieużywane zmienne, nazwij je jako takie.

Uważam to za złą praktykę, ponieważ

• nie powinieneś mieć niewidocznej zmiennej w swoim kodzie. Jeśli uważasz, że powinieneś, powód może być prawdopodobnie omówiony.

• język Go używa tego słowa kluczowego, aby wskazać, że żadna zmienna nie jest celem jednego z wielu zwrotów funkcji. Jeśli twój język nie ma wielu zwrotów, nie jest potrzebny. Konwencja nazewnictwa zaszkodzi Ci w dniu, w którym będziesz używać języka, używając _ jako standardowej notacji językowej.

(Nie znam Pythona: czy ten konstrukt jest naprawdę potrzebny?)

Może być poprawny pod względem składniowym i może być OK jako część standardu.

Powiedziawszy to, chciałbym poprosić kogoś o zmianę w recenzji kodu. Nigdy też nie wprowadziłbym go do standardu kodowania i próbowałbym go usunąć z istniejącego. Jest po prostu trudniejszy do odczytania i nie ma wielkiego znaczenia.

Myślę, że to źle, ponieważ:

1) Trudniej to zobaczyć, ponieważ nie ma wielu pikseli.

2) Jeśli jest więcej niż jeden _, skąd wiesz, który? - lub że nowy programista „przestrzegał zasad” i utrzymywał ich wyjątkowo lokalny zasięg?

3) Jest to praktyka, która nie jest pomocna. Używanie pojedynczych liter zmiennych to tak stara szkoła (tj. Moje oryginalne wykształcenie!). Zobaczę je ... a potem dodam komentarze, by powiedzieć, co robi kod, a to jest zła praktyka w dzisiejszym świecie. Używam długich nazw zmiennych tak często, jak to możliwe, więc każdy, bez względu na poziom programowania lub znajomość kodu, może po prostu „czytać” prawie jak angielski. Używanie nazw 1-literowych jest niezwykle powszechną praktyką w przypadku starszych kodów i starszych programistów (znowu obejmuje mnie), ale to nie czyni tego w porządku.

Aby uniknąć kolizji w przestrzeni nazw i umożliwić debugowanie, w przypadku gdy jedyną wskazówką jest nazwa zmiennej, lepiej nazwać ją „join_ab_unused”.

Zainspirowany przez Birfl.

Tak, to zła praktyka z dwóch powodów:

1. Prefiks nieużywanej zmiennej znakiem podkreślenia nie jest powszechnie akceptowanym standardem. Prawdopodobnie zostanie zignorowany jako „niewtajemniczony”.
2. Widziałem, jak niektórzy ludzie poprzedzają prywatne zmienne członkami znakiem podkreślenia, a twój standard bardzo pomieszałby takie osoby.

To, co próbujesz zrobić, to napisać w ładniejszej wersji SQL, która nie ma problemu z wymuszeniem wymyślenia nazwy czegoś bezużytecznego.

Podkreślenie jest prawie niewidoczne, więc wygląda na to, że jesteś w tym języku. Gdyby tylko identyfikator mógł być użyty jako identyfikator, byłoby idealnie, prawda?

Ale nie jesteś w innym języku, a to, co robisz, nie jest czystym sposobem na rozszerzenie języka.

To zależy od języka. W Javie tak, jest to złe i może być niebezpiecznym trendem do dodawania do twojego kodu, głównie dlatego, że narzędzia wykorzystujące odbicie nie radzą sobie zbyt dobrze z podkreśleniami, ponieważ są poza konwencjami nazewnictwa zmiennych Java. W Pythonie jest to również złe, ale nie tak złe. W clojure jest w 100% w porządku, aw rzeczywistości idiomatyczne jest używanie _ jako symboli zastępczych w instrukcji let.

Pamiętaj, że każdy język ma swoją własną składnię i zestaw idiomów, więc musisz oceniać dobre / złe pod względem tych idiomów, a nie w kategoriach bezwzględnych.

Byłoby źle w perlu, który używa $ _ (a czasami _) jako specjalnej zmiennej.

Ogólnie rzecz biorąc, trzymałbym się z dala od tego tylko dlatego, że _ wydaje się być specyficzną dla języka zmienną. Gdybym zobaczył twój kod, szukałbym w dokumentacji tego, czym był _, dopóki nie zdałem sobie sprawy, że to tylko manekin. Nic złego z DUMMY, $ DUMMY, cokolwiek.

Unikałbym podkreśleń na początku różnych wersji, chyba że byłeś pewien, że nie wskazują one na coś innego w danym języku lub frameworku, który jest często używany. Na przykład w Pythonie podwójny znak podkreślenia wskazuje na magiczną zmienność. W JQuery i innych bibliotekach JS pojedynczy znak podkreślenia wskazuje na zmienną rezerwową w przypadku zastępowania przestrzeni nazw. Jest to również popularna konwencja nazewnictwa dla plików dołączanych, które z kolei mają tendencję do przenoszenia na kod, który obsługuje zmienne w formie.