Ostatnim razem, gdy pisałem artykuł 7 Bad Code Smells In Typescript, spotkał się on z dużym zainteresowaniem i pochwałami. Dlatego myślę, że wiele osób chce wiedzieć więcej na ten temat i postanowiłem napisać o tym kolejny artykuł.
W tym artykule nie zamierzam powtarzać poprzednich zapachów złego kodu. Dzisiaj omówimy 5 innych koncepcji czystego kodu w TypeScript.
Jeśli funkcje wykonują więcej niż jedną rzecz, trudniej jest je zmieniać, testować i refaktoryzować.
Zła praktyka:
function updateDeprecatedDependencies(dependicies: Dependency[]) {
dependicies.forEach((dependency) => {
const dependencyVersion = getDependencyVersion(dependency);
if (dependencyVersion.isDeprecated()) {
upgradeDependency(dependency);
}
})
}
function updateDeprecatedDependencies(dependicies: Dependency[]) {
dependicies.filter(isDeprecatedDependency).forEach(upgradeDependency);
}
function isDeprecatedDependency(dependency: Dependency) {
const dependencyVersion = getDependencyVersion(dependency);
return dependencyVersion.isDeprecated();
}
Wyliczenia mogą pomóc w udokumentowaniu celu kodu.
Zła praktyka:
const MOBILE_OS= {
ANDROID: 'android',
IOS: 'iOS',
}
reactNative.run(MOBILE_OS.ANDROID);
class ReactNative {
// declaration of React Native
run(mobileOS) {
switch (mobileOS) {
case MOBILE.ANDROID:
// some logic to be executed
case MOBILE.IOS:
// some logic to be executed
}
}
}
enum MOBILE_OS {
ANDROID,
IOS,
}
reactNative.run(MOBILE_OS.ANDROID);
class ReactNative {
// declaration of ReactNative
run(mobileOS) {
switch (mobileOS) {
case MOBILE.ANDROID:
// some logic to be executed
case MOBILE.IOS:
// some logic to be executed
}
}
}
Jeśli otoczysz swój kod try/catch, oznacza to, że uważasz, że mógł wystąpić błąd i dlatego powinieneś zarejestrować błąd lub coś z nim zrobić.
Zła praktyka:
try {
functionThatMightThrow();
} catch (error) {
console.log(error);
}
// or even worse
try {
functionThatMightThrow();
} catch (error) {
// ignore error
}
import { logger } from './logging'
try {
functionThatMightThrow();
} catch (error) {
logger.log(error);
}
Jeśli masz niewykorzystany kod, pozbądź się go! Zostanie zachowany w Twojej historii wersji, jeśli nadal będziesz go potrzebować.
function unusedFunction(param: string) {
// ...
}
function newFunction(param: string) {
// ...
}
const result = newFunction();
function newFunction(param: string) {
// ...
}
const result = newFunction();
Użyj type, jeśli potrzebujesz unionlub intersection. Użyj interfacejeśli potrzebujesz extendslub implements.
Jeśli jesteś zainteresowany, możesz przeczytać więcej Interfaces vs Types.
Zła praktyka:
interface FrontendConfig {
// ...
}
interface BackendConfig {
// ...
}
interface Config {
// ...
}
//...
type Settings = {
// ...
}
type FrontendConfig = {
// ...
}
type BackendConfig = {
// ...
}
type Config = FrontendConfig | BackendConfig;
// ...
interface Settings {
// ...
}
class FrontendSettings implements Settings {
// ...
}
class BackendSettings implements Settings {
// ...
}
O czystym kodzie można mówić dużo, jeden artykuł to za mało. Jeśli jesteś zainteresowany, możesz również przeczytać więcej 7 Bad Code Smells In Typescript.
Dziękuję za przeczytanie, mam nadzieję, że ten artykuł był dla Ciebie przydatny. Miłego kodowania!
Kiedy wysyłasz żądanie do facebook.com, Twój komputer wyszukuje nazwę domeny, aby przetłumaczyć tę nazwę domeny na adres IP, aby komputer mógł nawiązać to połączenie.
Nasz język jest potężnym narzędziem, które może kształtować nasze myśli, postawy i działania. Nawet pozornie nieszkodliwe terminy mogą utrwalać szkodliwe uprzedzenia i stereotypy.
Kiedy dorastasz, zwykle słyszysz, że świat jest taki, jaki jest, a twoje życie polega na tym, by żyć swoim życiem w świecie, nigdy nie ryzykując życia, po prostu podążaj wyznaczoną ścieżką i umrzyj w końcu i staraj się nie za bardzo walnij w ściany. Ale to bardzo ograniczone życie.
Swędzenie w mojej dłoni rozszerzyło się, gdy targowałem się z miejscowym księgarzem o kolejną książkę. Ta książka, podobnie jak pozostałe, które ostatnio kupiłem, znalazłaby swój tron na moim stosie „Do przeczytania” (TBR); a mimo to kupiłem.
Hej, cyberentuzjaści! Witamy ponownie w serii OSINT poświęconej polowaniu na zagrożenia. W pierwszym artykule przedstawiłem przegląd OSINT i jego znaczenie w polowaniu na zagrożenia.
[Ostrzeżenie: ten esej zawiera zrzuty ekranowe ludzi wychwalających mordercę Jordana Neely'ego.] Funkcjonariusze organów ścigania w końcu - i być może niechętnie - oskarżyli Daniela Penny'ego, człowieka, który dusił Jordana Neely'ego aż do śmierci, o to zabójstwo.