Programiści Javy nie potrzebują kodowania typów. Obiekty są silnie typowane, a środowiska są tak zaawansowane, że wykrywają błąd, na długo przed tym, jak uruchomić kombinację . Tak więc obecnie HN i inne formy kodowania typów są po prostu przeszkodami. Utrudniają one zmianę nazwy lub typu zmiennej, funkcji lub klasy, utrudniają czytanie kodu. I stwarzają możliwość, że system kodowania wprowadzi czytelnika w błąd. Poza tym, ludzie szybko uczą się ignorować przedrostek (lub przyrostek), aby zobaczyć znaczącą część nazwy. Im więcej czytamy kod, tym mniej widzimy prefiksy. W końcu stają się znacznikiem kodu.
Pojawiające się problemy
Problem zazwyczaj wynika z wyboru, aby nie używać ani terminów z dziedziny problemów, ani terminów z dziedziny rozwiązań. Jest to problem z jednoliterowymi nazwami zmiennych. Z pewnością licznik pętli może być nazwany i lub j lub k (ale nie l!), jeśli jego zakres jest bardzo mały i żadne inne nazwy nie mogą z nim kolidować. Dzieje się tak dlatego, że te jednoliterowe nazwy dla liczników pętli są tradycyjne. Jednakże, w większości innych kontekstów jednoliterowa nazwa jest złym wyborem; jest to tylko uchwyt miejsca, który czytelnik musi sprowadzić do rzeczywistej koncepcji. Nie może być gorszego powodu. Wybierz jedno słowo dla jednego abstrakcyjnego pojęcia i trzymaj się go.
Nowoczesne środowiska edycyjne, takie jak Eclipse i IntelliJ, zapewniają wskazówki kontekstowe, takie jak lista metod, które możesz wywołać na danym obiekcie. Lista zazwyczaj nie daje komentarzy, które napisałeś wokół swoich nazw funkcji i list parametrów. Nazwy funkcji muszą stać samodzielnie i muszą być spójne, abyś mógł wybrać właściwą metodę. Unikaj używania tego samego słowa do dwóch celów. Tak długo jak listy parametrów i wartości, różnych metod add są semantycznie równoważne, wszystko jest w porządku.
Pamiętaj! Naszym celem jest sprawienie, aby nasz kod był jak najłatwiejszy do zrozumienia.
Na naszych kursach znajdziesz koleją dawkę wiedzy. KIinkij TUTAJ i sam się przekonaj.
Zespół GREAT