Dlaczego pylint obiektuje nazwy zmiennych składających się z jednego znaku?

Wciąż przyzwyczajam się do konwencji Pythona i używam, pylintaby uczynić mój kod bardziej pythonowym, ale zdziwi mnie fakt, że pylint nie lubi nazw zmiennych składających się z jednego znaku. Mam kilka takich pętli:

for x in x_values:
   my_list.append(x)

a kiedy uruchamiam pylint, otrzymuję Invalid name "x" for type variable (should match [a-z_][a-z0-9_]{2,30}- to sugeruje, że prawidłowa nazwa zmiennej musi mieć od 3 do 31 znaków, ale przejrzałem konwencje nazewnictwa PEP8 i nie widzę nic wyraźnego w odniesieniu do pojedynczych małych liter i widzę wiele przykładów, które ich używają.

Czy jest coś, czego brakuje mi w PEP8, czy jest to standard, który jest unikalny dla pylinta?

PyLint sprawdza nie tylko zalecenia PEP8. Ma też swoje własne zalecenia, z których jednym jest to, że nazwa zmiennej powinna być opisowa i niezbyt krótka.

Możesz tego użyć, aby uniknąć takich krótkich nazw:

my_list.extend(x_values)

Lub dostosuj konfigurację PyLint, aby poinformować PyLint, jaka nazwa zmiennej jest dobra.

Trochę więcej szczegółów na temat tego, co zauważył gurney Alex: możesz powiedzieć PyLintowi, aby robił wyjątki dla nazw zmiennych, które (przysięgasz, mały ) są całkowicie jasne, nawet jeśli mniej niż trzy znaki. Znajdź lub dodaj do pliku pylintrc pod [FORMAT]nagłówkiem:

# Good variable names which should always be accepted, separated by a comma
good-names=i,j,k,ex,Run,_,pk,x,y

Tutaj pk (dla klucza podstawowego), x i y to nazwy zmiennych, które dodałem.

W językach silnie wpisanych 1-literowe zmienne nazw mogą być w porządku, ponieważ zazwyczaj otrzymujesz typ obok nazwy w deklaracji zmiennej lub w prototypie funkcji / metody:

bool check_modality(string a, Mode b, OptionList c) {
    ModalityChecker v = build_checker(a, b);
    return v.check_option(c);
}

W Pythonie nie otrzymujesz tych informacji, więc jeśli napiszesz:

def check_modality(a, b, c):
    v = build_checker(a, b)
    return v.check_option(c)

nie pozostawiasz absolutnie żadnej wskazówki zespołowi utrzymania ruchu, co ta funkcja może robić, jak się ją nazywa i co zwraca. Dlatego w Pythonie masz tendencję do używania nazw opisowych:

def check_modality(name, mode, option_list):
    checker = build_checker(name, mode)
    return checker.check_option(option_list)

a nawet dodajesz dokumentację wyjaśniającą, co robi ten materiał i jakich typów się oczekuje.

Obecnie istnieje również możliwość zastąpienia wyrażenia regularnego. To znaczy, jeśli chcesz zezwolić na pojedyncze znaki jako zmienne:

pylint --variable-rgx="[a-z0-9_]{1,30}$" <filename>

Tak więc pylintbędzie pasować do PEP8 i nie spowoduje dodatkowych naruszeń. Możesz również dodać go do .pylintrc.

Im głębiej Powodem jest to, że można sobie przypomnieć, co zamierzałeś a, b, c, x,y , i zdo myśli, kiedy pisał swój kod, ale gdy inni ją przeczytać, a nawet po powrocie do kodu, kod staje się bardziej czytelny, gdy dajesz to nazwa semantyczna. Nie piszemy rzeczy raz na tablicy, a potem nie usuwamy. Piszemy kod, który może pozostać przez dekadę lub dłużej i być czytany wiele, wiele razy.

Używaj nazw semantycznych. Semantyczne nazw Mam stosowane były podobne ratio, denominator, obj_generator, path, itd. To może podjąć dodatkową sekundę lub dwie, aby wpisać je na zewnątrz, ale Zaoszczędzony czas próbuje dowiedzieć się, co napisałeś nawet pół godziny od tej pory jest tego warte .