jeden programista, wiele języków - dylemat nazwy

Podczas pracy w wielu językach programowania występuje problem ...

Prawidłowa nazwa (identyfikator) w jednym języku jest nieprawidłowa w innym. Na przykład...

var new function thissą słowami kluczowymi w JavaScript, ale możesz używać ich dowolnie w Pythonie. Podobnie list dict defmożna bez problemu używać w JavaScript.

Jest to bardzo powszechne i coś, co programiści zazwyczaj szybko się zapoznają, gdy programują w wielu językach.

Jednak podczas współpracy musisz określić zasady / wytyczne dla członków zespołu, aby zapewnić spójność i jednolitość kodu. W zespołach ten problem staje się ważniejszy niż zwykłe zapamiętywanie, co jest ważne, a co nie, podczas programowania.

Moje pytanie brzmi: jakie strategie przyjmujecie ...

• po prostu zbierz wszystkie zastrzeżone słowa obecne we wszystkich używanych przez ciebie językach, rozdaj wszystkim listę i powstrzymaj się od ich używania?
• zaakceptuj różnorodność i dołóż starań, gdy „przełączanie kontekstu”
• przyjąć płaszczyznę pośrednią, w której jeden język może używać drugiego, ale nie odwrotnie

(Uwaga: mówię tylko o Pythonie i JavaScript w tym pytaniu ... ale proszę odpowiedzieć bardziej ogólnie na pytanie)

-- AKTUALIZACJA --

Dziękuję za wszystkie odpowiedzi. Tak więc ogólny konsensus, jaki widzę, wyłania się, pozwala programistom używać dowolnej nazwy, niezależnie od tego, co robią w innych językach - dopóki nazwy są opisowe, nie boli.

Po ponad 30-letnim doświadczeniu programując w kilku językach, powiedziałbym, że próba znalezienia standardów nazewnictwa, które będą działać w każdym języku, jest prawdopodobnie pomysłem na niebie.

Na początku doświadczenia próbowałem użyć makr #define w C, aby stworzyć rzeczy, które sprawiłyby, że mój kod C wyglądałby jak kod Pascal, którego wcześniej używałem. Byłem tak przyzwyczajony do programowania w Pascalu, że doszedłem do wniosku, że jeśli mogę po prostu sprawić, by C działał jak Pascal, zwiększy to moją produktywność. Wkrótce odkryłem, że się myliłem.

To, co uczyniło mnie bardziej produktywnym, to nauka języka C i nie próbowanie wykorzystania składni Pascala w innym języku tylko dlatego, że uczyniło mnie to wygodniejszym.

Myślę, że potencjalnie będziesz ograniczać swoich programistów, uniemożliwiając im robienie czegoś w jednym języku, tylko dlatego, że źle jest to robić w innym języku, którego używasz.

Jeśli ograniczysz konwencje nazewnictwa do rzeczy, które mają sens, aby wyjaśnić użycie zmiennej, prawdopodobnie stworzysz dobry kod w dowolnym języku.

Nie powinieneś nazywać rzeczy „list”, „new”, „var”, „this”, ponieważ nie są wystarczająco opisowe w żadnym języku.

Przejście z, powiedzmy, javascript na python jest już przełącznikiem kontekstu. Nie sądzę, że źle jest, jeśli zmieniają się nazwy zmiennych, szczególnie jeśli zmiany w nazwach są idiomatyczne z językiem. W tym przypadku można nawet argumentować, że trudniejsze są przełączniki kontekstu, ponieważ pomagają wzmocnić „koleś, piszesz teraz javascript, a nie python”.

Myślę, że jeśli używasz zmiennej opisowej, opisany problem powinien być minimalny. To powiedziawszy, jeśli jest minimalne, akceptacja przesunięcia kontekstu spowodowanego przez nazewnictwo zmiennych między językami również staje się minimalna.

Najbardziej zastrzeżone słowa (w dowolnym języku) są dość ogólne. Wolę nazwy zmiennych / funkcji, które są bardziej opisowe, co oznacza, że ​​prawie nigdy nie napotykam tego problemu. Muszę przyznać, że został zainfekowany przez Charlesa Simonyi jego oryginalnym schematem nazewnictwa - to było w Xerox pod koniec lat 70., zanim jeszcze nazwano go Notacją Węgierską - i to również oznacza, że ​​imiona są czymś więcej niż normalnym człowiekiem użyłby kiedykolwiek słów zastrzeżonych.

Nie powinieneś marnować czasu na pisanie wytycznych, dopóki nie odkryjesz, że jest to rzeczywisty , a nie hipotetyczny problem.

Jedną z sytuacji, o których mogę pomyśleć, gdzie może to stać się problemem, jest dzielenie się strukturami danych między językami programowania. Na przykład, jeśli masz obiekt JavaScript po stronie klienta, który jest odzwierciedlony w obiekcie Python po stronie serwera, i naturalnie chcesz, aby miały te same nazwy dla swoich członków. W takim przypadku reguła jest prosta: nie używaj nazw, które są słowami zastrzeżonymi w żadnym z języków. Otóż ​​to. Napisz to w wytycznych, jeśli chcesz. Teraz przejdź do ważniejszych zadań.

BTW, ani lista, ani dict nie są słowem zastrzeżonym w Pythonie. Mogą być używane jako nazwy zmiennych, choć dość kiepskie.

Z mojego doświadczenia wynika, że ​​rozwiązaniem tego są ogólne konwencje nazewnictwa, które dotyczą wszystkich języków. Niezależnie od tego, czy jest to JavaScript, C #, czy jakiś inny funky język, sposób, w jaki zmienne i klasy są nazywane, może stać się standardem w bazie kodu, co na ogół uważam za rozwiązanie tego problemu. Konwencje mogą być uzgadniane w drodze konsensusu wszystkich, po prostu większość chce wytycznych, kierownictwo mówi: „Tak to robimy” lub kilka innych możliwości, jakie sobie wyobrażam.

Rzadko widzę opisywany problem z identyfikatorem, ponieważ przez większość czasu nazwa mojej klasy lub zmiennej jest wystarczająco opisowa, aby nie powodować konfliktów. Jednocześnie, jeśli ktoś pracuje z innymi, nie ma jasności co do sposobu, w jaki zespół chce sobie z tym poradzić, jest to ważna kwestia.

Nie rozumiem, jak może to stanowić problem, chyba że planujesz przenieść kod z jednego języka na inny. Jeśli osobiście zapominasz, które nazwy zmiennych są prawidłowe, nie używaj nazwy zmiennej, chyba że masz pewność, że jest poprawna. Ale jeśli inne osoby używają niepoprawnych nazw zmiennych, ich kod nie zostanie skompilowany ani uruchomiony. Jeśli więc pracujesz nad czyimś kodem, który nazwał coś „var”, możesz być całkiem pewien, że jest to poprawna nazwa w dowolnym języku, którego używa.

Jeśli możesz planować przenoszenie kodu z jednego języka na inny, może być potrzebna lista zabronionych nazw. Na przykład mój dokument dotyczący kodowania w języku C zabrania używania nowej lub klasy jako zmiennej, ponieważ utrudnia to przeniesienie kodu do C ++. W takim przypadku rozsądne jest ustanowienie zasad ułatwiających tę pracę, jeśli zajdzie taka potrzeba,

Po prostu trzymaj się wiodącej małej litery CamelCase. Działa wszędzie. Nazywa się to szukaniem najniższego wspólnego mianownika między niekompatybilnymi systemami, a będziesz to robił często!