Megjegyzések
Válasz
Ha tovább folytatom ha több kódot írsz, akkor lesz idő, amikor nehéz lesz a kódot rendezni.
Ez a te problémád: igazítsd a szervezetet, és a stílusnak könnyebben kell áramlania.
“Ne árjon a kód rendezéséhez: tartsa rendszerezetten a kódját menet közben. Bár a nyelv nem teszi meg helyetted, a kódot továbbra is alacsony csatolású és nagy kohéziójú modulokba kell szervezni.
Ezek a modulok természetesen névteret biztosítanak. Az ütközések elkerülése érdekében rövidítse le a modul nevét (ha hosszú), és előtagolja a függvény nevét a moduljával.
Az egyedi azonosítók szintjén ezek nagyjából növekvő szubjektivitási sorrendben vannak:
- válasszon egy konvenciót, és tartsa be azt
- pl.
function_like_this(struct TypeLikeThis variable)gyakori
- pl.
-
feltétlenül kerülje a magyar jelölést (sajnálom a JNL-t)
-
hacsak nem hajlandó használni az eredeti szándéknak megfelelően, ami inkább Simonyi apps jelölését jelenti, mintsem a szörnyű rendszer verzió
Miért? Írhatnék erről esszét, de inkább azt javaslom, olvassa el ezt a cikket Joel Spolsky-tól, majd vadásszon még egyet, ha érdekli. Alul található a link Simonyi eredeti papírjához.
-
-
kerülje a mutatógépeket, hacsak nem “valóban átlátszatlan sütitípusok” – csak összekeverni a dolgokat
struct Type *ok; typedef struct Type *TypePtr; TypePtr yuck;Mit értek átlátszatlan sütitípus alatt? Valamit értek egy modulban (vagy könyvtárban, vagy bármi), amelyet át kell adni az ügyfélkódnak, de ez az ügyfélkód “nem közvetlenül használható. Csak visszaadja a könyvtárnak.
Például egy adatbázis-könyvtár olyan felületet tárhat fel, mint például
/* Lots of buffering, IPC and metadata magic held in here. No, you don"t get to look inside. */ struct DBContextT; /* In fact, you only ever get a pointer, so let"s give it a nice name */ typedef struct DBContexT *DBContext; DBContext db_allocate_context(/*maybe some optional flags?*/); void db_release_context(DBContext); int db_connect(DBContext, const char *connect); int db_disconnect(DBContext); int db_execute(DBContext, const char *sql);Most a kontextus átlátszatlan az ügyfélkód számára, mert nem lehet belenézni. Csak vissza kell adnia a könyvtárnak. Valami
FILEis átlátszatlan, és egy egész fájlfájl-leíró szintén süti , de nem átlátszatlan.
Megjegyzés a tervezéshez
A fenti alacsony csatolás és magas kohézió kifejezést magyarázat nélkül használtam, és ettől kissé rosszul érzem magam. Kereshet rá, és valószínűleg találhat néhány jó eredményt, de megpróbálom röviden foglalkozni vele (ismét írhatnék egy esszét, de megpróbálok nem).
A fent vázolt DB könyvtár megmutatja alacsony összekapcsolás mert kis felületet tár a külvilág elé. A megvalósítás részleteinek elrejtésével (részben az átlátszatlan cookie-trükkel) megakadályozza, hogy az ügyfélkód függjön ezektől a részletektől.
Képzelje el, hogy az átlátszatlan süti helyett a kontextus struktúráját deklaráljuk, így annak tartalma látható lesz, és ez magában foglal egy socket fájlleírót az adatbázis TCP-kapcsolatához. Ha ezt követően módosítjuk a megvalósítást egy megosztott memória szegmens használatára, amikor a A DB ugyanazon a gépen fut, az ügyfelet nem csak újra kell összekapcsolni, hanem újra össze kell állítani. Még rosszabb, hogy az ügyfél elkezdhette használni a fájlleírót, például felhívni a setsockopt az alapértelmezett pufferméret megváltoztatásához, és most egy kódváltásra is szükség van. Azokat el kell rejteni a modulunkban, ahol praktikus, és ez alacsony összekapcsolódást eredményez modulok között.
A példa a magas kohézió t is mutatja, abban az esetben A modul metódusai ugyanarra a feladatra vonatkoznak (DB hozzáférés). Ez azt jelenti, hogy csak azok a kódok férnek hozzá valójában, amelyeknek tudnia kell a megvalósítás részleteiről (vagyis a sütink tartalmáról), ami egyszerűsíti a hibakeresést.
Azt is láthatja, hogy egyetlen gondja megkönnyítette az előtag kiválasztását a függvények csoportosításához.
Most könnyű ezt a példát mondani (főleg, hogy nem “még nem is teljes”, de nem segít azonnal. A trükk az, hogy a kód írása és kiterjesztése során figyeljünk olyan funkciókra, amelyek hasonló dolgokat végeznek, vagy ugyanazokat a típusokat működtetik (amelyek a saját moduljuk jelöltjei lehetnek), valamint olyan funkciókra, amelyek sok különálló dolgot végeznek, amelyek nem ” Nem igazán áll kapcsolatban, és lehet, hogy jelölt a szétválásra.
Hozzászólások
- Tudna segíteni abban, hogy megértsem, miért kerülik el a magyar nyelvet? erről. 🙂
- @JNL: A megjegyzés túl rövid ahhoz, hogy megfelelően megmagyarázza. Javaslom, hogy tegye fel új kérdésként.
-
with low coupling and high cohesion. Mit jelent ez? És kérem, magyarázza el az átlátszatlan sütitípusokat. Fogalmam sincs, hogy ez mit jelent. - Igyekeztem mind röviden foglalkozni, és őszintén szólva nem sikerült röviden. Remélhetőleg ez megkapja Önt mégis elkezdődött.
- Néhány nap múlva válaszolok. Elnézést ezért. Elolvastam a (z)
low coupling and high cohesionleírását. Tehát ez alapvetően azt jelenti, hogy egyesítem a dolgokat, amikor csak tudok és úgy kell elvégezni, hogy a a valóban szükséges funkcióknak hozzáféréssel kell rendelkezniük. Néhány dolog a fejemen járt, de mégis úgy gondolom, hogy megértettem a véleményét.
Válasz
Véleményem szerint 90 A névadási probléma% -a megoldódik, ha három dolgot szem előtt tart: lehetséges, b) konzisztensnek kell lennie az egész kódban (azaz ha egy függvényt addNumbers néven kap, akkor egy második függvényt meg kell nevezni multiplyNumbers és nem a numberMul) és a c) megpróbálja rövidíteni a neveket, ha lehetséges, mivel be kell írnunk őket.
Ennek ellenére, ha meg szeretné tekinteni a témával kapcsolatos egyéb szempontokat, a Wikipedia oldala a elnevezési konvenciókban tartalmaz egy jó listát azokról a dolgokról, amelyeket érdemes tartsd észben. A C-n és a C ++ -on is van egy szekciója:
C és C ++ nyelven a kulcsszavak és a szokásos könyvtárazonosítók többnyire kisbetűvel vannak ellátva. A C szabványos könyvtárban a rövidített nevek a leggyakoribbak (pl. Az izalnum egy funkció teszteléséhez, hogy egy karakter alfanumerikus), míg a C ++ szabványos könyvtár gyakran aláhúzást használ szóelválasztóként (például out_of_range). A makrókat reprezentáló azonosítókat megegyezés szerint csak nagybetűk és aláhúzások segítségével írják (ez sok programozási nyelvben a nagybetűs azonosítók konstansoknál történő használatához kapcsolódik). A kettős aláhúzást tartalmazó, aláhúzással és nagybetűvel kezdődő nevek a megvalósításhoz vannak fenntartva (fordító, szabványos könyvtár), és nem használhatók (pl. Fenntartott__ vagy _Rezervált). [5] [6] Ez felületesen hasonlít a sztringeléshez, de a szemantika különbözik: az aláhúzás az azonosító értékének része, ahelyett, hogy karaktereket idézne (mint a stropping): A __foo értéke __foo (ami fenntartva van), nem foo (de egy másik névtérben).
Megjegyzések
- " próbálja meg rövidíteni a neveket, ha lehetséges " Használjon IDE-t automatikus kiegészítéssel, ekkor a függvénynevei olyan hosszúak és leíróak lehetnek, amennyire csak szükségük van gépelni akkor egyszer.
- @Joel szörnyű tanács. Nem mindenki fogja használni ugyanazt az IDE-t, mint te.
- @James Nem szükséges, div id = “5b6d787de1″>
nek kell, csak bármilyen tisztességes IDE-t használhatnak. Akkor nem kell ' feláldozni az egyértelműséget a termelékenység érdekében.
Válasz
Az egyetlen kemény korlát a C-ben, hogy nincsenek névterek. Ezért meg kell találnia a módját, hogy a fájlrendszer könyvtár rename() függvényét megkülönböztesse a rename() a média könyvtár funkciója. A szokásos megoldás egy előtag, például: filesystem_rename() és media_rename().
A másik általános tanács a következő: projekten vagy csapaton belül következetes. Javul az olvashatóság.
Megjegyzések
- +1: Ez különösen igaz a könyvtár exportált szimbólumaira. " Sajnálom, de ez a fájlrendszer-könyvtár nem tartozik ehhez a médiatárhoz, mert mindkettő exportált függvény átnevezéssel rendelkezik.
Válasz
HA GLOBÁLISAN KERES ELFOGADOTT FORMÁT
A MISRA / JSF / AUTOSAR lefedi a C / C ++ kódok elnevezésére és rendszerezésére vonatkozó minden ipari szabvány közel 100% -át. A probléma az, hogy nem lesznek ingyen megszerezhetők, azaz mindegyik útikönyv némi pénzbe kerül. Tudom, hogy a MISRA 2008 C / C ++ kódolási szabványkönyv valószínűleg körülbelül 50 USD-ba kerül.
Ezeket úgy gondolhatja, mint a Harvard-referenciákat az irodalomjegyzék és az olvasmányok olvasására, amikor naplót ír. A MISRA-t használtam, és ez egy jó módja annak, hogy megnevezzük a függvényeket és a változókat, és rendbe hozzam azokat a megfelelő használat érdekében.
A Pythonra és a Java-ra megadott hivatkozások szerintem rendben vannak. Láttam, hogy a javadoc stílusú emberek átveszik a kód megjegyzését, elnevezését és rendszerezését. Ami azt illeti, a legutóbbi projektemben C ++ kódot kellett írnom Java-szerű függvényekben / változónevekben. Két oka van ennek:
1) Nyilvánvalóan könnyebb volt követni.
2) A gyártási kódra vonatkozó követelmények nem érintették a biztonság szempontjából kritikus szoftverrendszer szabványainak talaját.
3) A régi kód (valahogy) ebben a formátumban volt.
4) A Doxygen lehetővé tette a Javadoc sytle kommentelését. Abban a pillanatban doxygen-t használtunk dokumentumok készítéséhez a produkciós srácok számára.
Sok programozó lesz ennek ellenzője, de én személy szerint azt mondom, hogy nincs semmi baj a javadoc stílusú függvény / változó elnevezés C-ben történő alkalmazásával. / C ++. Természetesen IGEN, az áramlásszabályozás megszervezésének gyakorlatával, a menetbiztonsággal stb. Foglalkozni kell. Itt azonban nem vagyok pályázó. Azt sem tudom, hogy mennyire szigorúak a gyártási kód formátumra vonatkozó követelményei. Anélkül, hogy egy témán kívüli területre terelném, azt javaslom, hogy nézze át a követelményeket, derítse ki, mennyire függ egy adott elnevezési megállapodástól, és keressen egy említett megoldást az enyémben és mások “válaszok
Remélem, hogy ez segített !?
Megjegyzések
- Valójában ezt kértem személyes C kódoktól . De ' emlékszem a javaslatára.
- @AseemBansal Személyes vagy szakmai, ezeket jó megtanulni, és jó feltenni az önéletrajzába is … … . Rajtad múlik.
Válasz
Kevés fontos szempont, amelyet figyelembe kell venni a névadás során;
-
Nézze meg az actionObject vagy ObjectAction típust. (Az objektum nem a C-re vonatkozik, de általában, ha más objektumorientált nyelvekhez megy) Ennek segítenie kell
-
A pihenés következetesnek, rövidnek és biztosan leírónak kellene lennie. minden definiált változó és függvény egyetlen célja, pl .: Ha értékének ideiglenes tárolására szolgál, nevezze meg int-nek nTempVal
- A változóknak főnévnek, a Methodsnak pedig igének kell lenniük. >
Megjegyzések
- A magyar jelölés (a változó előtagja a típust jelölő betűkkel) nem vezet véget a fájdalomnak. Szerencsére többnyire kiment a divatból.
- @StevenBurnap Csak arra volt kíváncsi, miért kerülik el a magyar formátumot? Úgy gondolom, hogy ' az, amit tanítottak nekünk az iskolában, és néhány munkahelyen is láttam ilyen kódot. Melyiket ajánlanád, ha nem magyar. Köszönet
- A legjobb elnevezési szokás csak egy következetesen alkalmazott, világos, leíró nevek, amelyek ideális esetben viszonylag rövidek, túlzott rövidítés nélkül, és elkerülik a felesleges előtagokat. A magyar jelölésnek kevés tényleges hasznossága van, a kódot nehezebben olvashatja, és a típusváltást is megnehezíti.
- Íme az eredeti szándék leírása és utálatosság, amelyből a magyar jelölés vált: joelonsoftware.com/articles/Wrong.html
- @Residuum Ez jó link volt. Sokat segített. Értékelje.
Válasz
A válaszok többsége jó, de néhány dolgot el akarok mondani a névadásról a könyvtárak és a hozzá tartozó fájlok konvenciói, hasonlóan más nyelvek névtereinek használatához, mint a C ++ vagy a Java:
Ha könyvtárat épít, keressen egy közös előtagot az exportált szimbólumokhoz, azaz globális függvényekhez, typedefekhez és változókhoz. Ez megakadályozza az ütközéseket más könyvtárakkal, és azonosítja a funkciókat a tiédtől. Ez egy kis alkalmazás magyar nyelvű jelölés.
Talán menj tovább, és csoportosítsd az exportált szimbólumokat: a libcurl a curl_ * -t használja a globális szimbólumokhoz, a curl_easy_ *, curl_multi_ * és curl_share_ * a különböző felületekhez.Tehát amellett, hogy a curl_ * -t minden funkcióhoz használják, felvettek egy másik “névteret” a különböző felületekhez: a curl_easy_ * függvény meghívása a curl_multi_ * fogantyún most rosszul néz ki, lásd a függvényneveket a http://curl.haxx.se/libcurl/c/
Az exportált szimbólumok szabályainak megtartása mellett a szerkesztett fájlok: Próbáljon meg egy közös előtagot találni ezekhez a funkciókhoz. Esetleg statikus karakterlánc-segédfunkciók vannak a “my_string” nevű fájlban? Az összes függvényt előtagozza a my_string_ * kifejezéssel.
Megjegyzések
- Exportált szimbólumok alatt globális változókat, függvényeket, typedefeket stb. Ért, ha jól gondolom. Meg tudná magyarázni az exportált szimbólumok csoportosítását? Azt hittem, ezt már az előző bekezdésben kifejtette. Mit adott hozzá a 3. bekezdéshez?
order.c, akkor megnevezheti aorder_add(),order_del()és ilyenek. Lehet, hogy vannak olyan régi rendszerek, amelyek azt mondják, hogy a névnek egyedinek kell lennie az első 8 karakteren belül. Amikor véletlenül később váltasz a c ++ – ra, ' szeretsz írniorder::add()ésorder::del()akkor.