Na przykład następująca funkcja przechodzi przez tablicę, która zawiera nazwę i błędy pola wejściowego. Robi to, sprawdzając nazwę pola sprawdzania poprawności, a następnie wypychając informacje o błędzie do tablicy niepoprawnych pól.
Czy lepiej jest streścić i napisać to:
addInvalidField (field, message) {
const foundField = this.invalidFields.find(value => {
return value.name === field.name
})
const errors = foundField.errors
if (!errors.some(error => error.name === message)) {
errors.push({ name: message, message })
}
},
Czy może być bardziej szczegółowy w ten sposób?
addInvalidField (validatingField, message) {
const foundField = this.invalidFields.find(invalidField => {
return validatingField.name === invalidField.name
})
if (!foundField.errors.some(foundFieldError => foundFieldError.name === message)) {
fouldField.errors.push({ name: message, message })
}
},
coding-style
naming
alex
źródło
źródło
Odpowiedzi:
Jeśli zwięzłość można poświęcić dla przejrzystości, powinna. Ale jeśli gadatliwość można poświęcić dla przejrzystości, jeszcze lepiej.
Gdy zmienna żyje tylko tak długo, jak jedna linia, może być bardzo krótka.
FoundInvalidField
jest używany w trzech liniach i jest przedmiotem niniejszej pracy. Zasługuje na nazwę wyjaśniającą.Jak zawsze kontekst jest królem.
źródło
Właściwie faworyzuję twój pierwszy przykład kodu.
Oczywiste jest, co robi kod, czytając go. Utrzymując nazwy zmiennych tak małe, jak to możliwe, czynisz kod jeszcze łatwiejszym do odczytania. Bardziej opisowe nazwy zmiennych byłyby konieczne tylko wtedy, gdyby twoje funkcje były dłuższe, twoje zmienne były liczniejsze i / lub zmienne zostały użyte w większym zakresie kodu.
Dzieje się tak dlatego, że masz krótkie funkcje, dlatego możesz także utrzymywać krótkie nazwy zmiennych. Wszystkie inne rzeczy są równe, zawsze mniej kodu jest zawsze lepsze.
źródło
validatingFields
są polami formularza z walidacją. Pierwotna nazwa tofieldWithValidation
. Naprawdę trudno znaleźć krótką nazwę dla tego. Mógłbym to nazwać,field
ale wtedy będzie miał konflikt z innymfield
wewnątrz metody.Wydaje mi się, że zgadzam się z wujem Bobem, że wolę jasność bez nadmiernej gadatliwości . W pokazanych przykładach powiedziałbym, że zamiary drugiego są wyraźniejsze, bez nadmiernej gadatliwości . Łatwiej byłoby również znaleźć ten konkretny fragment podczas przeszukiwania bazy kodu w poszukiwaniu
invalidField
niżvalue
.Cóż, cytuję tutaj Clean Code (pomiń go, jeśli masz dość kazań wuja Boba (których nie jestem):
Użyj nazw, które pomogłyby ci zrobić
grep -iIR whateveryouaresearching .
(nie czysty kod, tutaj CC mówiło tylko o zmiennych jednoliterowych).źródło
W dzisiejszych czasach zawsze wolałbym być bardziej opisowy - uzupełnianie kodu IDE oznacza, że nie będziesz musiał pisać opisowych nazw zmiennych, więc nie widzę minusów.
Już w prehistorii obowiązywały ograniczenia nazw zmiennych, a używanie znaczących nazw zmiennych mogło w rzeczywistości wiązać się z mierzalnym kosztem (np. W BBC BASIC przy użyciu liczb całkowitych zmiennych statycznych% itp. Było o wiele tańsze niż użycie znaczącej liczby całkowitej - i w systemie z 1MHz procesor, co pozwala zaoszczędzić kilka cykli zegara w pętli)
źródło
Drugi wariant sprawia, że jestem zaskoczony. Kiedy patrzę tylko na podpis, zastanawiam się, czy pole jest już znane jako nieważne? Czy też najpierw zostanie sprawdzony (jak się nazywa
validatingField
), aby sprawdzić, czy jest naprawdę nieważny? Więc to nie tylko zbędne informacje tutaj, dodatkowe informacje wydają się nieco mylące. Ten rodzaj „jasności” nie jest wyraźniejszy, wręcz przeciwnie.Właściwie, kiedy zobaczyłem twoją pierwszą funkcję, również mnie to zaskoczyło. Zadałem sobie pytanie, dlaczego, do cholery, twoja funkcja zajmuje tylko pole, ale potem go nie używa i szuka innego w
invalidFields
? Szukanie pola wydaje się mieć dużo więcej sensu, gdy podana jest tylko nazwa pola, jak poniżej:Myślę jednak, że Bob Martin prawdopodobnie poszedłby o krok dalej i uczyniłby kod bardziej szczegółowym - dla większej przejrzystości - w innym kierunku. Typowe refaktoryzacja w stylu książki „Czysty kod” prawdopodobnie wyglądałoby tak:
z trzema dodatkowymi funkcjami
Dyskusyjne jest, jeśli opłaca się posunąć się tak daleko za zasadą pojedynczej odpowiedzialności. Ma w rzeczywistości pewne zalety i wady. Moim osobistym punktem widzenia jest to, że oryginalny kod jest „wystarczająco czysty” dla większości kodu produkcyjnego, ale kod zrestrukturyzowany jest lepszy.
Kiedy wiedziałem, że muszę dodać coś do pierwszego wariantu, aby rosło coraz bardziej, wcześniej podzieliłem to na mniejsze funkcje, aby kod nawet nie zaczął się bałaganić.
źródło
validatingFields
to pola w formularzu, które mają sprawdzanie poprawności. Początkowo nazwałem je,fieldsWithValidation
ale było to trochę długie.Ogólnie nie ma poprawnej odpowiedzi w nazewnictwie. Wiele osób, gdy otrzyma dokładnie ten sam zestaw zadań, będzie bardzo różnie nazywać wynikowe funkcje i zmienne. Oczywiście chcesz, aby inni, którzy czytają Twój kod, zrozumieli, ale dłużej nie zawsze oznacza, że coś jest wyraźniejsze. Jeśli twój kod jest gęstszy, to musi nim być, to zajmie więcej czasu, aby zrozumieć, że nawet każda linia twoich funkcji jest tak przejrzysta i opisowa, jak to tylko możliwe.
Osobiście bardziej podoba mi się ten pierwszy przykład. Jest prosty i do tego stopnia, że zmienne nie mają tak opisowych nazw, jak w drugim przykładzie. Szczerze mówiąc, nazwy zmiennych w drugim przykładzie nie są o wiele jaśniejsze niż pierwsze, moim zdaniem, a krótka funkcja ułatwia zrozumienie samej funkcji.
Pod koniec dnia, co będzie lepsze, zależy od ciebie i od tego, z kim pracujesz. W końcu to on będzie go czytał i utrzymywał.
źródło