Ma arról fogunk beszélni, hogyan kell kinéznie a kódnak, amihez szép, olvasható kód szükséges.

Annak ellenére, hogy a programot gép hajtja végre, a programkódot emberek írják és emberek számára - nem véletlen, hogy a magas szintű programozási nyelvek ember által olvasható szintaxissal és parancsokkal rendelkeznek. A modern szoftverprojekteket programozók csoportjai fejlesztik, néha nemcsak irodaterületek, hanem kontinensek és óceánok is elválasztják őket egymástól. Szerencsére a technológiai fejlettség szintje lehetővé teszi a legjobb fejlesztők készségeinek alkalmazását, függetlenül a munkáltatók elhelyezkedésétől. Ez a fejlesztési megközelítés komoly követelményeket támaszt a kód minőségével, különösen annak olvashatóságával és érthetőségével szemben.

A kódminőségi kritériumoknak számos jól ismert megközelítése létezik, amelyeket előbb-utóbb szinte minden fejlesztő megismer. Például vannak olyan programozók, akik betartják a KISS (Keep It Simple, Stupid!) tervezési elvet. Ez a fejlesztési módszer meglehetősen igazságos és tiszteletet érdemel, és tükrözi is egyetemes szabály jó kód - egyszerűség és áttekinthetőség. Az egyszerűségnek azonban korlátai vannak – a program rendje és a kód olvashatósága nem lehet az egyszerűsítés eredménye. Az egyszerűségen kívül van még néhány egyszerű szabály. És számos problémát megoldanak.

• Könnyű kódlefedettséget biztosít tesztekkel és hibakereséssel. Az egységtesztelés a modulok, azaz a program részét képező függvények és osztályok tesztelésének folyamata. A program létrehozásakor a fejlesztőnek a kódírás legelejétől mérlegelnie kell a tesztelés lehetőségét.
• A kód észlelésének és a program használatának megkönnyítése. Ezt elősegíti a logikus elnevezés, valamint a jó interfész és megvalósítási stílus.
• Biztosítsa az egyszerű nyomon követést. A program átgondolt és megvalósított felépítése lehetővé teszi, hogy a program működésével kapcsolatos kérdéseket újon oldja meg. hardver vagy egy új platform.
• Egyszerűsítse a további változtatások folyamatát. Minél optimalizáltabb a szerkezet, annál könnyebb a kód megváltoztatása, új szolgáltatások hozzáadása, a teljesítmény javítása és az architektúra megváltoztatása.
• Biztosítsa a program fenntarthatóságát. Ha változtatásokat hajt végre, vagy problémák merülnek fel, könnyen elvégezheti a javításokat. A megfelelő hibakezelés pedig nagyban megkönnyíti a szoftvertermék működését.
• Győződjön meg arról, hogy a projektet több fejlesztő vagy teljes közösség is támogathatja (különösen fontos a nyílt forráskódú projekteknél).

Bármilyen kód egy fejlesztő ötleteinek megvalósítása egy meghatározott céllal: szórakoztatás létrehozása, vállalati szoftverek írása, programozási ismeretek fejlesztése, ipari szoftverek létrehozása stb. egy ilyen szokás a programozó számára is beválik, minél intenzívebben éri el a projekt nagy léptéket.

A jó kód kritériumai a programozásban - 8 szabály a GeekBrains-től

Kövessen egyetlen kódstílust. Ha egy programozó egy szervezetben dolgozik, különösen egy nagy szervezetben, akkor leggyakrabban megismertetik egy adott projektben a kód formázásának szabályaival (kódstílus-egyezmény). Ez nem a munkáltató véletlen szeszélye, hanem a komoly hozzáállás bizonyítéka.

Íme néhány Általános szabályok amivel találkozhatsz:

figyelje meg a göndör kapcsos zárójelek elválasztását és a behúzást – ez nagyban javítja az egyes kódblokkok észlelését
kövesse a függőleges szabályt – ugyanannak a lekérdezésnek vagy feltételnek ugyanabban a behúzásban kell lennie

if (typeof a ! == "undefined" &&
b típusú! == "meghatározatlan" &&
c típus === "karakterlánc") (
//a cuccaidat
}

figyelje meg a szóközt - tegyen szóközöket, ahol javítja a kód olvashatóságát; ez különösen fontos összetett körülmények között, például hurokfeltételek esetén.

for (var i = 0; i< 100; i++) {
}

Egyes fejlesztői környezetekben a kód formázási szabályait kezdetben a beállítások betöltésével állíthatja be külön fájl(Elérhető a Visual Studio-ban). Így a projekt minden programozója automatikusan ugyanazt a típusú kódot kapja, ami jelentősen javítja az észlelést. Köztudott, hogy sok év gyakorlása után meglehetősen nehéz újratanulni és megszokni az új szabályokat. Azonban minden vállalatnál a kódstílus egy törvény, amelyet szigorúan be kell tartani.

Ne használj "varázsszámokat". Nem véletlenül nevezik a mágikus számokat programozási antimintának, más szóval a programkód írásának szabályait. Leggyakrabban a mágikus szám mint antiminta a kódban használt állandó, amelynek jelentése megjegyzés nélkül nem egyértelmű. Az ilyen számok nemcsak megnehezítik a kód megértését és rontják annak olvashatóságát, hanem problémákat is okoznak az átalakítás során.

Például a kódban van egy sor:
DrawWindow(50, 70, 1000, 500);

Nyilvánvalóan nem fog hibát okozni a kódban, de a jelentése nem mindenki számára világos. Sokkal jobb, ha nem lustálkodunk, és azonnal írunk így:

int bal = 50;
int top = 70;
int szélesség = 1000;
int magasság = 500;
DrawWindow(bal, felső, szélesség, magasság);

Néha mágikus számok merülnek fel általánosan elfogadott állandók használatakor, például a π szám írásakor. Tegyük fel, hogy a projekt készült:

SquareCircle = 3,14*rad*rad

Mi a baj vele? De van rossz is. Például, ha a munka során nagy pontosságú számítást kell végeznie, akkor meg kell keresnie a konstans minden előfordulását a kódban, és ez munkaerő-források pazarlása. Szóval jobb, ha így írod:

const float pi = 3,14;
SquareCircle = pi rad rad

Egyébként előfordulhat, hogy a programozótársak nem emlékeznek az Ön által használt állandó értékére - akkor egyszerűen nem ismerik fel a kódban. Ezért jobb elkerülni a számok írását anélkül, hogy azokat változókban deklarálnák, és még az állandó értékeket is jobban deklarálják. Egyébként ezek az állandók szinte mindig a beépített könyvtárakban vannak, így a probléma magától megoldódik.

Használjon értelmes neveket változóknak, függvényeknek, osztályoknak. Minden programozó ismeri a "kód obfuszkáció" kifejezést - a program évének szándékos elhomályosítását egy obfuszkátor alkalmazás segítségével. Ez azért történik, hogy elrejtse a megvalósítást, és a kódot homályos karakterkészletté alakítja át, átnevezi a változókat, megváltoztatja a metódusok, függvények neveit stb... pont a változók és függvények értelmetlen nevei miatt: var_3698, myBestClass, NewMethodFinal, stb... Ez nem csak a projektben közreműködő fejlesztők útjában áll, hanem végtelen mennyiségű kommentárhoz is vezet. Eközben a függvény átnevezésével megszabadulhat a megjegyzésektől – a neve maga fogja mondani, hogy mit csinál.

Az úgynevezett öndokumentáló kód ki fog derülni - olyan helyzet, amelyben a változókat és a függvényeket úgy nevezik el, hogy a kód megnézésekor egyértelmű, hogyan működik. Az öndokumentáló kód ötletének számos támogatója és ellenzője van, akiknek érveit érdemes meghallgatni. Általában azt javasoljuk, hogy találjon egyensúlyt, és okosan használja mind a megjegyzéseket, a "beszélő" változóneveket, mind az öndokumentáló kódfunkciókat, ahol indokolt.

Vegyünk például egy ilyen kódot:

// keresse meg a levelet, írjon r-re
if (x != null) (
while (x.a != null) (
x = x.a;
r = x.n;
}
}
más(
r = "";
}

A megjegyzésből egyértelműnek kell lennie, hogy pontosan mit csinál a kód. De egyáltalán nem világos, hogy az x.a és az x.n mit jelent. Próbáljunk meg a következőképpen módosítani:
// keresse meg a levelet, írja be a nevet a leafName-ba
if (csomópont != null) (
while (node.next != null) (
csomópont = csomópont.next;
levélnév = csomópont.név;
}
}
más(
levélnév = "";
}

Ezen a ponton külön ki kell emelni a megjegyzéseket, hiszen a hallgatók mindig sok kérdést tesznek fel használatuk helyénvalóságáról és szükségességéről. Ha sok a megjegyzés, az rossz kódolvashatóságot eredményez. Szinte mindig lehetséges a kód módosítása úgy, hogy nincs szükség megjegyzésekre. Nagy projekteknél az API használata esetén indokolt a megjegyzés, jelezve a harmadik féltől származó modulok kódjának csatlakoztatását, megjelölve a vitás pontokat vagy további feldolgozást igénylő pontokat.

Összítsünk még két fontos szabályt egyetlen pontosításba. Hozzon létre olyan módszereket, mint új szintértelmes elnevezésű absztrakciókÉs a módszereket kompakt legyen.Általánosságban elmondható, hogy ma a kód modularitása minden programozó számára elérhető, ami azt jelenti, hogy ahol lehetséges, törekedni kell absztrakciók létrehozására. Az absztrakció az egyik módja a funkcionalitás megvalósítási részleteinek elrejtésének. Különálló kis metódusok létrehozásával a programozó jó kódot kap, blokkokra osztva, amelyek az egyes funkciók megvalósítását tartalmazzák. Ez a megközelítés gyakran növeli a kódsorok számát. Vannak még bizonyos ajánlások is, amelyek a módszer hosszát legfeljebb 10 sorral jelzik. Természetesen az egyes módszerek mérete teljes mértékben a fejlesztőtől függ, és számos tényezőtől függ. Tanácsunk: egyszerű, legyen a módszer kompakt, hogy egy módszer egy feladatot végezzen. Az egyes távoli entitások könnyebben javíthatók, például közvetlenül a metódus elejére beillesztve a bemeneti adatok érvényesítését.

E szabályok szemléltetésére vegyük az előző bekezdés példáját, és hozzunk létre egy metódust, amelynek kódja nem igényel megjegyzéseket:
string GetLeafName(Csomópont csomópont)(
if (csomópont != null) (
while (node.next != null) (
csomópont = csomópont.next;
}
return node.name;
}
Visszatérés"";
}

Végül pedig rejtse el a módszer megvalósítását:

LeafName = Get LeafName(csomópont); …

Ellenőrizze a bemenetet a metódusok elején. A kód szintjén feltétlenül el kell végezni a bemeneti adatok ellenőrzését az összes vagy majdnem minden módszerben. Ennek oka a felhasználói viselkedés: a jövőbeli felhasználók bármilyen adatot megadhatnak, amely a program összeomlását okozhatja. Bármilyen módszernél, még akkor is, ha csak egyszer használták, feltétlenül meg kell szervezni az adatok érvényesítését és létrehozni a hibakezelést. Ezt azért érdemes megtenni, mert a metódus nem csak absztrakciós rétegként működik, hanem az újrafelhasználáshoz is szükséges. Elvileg fel lehet osztani a módszereket azokra, amelyekben ellenőrizni kell, és olyanokra, amelyekben ezt nem szükséges megtenni, de a teljes bizalom és a „ravasz felhasználó” elleni védelem érdekében jobb, ha mindent ellenőriz. beviteli adat.

Az alábbi példában egy ellenőrzést szúrunk be annak biztosítására, hogy a bemenet ne kapjon nullát.
GetEvenItems(listaelemek) listázása (
assert(elemek != null);

Lista eredmény = new List();
foreach (int i a tételekben) (
if (i % 2 == 0) (
eredmény.add(i);
}
}
visszatérési eredmény;
}

Csak a "van" kapcsolatot valósítsa meg az örökléssel. Egyébként összetétel. A kompozíció az egyik kulcsfontosságú minta, amelynek célja a kód könnyebb olvashatósága, és az öröklődéssel ellentétben nem sérti a beágyazás elvét. Tegyük fel, hogy van egy Kormányosztálya és egy Kerék osztálya. A Car osztály megvalósítható a Rudder ősosztály leszármazottjaként, de az Autónak is szüksége van a Wheel osztály tulajdonságaira.

Ennek megfelelően a programozó elkezdi az öröklést. De a Car osztály még a szűk látókörű logika szempontjából is elemek összetétele. Tegyük fel, hogy van ilyen kód, amikor egy új osztály jön létre örökléssel (a ScreenElement osztály örökli a Coordinate osztály mezőit és metódusait, és kiterjeszti ezt az osztályt):

Osztály koordináta (
nyilvános intx;
nyilvános int y;
}
osztály Képernyőelem: Koordináta(
nyilvános karakter szimbólum;
}

Használjuk a kompozíciót:
Osztály koordináta (
nyilvános intx;
nyilvános int y;
}
osztály ScreenElement(
nyilvános koordináta;
nyilvános karakter szimbólum;
}

A kompozíció jó helyettesítője az öröklődésnek, ez a minta könnyebb az írott kód további megértéséhez. Kövesse ezt a szabályt: csak akkor válassza az öröklődést, ha a kívánt osztály hasonló az ősosztályhoz, és nem használja más osztályok metódusait. Ezenkívül a kompozíció még egy problémától kíméli meg a programozót - kiküszöböli az öröklődés során fellépő névütközést. A kompozíciónak van egy hátránya is: az objektumok számának megsokszorozása hatással lehet a teljesítményre. De ez ismét a projekt hatókörétől függ, és ezt a fejlesztőnek eseti alapon kell értékelnie.

Külön felület a megvalósítástól. A programban használt bármely osztály egy interfészből (ami elérhető az osztály kívülről történő használatakor) és egy megvalósításból (metódusok) áll. A kódban az interfészt el kell különíteni a megvalósítástól, mind az OOP egyik alapelvének, a beágyazásnak való megfelelés, mind a kód olvashatóságának javítása érdekében.

Vegyünk egy osztályt:

osztályú tér (nyilvános úszó szél; nyilvános úszótér; )

Egy másik osztály:

osztály négyzet( nyilvános lebegő GetEdge(); nyilvános lebegő GetArea(); public void SetEdge( úszó e) ; public void SetArea( úszó a) ; privát úszó él; privát úszóterület; )

A második eset előnyösebb, mert elrejti a megvalósítást a privát hozzáférés módosítóval. A kód olvashatóságának javítása mellett az interfész leválasztása az implementációtól, az interfész kicsiben tartásával párosulva van még egy fontos előnye: a program meghibásodása esetén csak néhány funkciót kell ellenőrizni, hogy megtaláljuk a hiba okát. Minél nyitottabbak a függvények és adatok, annál nehezebb nyomon követni a hiba forrását. A felületnek azonban teljesnek kell lennie, és lehetővé kell tennie, hogy bármit megtegyen, különben használhatatlan.

A webináriumon elhangzott a kérdés: „Lehet-e azonnal jól írni, és nem reflektálni?” Valószínűleg néhány év vagy akár évtized programozás alatt ez lehetséges lesz, különösen, ha van egy kezdeti elképzelés a program architektúráról. De soha nem láthatja előre a projekt végső állapotát számos kiadás és finomítási iteráció révén. Ezért fontos, hogy mindig emlékezzen ezekre a szabályokra, amelyek garantálják programja fenntarthatóságát és fejlődési képességét.

A programozók felvétele témájában írt cikkek többsége nagyjából ugyanúgy hangzik. Általában az ilyen cikkek azt javasolják, hogy „csak a legjobbakat vegyék fel”. Bevallom, hogy nem vagyok elégedett ezzel a tanáccsal, mert túl homályosan hangzik. Ez olyan, mintha egy autókereskedésbe érkeznél és megkérdeznéd az eladótól, hogy milyen autót ajánlana neked, ő pedig azt válaszolná, hogy az autókereskedésben egyetlen autónál sem szerepel a "Legjobb" felirat.

Kérem, ne értsen félre, nem azt tanácsolom, hogy szándékosan keressen középszerű programozókat. Természetesen mindenki csak a legtehetségesebb és legtapasztaltabb programozókat akarja felvenni. A felvételi döntéseknél nagy a tét. Döntése az egész csapat és egyes tagjainak munkáját érinti. Ahogy mondják:

"Sokkal jobb elutasítani egy jó jelöltet, mint elfogadni egy rosszat... Ha a legcsekélyebb kétségei vannak, ne alkalmazzon."

De a szokásos tanácsok még mindig idegesítenek. Nem is annyira maga a tanács, hanem az a tény, hogy az emberek hajlamosak félreérteni. Ha további módosítások nélkül alkalmazzák, ez a gyakorlat alapvetően a felsőbbrendűség érzését kelti. Ez a hatás különösen gyakori a programozók körében, mivel az elitizmus valamilyen módon velünk van. Amikor azt halljuk, hogy csak a „legjobbakat” szabad felvenni, ez a tanács tudatalatti átalakuláson megy keresztül:

"A leges legjobb?" De én vagyok! Én vagyok a legjobb". Természetesen olyan tehetséges, okos és szimpatikus embereket kell felvennem, mint én. És minek szemetelni a kiváló csapatomat mindenféle garázdasággal?

Kik a legjobb programozók?

Természetesen ez a megközelítés nem teremti meg a legjobb feltételeket a döntéshozatalhoz. A standard szabály sokkal jobban működik, ha egy kicsit másképp értelmezed:

„A lehető leghatékonyabb csapatot szeretném kialakítani. Egy további alkalmazott felvételével nem csak a létszám számbeli bővítésére törekszem. Minden alkalmazottnak valamilyen módon javítania kell a csapatomat. Nem keresek olyan tehetséges embert, mint én. Inkább olyan férfira van szükségem, aki legalább egy fontos irányban tehetségesebb nálam.

Főnök

A legrosszabb főnök az, aki fenyegetve érzi magát a csapata miatt. Tudatosan vagy sem, a "legjobbtól" fél, ezért folyamatosan olyan embereket alkalmaz, akikkel szemben előnyösnek tűnik.

Valószínűleg nagy cégben élhetsz ezzel a megközelítéssel. Erősen gyanítom, hogy a Dilbert-képregényben szereplő Shaggy Boss az életből származik.

De a kis szoftverfejlesztő cégek világában a dolgok egészen másként működnek. Ha Ön egy kis cég alapítója vagy „vezető guruja”, vessen gondos, őszinte és tárgyilagos pillantást önmagára. Ha Ön azok közé tartozik, akik fenyegetve érzik magukat saját alkalmazottaikkal szemben, álljanak meg és gondolkozzatok. Amíg nem sikerül megoldani ezt a problémát, nulla az esélye egy hatékony csapat felépítésének.

A programozók személyzete

A standard szabály valódi jelentése nem az egónk szórakoztatása, hanem az, hogy emlékeztessen bennünket, hogy ne féljünk jobb alkalmazottakat keresni. Mégis pontosabban ki kell deríteni, mit is jelent valójában a „legjobb” szó.

Keress olyan embereket, akik hajlamosak az önvizsgálatra

A "legjobb" munkások soha nem hagyják abba a tanulást.

A jelöltek értékelése során az egyik legfontosabb kritériumnak azt tartom, amit magam is "első származéknak" nevezek. Ez a személy tanul? Előre halad vagy áll? (E témával kapcsolatos gondolataim egy részét a blogom Karrierkalkulus című cikkében közöljük).

Azok, akik komolyan gondolják jövőbeli sikereiket, nagyobb valószínűséggel járnak sikerrel. Ez a gondolkodásmód gyakran a legerősebb jele a munkaerő-felvételi döntéseknek.

Ez nem jelenti azt, hogy csak azokat kell felvenni, akik sikeresek akarnak lenni. Minden ember sikeres akar lenni. Azt tanácsolom, hogy olyan embereket vegyenek fel, akik komolyan gondolják a folyamatos tanulást. Ezek az emberek nem vesztegetik az idejüket azzal, hogy meggyőzzék, mennyit tudnak. Nem a múltra koncentrálnak, nem a jövőre. Amíg Ön interjút készít velük, ők interjút készítenek Önnel, hogy megnézzék, mit tanulhatnak tőled.

Hogyan lehet ilyen embert találni?

Az egyik kiemelkedő jellemzője, hogy az állandó tanulásra elszánt emberek jól tudják, mit nem tudnak. Ismerik gyengeségeiket, és nem félnek beszélni róluk.

Az interjúk során a jelöltet gyakran megkérik, hogy írja le fő gyengeségét. Bár ez a kérdés rettenetesen hagyományos, nekem tetszik.

Sajnos sok jelölt megpróbálja kibújni a válasz elől. Elmennek egy könyvesboltba, és vesznek egy könyvet az interjúkészítésről. A könyv figyelmeztet, hogy felteszem nekik ezt a kérdést, és "kreatív" módszereket kínál az őszinte válasz elkerülésére:

• Néha túl keményen dolgozom.
• Néha a részletekre való figyelmem bosszantja a zenekar többi tagját.

Amikor megkérek egy jelöltet, hogy beszéljen a gyengeségeiről, intelligens, őszinte és magabiztos választ várok. Ha azt hallom, hogy egy jelölt beismeri gyengeségét, az nagy benyomást kelt. De ha egy jelölt egyenesen egy könyvből kitérő választ ad, akkor elkezdek gondolkodni a következő jelölten.

Béreljen fejlesztőket, ne programozókat

Egy kis cégnél a "legjobb" programozók azok, akik nem korlátozódnak magára a programozásra. Próbálj fejlesztőket felvenni, ne programozókat. Bár ezeket a szavakat gyakran felcserélhetően használják, különbséget teszek közöttük. Ez körülbelül az egyszerű programozás és a termékcsapat tagság közötti különbségről. Íme egy idézet egy cikkből, amelyet ebben a témában írtam a blogomon:

„Ebben a cikkben a „programozó” olyan valakire vonatkozik, aki kizárólag az új funkciók kódolásával és [ha szerencséd van] a hibák kijavításával foglalkozik. A programozók nem írnak specifikációkat. Nem hoznak létre automatizált teszteseteket. Nem segítenek támogatni automatizált rendszerek az építmények naprakészek. Nem segítik az ügyfeleket a döntésben technikai problémák. Nem segítenek a dokumentáció írásában, nem vesznek részt a tesztelésben, és még a kódot sem olvassák el. Csak új kódot írnak. Nem érdemes ilyeneket kis társaságban tartani.

A „programozók” (a kódírásra szakosodott emberek) helyett „fejlesztőkre” van szükség (olyan emberekre, akik sokféleképpen járulnak hozzá a termék sikeréhez).

Mit jelent a standard szabály? Milyen tulajdonságot kell mérni annak megállapításához, hogy egy jelölt a „legjobb”-e?

Ez a szabály általában csak a kódolási készségekkel kapcsolatban értendő. De az igazán jó programozók okosak. Megértik azokat a dolgokat, amelyeket általában nem tanítanak, és 10-szer hatékonyabban tudnak dolgozni, mint egy átlagos programozó. Természetesen bölcs dolog lenne egy ilyen "10x" személyiséget keresni, különösen nagy szervezetekben, ahol az olyan szakemberek, mint a "tiszta" programozók, meglehetősen megfelelőek. De egy kis cégnél sokoldalúságra van szükség. Gyakran megkövetelik, hogy a csapattagok több funkciót is végrehajtsanak, nem korlátozódnak a kód írására. Ilyenkor nagyon fontos megtalálni a legjobb fejlesztőt, és ez az ember nem feltétlenül a legjobb programozó.

Tehát a szabványos szabály meglehetősen jól működik, de az általános ajánlásokról át kell térni a konkrétabbakra. Az előző részekben elmondottak összegzéseként íme 10 kérdés, amelyet fel kell tennie magának, amikor fejlesztőjelöltként gondolkodik:

1. Megtehet-e ez a jelölt a csoportért azt, amit senki más nem?
2. Folyamatos tanulási folyamatban van?
3. Tisztában van-e ez a jelölt a gyengeségeivel, és nyugodtan meg tudja beszélni azokat?
4. Mennyire sokoldalú ez a jelölt, és mennyire képes „bármit megtenni”, hogy biztosítsa a termék kereskedelmi sikerét?
5. A jelölt a "tízszeres" programozók számához tartozik?
6. Van alapdiplomája egy jó hírű egyetemen?
7. Ha a jelölt PhD fokozattal rendelkezik, van-e egyéb jele annak, hogy képes kereskedelmi termékeket fejleszteni?
8. Van-e a jelöltnek tapasztalata kereskedelmi termékeket fejlesztő csapatokban végzett munka során?
9. Tud-e a jelölt példákat mondani a jó kódra?
10. A jelölt annyira élvezi a programozást, hogy szabadidejében kódot írjon?

Nem szükséges mind a 10 kérdésre pozitív válasz. Nem is fogom megmondani, hány pozitív válasz szükséges egy jelölt elfogadásához. A felvétel egy sorsolás, és minden kérdés jelként szolgálhat a jelölt alkalmasságának értékeléséhez.

Végső soron a munkaerő-felvétel terén minden döntést akarat alapján hozzák meg, és itt semmilyen garanciára nincs lehetőség. És mégis, ha ezekre a kérdésekre odafigyel, növeli annak valószínűségét, hogy később nem kell megbánnia a döntését.

Tehát most gondja van, ha olyan könyvtárat ír, amelyet mind a régi iskolai kód, amely wchar_t-vel írt, mint az unsigned short álneve, és az új iskolai kód, amely a wchar_t-vel külön belső típusként van írva. Milyen adattípust kell használni a karakterlánc-paraméterekhez?

Ez a Visual C++ Unicode printf-stílusú formátumspecifikátorainak szomorú története fordítása.

A Windows Unicode implementációja a legtöbb előtt operációs rendszer. Ennek eredményeként Windows megoldások mert sok probléma különbözik azok döntéseitől, akik a por leülepedésére vártak¹. Ennek legvilágosabb példája az Windows használat UCS-2 Unicode kódolásként. Akkoriban ezt a kódolást javasolta a Unicode Consortium, mert a Unicode 1.0 csak 65"536 karaktert támogatott². A Unicode Consortium öt évvel később meggondolta magát, de akkor már késő volt a Windows számára, amely már kiadta a Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 és Windows 95 – mindegyik UCS-2³-t használt.

De ma a printf-stílusú formátumú karakterláncokról fogunk beszélni.

Ez a fordítása: Ha a FlushInstructionCache nem csinál semmit, miért kell ezt újranézni.

A FlushInstructionCache függvényt akkor kell meghívnia, amikor futtatható kódot generál vagy módosít futás közben – hogy a processzor a generált/módosított kód végrehajtásakor az Ön által írt utasításokat olvassa el, és ne a régi utasításokat, amelyek a processzorban maradhatnak. utasítás gyorsítótár.

Ezt korábban megtanultuk. Ennek az az oka, hogy egy egyszerű függvényhívás elegendő volt a parancs-gyorsítótár törléséhez.

Windows NT rendszeren azonban a FlushInstructionCache funkció igen igazi munka, mert értesítenie kell az összes többi processzort, hogy kiürítse gyorsítótárát.

Ha azonban megnézi a Windows 10-et, azt fogja tapasztalni, hogy a FlushInstructionCache függvény úgy néz ki, mint a Windows 95 verziója: nem csinál semmit.

mi a baj itt?

Az utóbbi időben kevés igazán jó kódot láttam, sok közepes és Nagyon sok rossz. (Amit korábban írtam - főleg amikor elkezdtem - sajnos az utóbbihoz tartozik.) Véletlenszerű cikkeket olvasgatva az interneten és szakmai könyvekben arra a következtetésre jutottam, hogy jó kódot írni könnyű. Hihetetlenül nehéz, de ugyanakkor könnyű. Valójában ez annyira egyszerű, hogy három szabályon alapul.

1. Írj kódot embereknek, ne gépeknek.
2. Minden kódrészletnek egy feladatot kell végrehajtania.

Ha ezeket következetesen követi, akkor jó kódot fog írni. Bármilyen programozási nyelven és bármilyen paradigmában. A probléma az, hogy nagyon nehéz. Mindegyik fegyelmet igényel, az utolsó kettő pedig a legtöbb esetben hosszas reflexiót is igényel.

Írj kódot embereknek, ne gépeknek

Ez a legfontosabb a három szabály közül, és a másik kettő alapja. Írjon olyan kódot, amely egyszerű az ember számára; hagyja a nehéz munkát a számítógépre. Használjon értelmes változó- és metódusneveket. Ne hozzon létre zavaró logikai láncokat, ahol egyszerűek is alkalmazhatók. Ne próbáljon a lehető legtöbbet egy sorba illeszteni. Figyeld meg egységes stílusértelmes behúzással rendelkező kód írása. Ha a fájlok olyan terjedelmesek, hogy nehéz lesz görgetni őket, bontsa fel őket több kisebbre.

Sok programozó megpróbál olyat írni, ami véleményük szerint gyorsabban működik, csökkenti az alkalmazás méretét - egyszóval „könnyíti” a számítógép munkáját. Ez nagyszerű, de ne felejtsd el, hogy sokkal fontosabb olyan kódot írni, amely könnyen olvasható és karbantartható mások számára.

A fordítója (vagy tolmácsa) teljesen különböző stílusú kódokat képes kezelni. Neki nÉs objektumok száma- Ez ugyanaz. Az emberek számára nem. Sok időbe telik beolvasni a kódot, még akkor is, ha a változó célja nyilvánvalónak tűnik az Ön számára.

Képzeld el, hogy készítettél egy kis forgatókönyvet magadnak, és néhány év múlva egy kicsit módosítanod kellett. Mit látnál szívesebben: egy jól strukturált szkriptet, megjegyzésekkel és egyértelmű névvel, vagy egy függvényt egyetlen megjegyzés nélkül és olyan változókkal, amelyek célját szinte lehetetlen megérteni?

Ha valami nem nyilvánvalót tesz egy kódrészlet optimalizálása érdekében, írja le megjegyzésben, hogy pontosan mit csinál. De ne felejtsd el, hogy a legtöbb esetben nem tudod jobban optimalizálni a programot, mint a fordítót. A valóság az, hogy ő okosabb nálad. Tény: a fordítókat több évtizedes kemény munka során fejlesztették a szakemberek. Vannak kivételek, de ezek csak erősítik a szabályt.

Írjon olyan kódot, amelyet az emberek megértenek.

Ne ismételd magad

Nem tudom megszámolni, hányszor láttam ugyanazt a kódrészletet a program különböző részeiben. Éppen ma dolgoztam egy nagy függvényen a régi kódban, és ugyanazokat a feltételeket láttam a feltételes két különböző részében. Időt kellett szánnom, hogy megbizonyosodjak arról, hogy ez csak programozói hiba.

Ha ugyanazt a töredéket több helyen megismétli, előbb-utóbb vissza kell térnie ahhoz, hogy kijavítson valamilyen hibát, vagy valami újat adjon hozzá. Ez megnehezíti a kód karbantartását. Ahelyett, hogy ismételné magát, helyezze a töredéket egy külön osztályba vagy függvénybe, amely szükség szerint meghívható. Ha több metódust hív meg ugyanabban a sorrendben, különböző helyeken, csomagolja be egy külön függvénybe.

Gondoljon arra, hogy mi lenne könnyebben érthető, ha megnézi a kódot: egy 30 soros részlet, amely memóriablokkot szabadít fel, vagy egy függvényhívás clearMapVariableMemory()?
Lehet, hogy később át kell tanulmányoznia a kódrészletet, de akkor is könnyebb lesz egyetlen funkcióval dolgozni.

Ugyanez az elv alkalmazható az adatokra is. Ha gyakran használja ugyanazokat a változókat, helyezze át őket egy másik osztályba vagy adattípusba.

Ha betartja ezt a szabályt, minden változtatás univerzális lesz – nem kell több tucat helyet átdolgoznia egy kis javításhoz.

Ne ismételd magad.

Minden kódrészletnek egy feladatot kell végrehajtania

Az utolsó szabály az előző kettőre épül: A kód minden darabjának csak egy dolgot kell tennie. Ez minden szinten igaz: kifejezésekre, függvényekre és metódusokra, osztályokra és objektumokra.

Néhány évvel ezelőtt egy fejlesztő mutatott egy kódrészletet, ami nem működött. A programozónak több órába telt, mire rájött. Ennek eredményeként a problémát a posztinkrementális C utasításokban találták meg (speciális esetekben fordítóról fordítóra eltérő a viselkedésük). Ezt követően egy fejlesztésről szóló könyv olvasása közben észrevettem, hogy az igazi probléma nem az állításokkal van, hanem azzal, hogy egy töredék sok különböző feladat elvégzéséért felelős.

Ha jól emlékszem, a hibát tartalmazó sor egy hármas művelet része volt. Ez viszont számos műveletet hajtott végre a mutatókon a feltétel kiszámításához, és még néhányat, a feltételes kifejezés eredményétől függően. Ez volt jó példa kód írása elsősorban a gépnek, nem az embernek: a töredék szerzőjén kívül senki nem fogja megérteni, hogy pontosan mit csinál a sor, még többszöri elolvasása után sem. Ha a programozó, aki a kódot írta, több részre bontotta volna a logikát, sokkal kevesebb időbe telt volna a probléma megoldása.

Nem szabad ugyanabban a módszerben kivonni, feldolgozni és módosítani az adatokat. Az egyes funkciók szóbeli leírásának egy mondatba kell illeszkednie. Minden sor céljának egyértelműnek kell lennie. Ez érthetővé teszi a kódot az emberek számára. Egyikünk sem tud több ezer soros függvényt eltárolni a fejében. Arra sincs jelentős ok, hogy több, együtt használt kis módszer helyett ilyen függvényeket hozzunk létre.

Meg kell jegyezni, hogy ez nem olyan nehéz: egy nagy feladat elvégzéséhez csak több kisebbre kell felosztani, amelyek mindegyike külön funkciót tölt be. Fontos, hogy minden funkció célja világos maradjon, különben a kód túlságosan zavaró lesz.

A kód minden egyes darabjának egy feladatot kell végrehajtania.

Következtetés

Jó kódot írni kemény munka. Négy éve programozom – nem olyan sokáig, de elég sokáig ahhoz, hogy jó néhány problémát láthassak, beleértve a sajátomat is. Világossá vált számomra, hogy ezek figyelmen kívül hagyásával bonyolítjuk a fejlesztést egyszerű szabályok. Megfelelő megfigyelésük nehéz: nem mindig egyértelmű, hogy hol van szükség külön osztályra vagy metódusra. Ez egy készség. Sok időbe telik, mire jó programozóvá válik. De ha nem tartjuk be ezeket a szabályokat, a kód írása és karbantartása még nehezebbé válik.

Cikk fordítás

15 szabály a minőségi kód írására

Számtalan módja van a rossz kód írásának. Szerencsére a minőségi kód szintjére emelkedéshez elegendő 15 szabályt betartani. Megfigyelésük nem tesz mesterré, de lehetővé teszi, hogy meggyőzően utánozza őt.

1. szabály Kövesse a kódolási szabványokat.

Minden programozási nyelvnek megvan a saját kódformázási szabványa, amely megmondja, hogyan kell behúzni, hová kell tenni a szóközöket és a zárójeleket, hogyan kell elnevezni az objektumokat, hogyan kell megjegyzést írni stb.

Például ebben a kódrészletben a szabvány szerint 12 hiba található:

For(i=0 ;i

Tanulmányozza figyelmesen a szabványt, tanulja meg fejből az alapokat, kövesse a szabályokat, mint parancsolatokat, és a programjai jobbak lesznek, mint a legtöbb diplomás.

Sok szervezet egyedi igényei szerint alakítja ki a szabványokat. A Google például több mint 12 programozási nyelvre dolgozott ki szabványokat. Jól átgondoltak, ezért nézze meg őket, ha segítségre van szüksége a Google programozásában. A szabványok tartalmaznak még szerkesztőbeállításokat is, amelyek segítenek követni a stílust, és speciális eszközöket is tartalmaznak annak ellenőrzésére, hogy a kód megfelel-e az adott stílusnak. Használd őket.

2. szabály. Adjon leíró neveket.

A lassú, ügyetlen teletípusokra korlátozódó ősi programozók szerződéseket használtak változó- és eljárásnevekre, hogy időt, billentyűleütéseket, tintát és papírt takarítsanak meg. Ez a kultúra bizonyos közösségekben jelen van a visszafelé kompatibilitás fenntartása érdekében. Vegyük például a wcscspn nyelvtörő C függvényt (széles karakterlánc-komplement span). De ez a megközelítés nem alkalmazható a modern kódban.

Használjon hosszú, leíró neveket, például a komplementSpanLength, hogy segítsen magának és másoknak megérteni a kódot a jövőben. A kivételek a metódusok törzsében használt néhány fontos változó, például a ciklusiterátorok, a paraméterek, az ideiglenes értékek vagy a végrehajtási eredmények.

Sokkal fontosabb, hogy hosszan gondolkodjon, mielőtt megnevez valamit. Pontos a név? A legmagasabb árra vagy a legjobb árra gondolt? Elég specifikus-e a név ahhoz, hogy ne használjuk más kontextusban a hasonló jelentésű objektumok esetében? Nem lenne jobb a getBest helyett a getBestPrice metódust hívni? Jobban illik, mint a többi hasonló név? Ha rendelkezik ReadEventLog metódussal, ne hívjon meg másik NetErrorLogReadot. Ha meghív egy függvényt, a neve leírja a visszatérési értéket?

Végül néhány egyszerű elnevezési szabály. Az osztály- és típusneveknek főneveknek kell lenniük. A metódus nevének tartalmaznia kell egy igét. Ha egy metódus meghatározza, hogy egy objektum bizonyos információi igazak vagy hamisak, akkor a nevének "is"-vel kell kezdődnie. Az objektumtulajdonságokat visszaadó metódusoknak „get”, a tulajdonságértékeket beállító metódusoknak pedig „set” szóval kell kezdődniük.

3. szabály: Megjegyzés és dokumentum.

Minden metódust és eljárást indítson el egy megjegyzésben található leírással arról, hogy a metódus vagy eljárás mit csinál, paramétereket, visszatérési értéket és lehetséges hibákatés kivételek. Írja le a megjegyzésekben az egyes fájlok és osztályok szerepét, az egyes osztálymezők tartalmát, valamint a komplex kód főbb lépéseit! Írjon megjegyzéseket a kód fejlesztése során. Ha azt hiszed, hogy később megírod, akkor becsapod magad.

Ezenkívül győződjön meg arról, hogy az alkalmazás vagy a könyvtár rendelkezik egy kézikönyvvel, amely elmagyarázza a kód működését, meghatározza a függőségeit, és útmutatást ad a kód létrehozásához, teszteléséhez, telepítéséhez és használatához. A dokumentum legyen rövid és praktikus; gyakran elég egy README fájl.

4. szabály: Ne ismételd magad.

Soha ne másoljon és illesszen be kódot. Ehelyett bontsa ki a közös részt egy metódusba vagy osztályba (vagy makróba, ha szükséges), és használja a megfelelő paraméterekkel. Kerülje a hasonló adatok és kódrészletek használatát. Használja a következő technikákat is:

• Hozzon létre API-referenciákat megjegyzésekből a Javadoc és a Doxygen használatával.
• Egységtesztek automatikus generálása annotációk vagy elnevezési konvenciók alapján.
• PDF és HTML létrehozása ugyanabból a jelölőforrásból.
• Az osztálystruktúra lekérése az adatbázisból (vagy fordítva).

5. szabály: Ellenőrizze a hibákat, és reagáljon rájuk.

A módszerek hibajelzéseket adhatnak vissza, vagy kivételeket dobhatnak. Feldolgozni őket. Ne hagyatkozzon arra, hogy a lemez soha ne teljen meg, a konfigurációs fájl mindig ott legyen, az alkalmazás teljes jogosultságokkal fusson, a memóriafoglalási kérelmek mindig sikeresek legyenek, vagy a kapcsolat soha nem szakad meg. Igen, a jó hibakezeléssel nehéz írni, és a kód hosszabb és nehezebben olvasható. De a hibák figyelmen kívül hagyása egyszerűen a szőnyeg alá söpri a problémát, ahol egy gyanútlan felhasználó egy napon rátalál.

6. szabály. Osszuk fel a kódot rövid, különálló részekre.

Minden metódusnak, függvénynek vagy kódblokknak el kell férnie egy normál képernyőablakban (25-50 sor). Ha túl hosszú, vágjuk rövidebb darabokra. Akár metóduson belül is osszuk fel a hosszú kódot blokkokra, aminek a lényegét minden blokk elején kommentben leírhatjuk.

Ezenkívül minden osztálynak, modulnak, fájlnak vagy folyamatnak egy bizonyos típusú feladatot kell végrehajtania. Ha egy kódrészlet teljesen eltérő feladatokat lát el, akkor ossza fel ennek megfelelően.

7. szabály: Használja a keretrendszer API-kat és harmadik féltől származó könyvtárakat.

Ismerje meg, milyen funkciók érhetők el a keretrendszer API-ján keresztül. és azt is, hogy a fejlett, harmadik féltől származó könyvtárak mire képesek. Ha a rendszercsomagkezelő támogatja a könyvtárakat, akkor valószínűleg támogatni fogja jó választás. Használjon olyan kódot, amely megakadályozza, hogy újra feltalálja a kereket (haszontalan négyzet alakú).

8. szabály: Ne vigyük túlzásba a tervezést.

Csak azt tervezze, ami most aktuális. A kódja meglehetősen általánossá tehető a támogatáshoz további fejlődés, de csak akkor, ha ez nem bonyolítja túl. Ne hozzon létre paraméterezett osztályokat, gyárakat, mély hierarchiákat és rejtett felületeket olyan problémák megoldására, amelyek nem is léteznek – nem sejtheti, mi lesz holnap. Másrészt, ha a kód felépítése nem felel meg a feladatnak, nyugodtan alakítsa át.

9. szabály: Légy következetes.

Ugyanazokat a dolgokat ugyanúgy csináld. Ha olyan módszert fejleszt, amelynek funkcionalitása hasonló egy meglévőéhez, akkor használjon hasonló nevet, hasonló paraméterek sorrendjét és hasonló törzsszerkezetet. Ugyanez vonatkozik az osztályokra is. Hozzon létre hasonló mezőket és metódusokat, adjon nekik hasonló felületeket, és képezzen le új neveket a hasonló osztályokban meglévő nevekre.

A kódnak meg kell felelnie a keretrendszerben foglalt szabályoknak. Például bevált gyakorlat, ha a tartományokat félig nyitottá teszik: zárt (beleértve) a bal oldalon (a tartomány elején) és nyitott (kizárólagos) a jobb oldalon (a végén). Ha egy adott esetre nincs megállapodás, akkor válasszon, és fanatikusan ragaszkodjon hozzá.

10. szabály Kerülje el a biztonsági problémákat.

A modern kód ritkán működik elszigetelten. Elkerülhetetlen annak a veszélye, hogy támadások célpontjává válik. Nem kell az internetről származniuk; a támadás az alkalmazás bevitelén keresztül történhet. A programozási nyelvtől és a tartománytól függően előfordulhat, hogy aggódnia kell a puffertúlcsordulás, a helyek közötti parancsfájlok, az SQL-befecskendezés és más hasonló problémák miatt. Tanulmányozza ezeket a problémákat, és kerülje el őket a kódban. Ez nem nehéz.

11. szabály Használjon hatékony adatstruktúrákat és algoritmusokat.

Az egyszerű kódot gyakran könnyebb karbantartani, mint a hatékonyság érdekében módosított kódot. Szerencsére egyensúlyba hozhatja a karbantarthatóságot és a hatékonyságot a keretrendszer által biztosított adatstruktúrák és algoritmusok segítségével. Használjon térképet, halmazt, vektort és ezekkel működő algoritmusokat. Így a kód tisztább, gyorsabb, méretezhetőbb és memóriahatékonyabb lesz. Például, ha ezer értéket tárol egy rendezett halmazban, akkor a metszésponti művelet megtalálja közös elemek egy másik halmazzal ugyanannyi műveletben, nem millió összehasonlításban.

12. szabály: Használjon egységteszteket.

A modern szoftverek összetettsége miatt költségesebb a telepítés, és nehezebb a tesztelés. Hatékony megközelítés az lenne, ha minden kódrészletet tesztekkel kísérnénk, amelyek ellenőrzik annak működésének helyességét. Ez a megközelítés leegyszerűsíti a hibakeresést, mert lehetővé teszi a hibák korábbi észlelését. Az egységteszt elengedhetetlen, ha dinamikusan tipizált nyelveken, például Pythonban és JavaScriptben programoz, mert ezek csak futás közben észlelnek hibákat, míg a statikusan beírt nyelvek, például a Java, a C# és a C++ futás közben is elkaphatják ezeket. Az egységtesztelés azt is lehetővé teszi, hogy magabiztosan újrafaktorálja a kódot. Az XUnit segítségével megkönnyítheti a tesztek írását és a végrehajtásuk automatizálását.

13. szabály: A kód hordozható legyen.

Hacsak nincs különleges oka, ne használjon olyan funkciókat, amelyek csak egy adott platformon érhetők el. Ne hagyatkozzon bizonyos adattípusok (például egész számok, mutatók és időbélyegek) meghatározott hosszúságára (például 32 bitre), mert ez a beállítás platformonként eltérő. Tartsa elkülönítve a programüzeneteket a kódtól és a hardcode-kultúra-specifikus beállításoktól (például decimális és egész számok elválasztóitól vagy dátumformátumától). Megállapodásokra van szükség ahhoz, hogy a kód különböző országokban futhasson, ezért tegye a lokalizációt a lehető legfájdalomtalanabbá.

14. szabály: Tegye összeépíthetővé a kódot.

Egy egyszerű paranccsal le kell fordítani a kódot egy terjesztésre kész űrlapra. A parancsnak lehetővé kell tennie a szükséges tesztek gyors felépítését és futtatását. Ennek eléréséhez használjon olyan automatizált összeállítási eszközt, mint a Make , Apache Maven vagy Ant . Ideális esetben be kell állítania egy integrációs rendszert, amely ellenőrzi, összeállítja és teszteli a kódot, amikor megváltozik.

15. szabály: Tedd mindent verziókezelés alá.

Minden elemének – kódnak, dokumentációnak, eszközforrásoknak, összeállítási parancsfájloknak, tesztadatoknak – forrásvezérlésben kell lennie. A Git és a GitHub olcsóvá és problémamentessé teszi ezt a feladatot. De számos más hatékony eszköz és szolgáltatás is elérhető az Ön számára. Képesnek kell lennie a program elkészítésére és tesztelésére egy konfigurált rendszeren úgy, hogy egyszerűen letölti a tárolóból.

Következtetés.

Ha ezt a 15 szabályt napi gyakorlata részévé teszi, akkor olyan kódot kap, amely könnyebben olvasható, jól tesztelt, nagyobb valószínűséggel fog megfelelően futni, és sokkal könnyebben módosítható, ha eljön az ideje. Ön is sok fejfájástól kíméli meg magát és felhasználóit.