Durne nazwy zmiennych

0

Mały background, pokazujący jedną z tysięcy takich sytuacji. Ta miała miejsce dzisiaj.
Wyszukuję sobie jak przesłać za pomocą Socketów plik. Znajduję coś takiego: http://www.rgagnon.com/javadetails/java-0542.html

Patrzę i nie rozumiem nic, bo muszę odszyfrowywać linijka po linijce kod. Jak w pieprzonym asemblerze bez komentarzy. Kod programu jest tutaj bardzo adekwatny, ponieważ to faktycznie jest napisane jakimś kodem.
Czy ktoś jest mi w stanie wytłumaczyć czemu ogromna część programistów wzięła sobie za punkt honoru, aby KAŻDA nazwa zmiennej była skrótem / literą? Dlaczego taki bałwan nie może napisać jednoznacznie: Socket socket.
Zamiast tego daje zmienna sock, co według wielu słowników angielsko-polskich znaczy skarpeta. Dzisiaj dowiedziałem się, że networking w Javie może być zapewniony przez obiekty skarpet.

Zamiast spojrzeć na kod programu i go rozumieć to muszę odszyfrowywać albo pozamieniać te is, bos, cs, ds, gi, i, j, sock, obj, itm, stkovflw, knstntnpltnczkwczwna na normalne, wymowne nazwy. Trochę mnie to frustruje i zaczynam kwestionować moją przyszłą karierę programisty, gdzie w takim gównokodzie napisanym przez Andrzeja po 10-godzinnym kursie programowania albo studenta informatyki na wydziale politologii trzeba będzie się babrać. Tutaj, w prostym przykładzie poświęcę 2 minuty i napiszę to po ludzku, ale w dużym projekcie może to być kiepskim pomysłem.

0

No co Ty? Na studiach nie byłeś, że Cię bulwersują takie rzeczy jak ten kod powyżej? :D

1

To dobrze że kwestionujesz. Kod nigdy nie będzie taki piękny jak Ci się wydaje. Jeżeli czepiasz się już do nazw zmiennych, to uwierz mi, że to dopiero początek. Oczywiście nie twierdzę że tak jest ok. Każdy powinien dbać o kod, ale dobry programista to nie ten co pisze dobry kod, ale ten który pisze dobry kod, a umie pracować ze słabym. Tak więc, jeżeli taka błahostka jest dla Ciebie frustrująca, to nie jest zawód dla Ciebie.

1

Problem jest tylko taki, że nazwy w podanym przykładzie są - według mnie - OK.

Co tam jest według ciebie nie tak? "fis", "bis", "fos"? Czy "current", "bytesRead"? Chyba tylko do "mybytearray" bym się mógł przyczepić za brak camelCase.

0

Wprawdzie ja z C ale swoje 3 grosze wtrące.

Nie pisałbym tego na capsie.
public final static int SOCKET_PORT = 13267; // you may change this

FileInputStream fis = null; // dalbym is_file 1
BufferedInputStream bis = null; // is_buff

Dorzuciłbym jeszcze że zamiast cosTakiego preferuję cos_takiego.
Jak dla mnie kod raczej czytelny, wprawdzie ja z java jestem zero ale widać co się dzieje z grubsza.

edit:
Może file_is buff_is bo is_file wygląda jak pytanie. No ale lepsze niż fis / bis.

0

@wujnia:
To kod Java, czyli camelCase, czyli cosTakiego, a nie cos_takiego. SOCKET_PORT też jest zgodny z wytycznymi od Oracle'a.

Znalazłem tylko dwie rzeczy (streamy, czyli "fis", "bis", "bos" i mybytearray zamiast myByteArray), ale one nie są jakimś megaprzestępstwem. Lepsze to niż np.

	int i,j,k,l,m,n,o;
	// ... operacje na tych zmiennych

        i = k > l ? k : m > l ? m : n > l ? n > l ? n : j : l;
0

Kod albo pseudokod algorytmu. Początek:

int n, p, k, j, x, w;

i już wiem, że będzie fajnie.
//edit: nie przeczytałem postu wyżej i wyszedł klon :/

4

Ten kod nie jest zły. fis i bis to oczywiście skróty nazw odpowiednich typów. Sam tak nazywam zmienne będące „lokalnymi singletonami”, czyli jedynymi zmiennymi danego typu w okolicy.

Potrzebujesz w funkcji obiektu FileInputStream, i będzie to jedyny obiekt tego typu w funkcji? To po co wymyślać mu jakąś inną nazwę, skoro innego FileInputStreamu nie ma.

Gorzej gdyby się nazywał x.

4
Potat0x napisał(a):

Kod albo pseudokod algorytmu. Początek:

int n, p, k, j, x, w;

i już wiem, że będzie fajnie.

To nie musi być zły kod. Jeżeli to jest implementacja jakiegoś wzoru, to nie ma po co silić się na wymyślanie nazw zmiennych opisowych, niezgodnych z użytymi we wzorze symbolami.

0

W czasach javy i monitorów 5k to nie ma znaczenia, ale jak miało się terminal na 80 lub 130 znaków to szerokość zmiennych zaczynała mieć znaczenie. Pewnie to jakaś zaszłość i obecnie bardziej tak się uczymy bo ktoś czyta stare kursy, albo wykładowca na tablicy pisze tak, albo bo jest starej daty, albo nie chce mu się na tablicy pisać długich zmiennych.

2

To jest całkiem poprawne nazewnictwo.
Stosowane zresztą w oficjalnych podręcznikach do Javy od Oracle'a (patrz "OCA/OCP Java SE 7 Programmer I & II Study Guide").
Wszelkie 3-4 wyrazowe nazwy można skrócić do 3-4 znakowych skrótów pochodzących od nazw klas i są w miarę unikalne w obrębie metody.

Nazwy jedno-literowe też są OK, część z nich pochodzi z matematyki, część z fizyki:
i,j,k - zmienne iteracyjne
n,m - liczba elementów
h - wysokość
x, y, z - pozycje w układzie współrzędnych
dx, dy, dz - przyrost pozycji w układzie współrzędnych
a,b - wartości "pierwsza i druga" np. w metodach typu min/max
v - prędkość
r - promień

A skróty są nie tylko przez małe ekrany. Łatwiej operuje się nazwą zmiennej "byteArrayOutputStream" czy "baos"?

0

A ja się całkowicie zgodzę z autorem wątku. Bo czy nie lepiej zarówno dla piszącego jak i czytającego byłoby:

FileInputStream input = null
BufferedInputStream buffer = null;
OutputStream output = null

zamiast takich nic nie mówiących akronimów fis, bis, etc.?

3

Zacznijmy od podstaw.

variable-name.png

Nazwa zmiennej w rodzaju fis czy bis nie jest złą nazwą o ile donosi się do czegoś lokalnego. Tak samo jak używamy i jako licznika w pętli, czy c do trzymania aktualnie parsowanego znaku.

Problem leży gdzie indziej. Kod na którym się pastwimy, jest proceduralny, aż do bólu. Jeżeli podzielisz go ładnie na metody, to nagle te zmienne znikną. Jeżeli pisząc kod, zastanawiasz się nad znaczeniem zmiennej, to oznacza, że:

  • zmienna ma zbyt szeroki zasięg i zbyt krótką nazwę,
  • nazwa choć opisowa, to nie oddaje intencji.

Dzisiaj nie powinien być to problem, bo IDE dość dobrze radzą sobie z uzupełnianiem nazw. Z drugiej strony nasze mózgi nadal nie za bardzo radzą sobie z dłuższymi nazwami zapisanymi camelCasem, albo z podkreśleniami. Podsumowując, nazwy skrótowe są ok, ale jak mają bardzo krótki i oczywisty zasięg.

1 użytkowników online, w tym zalogowanych: 0, gości: 1