Miért kell egy egész bash szkriptet írni függvényekbe?

Ugyanezt kezdtem használni a bash programozás stílusa a Kfir Lavi “Defensive Bash Programming” blogbejegyzésének elolvasása után. Jó néhány jó okot megad, de én személy szerint ezeket tartom a legfontosabbnak:

• az eljárások leíróvá válnak: sokkal könnyebb kitalálni, hogy a kód egy adott részének mi a célja megtenni. A kódfal helyett az “Ó, a find_log_errors függvény beolvassa a naplófájlt hibáért”. Hasonlítsa össze azzal, hogy sok awk / grep / sed sort talált használd az isten tudja, milyen típusú regexet egy hosszú szkript közepén – fogalmad sincs, mit csinál ott, hacsak nincsenek hozzászólásai.

• a funkciókat hibakeresheted a set -x és set +x beillesztésével. Miután megtudta, hogy a kód többi része rendben működik, ezzel a trükkel csak az adott funkció hibakeresésére összpontosíthat. Persze, mellékelheti a szkript egyes részeit, de mi van, ha hosszú szakasza van? Könnyebb ilyesmit csinálni:

   set -x parse_process_list set +x 

• nyomtatási használat a cat <<- EOF . . . EOF névvel. Sokszor használtam, hogy sokkal professzionálisabbá tegyem a kódomat. Ezenkívül a parse_args() a getopts függvénnyel nagyon kényelmes. Ez megint segít az olvashatóságban, ahelyett, hogy mindent szkriptbe taszítana, mint óriási szövegfalat. Ezeket is kényelmes újrafelhasználni.

És nyilvánvalóan ez sokkal több olvasható annak, aki ismeri a C-t vagy a Java-t, vagy a Valát, de korlátozott tapasztalata van. Ami a hatékonyságot illeti, nincs sok minden, amit tehetsz – maga a bash nem a leghatékonyabb nyelv, és az emberek inkább a perl-t és a pythont választják, ha a sebességről és a hatékonyságról van szó.nice függvényt azonban megadhat:

nice -10 resource_hungry_function 

Ahhoz képest, hogy minden egyes kódsorban szépet hívna, ez csökkenti a gépelés sokaságát, és kényelmesen használható, ha azt szeretné, ha a szkriptnek csak egy része futna alacsonyabb prioritással.

A függvények futtatása a háttérben véleményem szerint segít abban az esetben is, ha egészet szeretne egy csomó utasítás a háttérben történő futtatáshoz.

Néhány példa, ahol ezt a stílust használtam:

• https://askubuntu.com/a/758339/295286
• https://askubuntu.com/a/788654/295286
• https://github.com/SergKolo/sergrep/blob/master/chgreeterbg.sh

Megjegyzések

• Nem vagyok biztos benne, hogy nagyon komolyan kellene vennie a cikkben szereplő javaslatokat. Bizony, van néhány jó ötlete, de nyilvánvalóan nem valaki szokta parancsfájlok héjazására használni. Nem egy single változót a példák bármelyikében idézzük (!), és az UPPER C használatát javasolja ASE változónevek, ami gyakran nagyon rossz ötlet, mivel ütközhetnek a meglévő env változókkal. Ennek a válasznak a pontjainak van értelme, de úgy tűnik, hogy a linkelt cikket olyan valaki írta, aki csak más nyelvekhez szokott, és stílusát a bashra próbálja erőltetni.
• @terdon visszatértem a cikkhez és újra elolvastam. Az egyetlen hely, ahol a szerző a nagybetűs változó elnevezését említi, a ” megváltoztathatatlan globális változók ” helyen található. Ha a globális változókat olyanoknak tekintjük, amelyeknek a ‘ függvény környezetében kell lenniük, akkor ésszerű tőkévé tenni őket. Megjegyzendő, hogy a bash ‘ s kézikönyv nem állít elő ‘ t egyezményt a változó esetben. Még itt elfogadott válasz szerint ” általában ” és az egyetlen ” standard ” a Google, amely nem ‘ nem képviseli az egész informatikai ágazatot.
• @terdon egy másik megjegyzésben, 100% -ban egyetértek abban, hogy a változó idézetet meg kellett volna említeni a cikkben, és erre a blog kommentjeiben is felhívták a figyelmet. Ezenkívül nem ‘ nem ítélnék el valakit ezen kódolási stílus használatával, függetlenül attól, hogy ‘ más nyelvhez szoktak-e használni. Ez az egész kérdés és a válaszok egyértelműen megmutatják ‘ előnyeit és a személy ‘ fokozatát, amellyel ‘ hogy más nyelvhez szokott, itt valószínűleg nem releváns.
• @terdon, a cikket a ” forrás ” anyag. Elküldhettem volna mindent a saját véleményemként, de csak azt kellett elismernöm, hogy a cikkből megtudtam néhány dolgot, és hogy mindez az idők során végzett kutatásból származott. A szerző ‘ keresőoldala azt mutatja, hogy jó tapasztalataik vannak a Linux-ral és általában az informatikával kapcsolatban, ezért azt gondolom, hogy a cikk nem ‘ ezt nem igazán mutatják, de bízom a tapasztalataidban, amikor a Linuxról és a shell parancsfájlokról van szó, tehát igazad lehet.
• Ez ‘ kiváló válasz, de én ‘ is szeretném hozzátenni, hogy a Bash változó hatóköre funky. Ezért a változataimat inkább a függvényekben deklarálom a local használatával, és mindent a main() függvényen keresztül hívok meg. Ez sokkal jobban kezelhetővé teszi a dolgokat, és elkerülheti az esetleges rendetlen helyzetet.

Az olvashatóság egy dolog. De a modularizáció nál nem csak ez van. (A félmodularizáció talán helyesebb a függvényeknél.)

A függvényekben néhány változót helyi szinten tarthat, ami növeli a megbízhatóságot , csökkentve a a dolgok elrontódnak.

A funkciók másik előnye az újrafelhasználhatóság . Miután egy függvény kódolt, többször is alkalmazható a szkriptben. Portálozhat egy másik szkriptbe is.

A kódod most lineáris lehet, de a jövőben beléphetsz a multi-threading vagy multi- feldolgozás a bash világban. Miután megtanulta a dolgokat a függvényekben, akkor jól felkészült a párhuzamba lépésre.

Még egy pont hozzáadásra. Amint az Etsitpab Nioliv az alábbi megjegyzésben észreveszi, könnyű átirányítani a funkciókat, mint koherens entitást. De a funkciókkal történő átirányításoknak van még egy aspektusa. Ugyanis az átirányítások a funkciódefiníció mentén állíthatók be. Pl .:

f () { echo something; } > log 

Most nincs szükség kifejezett átirányításokra a függvényhívásoknak.

$ f 

Ez sok ismétlést megkímélhet, ami ismét növeli a megbízhatóságot és segít rendben tartani a dolgokat.

Lásd még:

• https://unix.stackexchange.com/a/483304/181255

Megjegyzések

• Nagyon jó válaszoljon, bár sokkal jobb lenne, ha függvényekre bontanánk.
• Talán hozzáadva, hogy a függvények lehetővé teszik a szkript importálását egy másik szkriptbe (az source vagy . scriptname.sh, és használja ezeket a függvényeket, mintha az új szkriptben lennének.
• Ez ‘ egy másik válaszban.
• Ezt nagyra értékelem. De én ‘ inkább más embereket is fontosnak hagytam.
• Egy eset előtt álltam ma, ahol a szkript kimenetének egy részét fájlba kellett átirányítanom (e-mailben elküldeni) ahelyett, hogy visszhangoztam volna. Egyszerűen meg kellett tennem a myFunction > > myFile a kívánt funkciók kimenetének átirányításához. Nagyon kényelmes. Lehet, hogy releváns.

Megjegyzésemben a funkciók három előnyét említettem:

1. Könnyebb tesztelni és ellenőrizni a helyességet.

2. A funkciók a későbbi szkriptekben könnyen újrafelhasználhatók (beszerezhetők)

3. Főnöke kedveli őket.

És soha ne becsülje alá a 3. szám fontosságát.

Még egy kérdéssel szeretnék foglalkozni:

… tehát a futási sorrend önkényes cseréje nem valami, amit általában tennénk. Például nem akarja hirtelen felvenni a declare_variables -t a walk_into_bar után, ez megtörné a dolgokat.

A kód funkciókra bontásának előnyeihez meg kell próbálnunk a függvényeket a lehető legfüggetlenebbé tenni. Ha a walk_into_bar változóra van szükség, máshol nem használatos, akkor ezt a változót meg kell határozni és lokalizálni kell a walk_into_bar fájlba. A kód függvényekre bontásának és az egymás közötti függőségeik minimalizálásának egyértelműbbé és egyszerűbbé kell tennie a kódot. .

Ideális esetben a funkciókat könnyen lehet egyedileg tesztelni. Ha interakciók miatt nem könnyű tesztelni őket, akkor ez annak a jele, hogy hasznot húzhatnak a refaktorálásból.

Megjegyzések

• Én ‘ azt állítom, hogy ‘ néha ésszerű modellezni és érvényesíteni ezeket a függőségeket, szemben az elhárításukkal, hogy elkerüljük őket (hiszen ha vannak ilyenek h közülük, és ‘ kellően szőrösek, ami csak olyan esethez vezethet, amikor a dolgokat már egyáltalán nem modulálják függvényekké. Egy nagyon bonyolult használati eset egyszer egy keretet erre inspirált .
• Amit funkciókra kell bontani, az legyen, de a példa túl messzire viszi. Szerintem az egyetlen, ami igazán hibát okoz nekem, a változó deklarációs függvény. A globális változókat, különösen a statikusakat, globálisan kell meghatározni egy erre a célra szánt kommentált szakaszban. A dinamikus változóknak lokálisaknak kell lenniük az őket használó és módosító függvények számára.
• @Xalorous I ‘ láttam olyan gyakorlatot, ahol a globális változókat inicializálják egy eljárásban, közbenső és gyors lépésként egy olyan eljárás kidolgozása előtt, amely kiolvassa az értéküket egy külső fájlból … Egyetértek azzal, hogy tisztábbnak kell lennie a definíció és az inicializálás elkülönítésének, de ritkán meg kell hajlítania a 3. számú előny ;-)

Bár teljesen egyetértek az újrafelhasználhatóság val, az olvashatóság val és a főnökök finoman csókolózásával, de a bash a funkcióinak még egy előnye van >: változó hatókör . Ahogy az LDP mutatja :

#!/bin/bash # ex62.sh: Global and local variables inside a function. func () { local loc_var=23 # Declared as local variable. echo # Uses the "local" builtin. echo "\"loc_var\" in function = $loc_var" global_var=999 # Not declared as local. # Therefore, defaults to global. echo "\"global_var\" in function = $global_var" } func # Now, to see if local variable "loc_var" exists outside the function. echo echo "\"loc_var\" outside function = $loc_var" # $loc_var outside function = # No, $loc_var not visible globally. echo "\"global_var\" outside function = $global_var" # $global_var outside function = 999 # $global_var is visible globally. echo exit 0 # In contrast to C, a Bash variable declared inside a function #+ is local ONLY if declared as such. 

Ezt a való világban nem nagyon látom shell szkriptek, de jó ötletnek tűnik a bonyolultabb szkripteknél. A kohézió csökkentése segít elkerülni a hibákat, amikor a kód egy másik részében várható változót csapdába ejti. .

Az újrafelhasználhatóság gyakran azt jelenti, hogy létrehozzon egy közös függvénykönyvtárat, és source beillessze ezt a könyvtárat az összes szkriptjébe. Ez nem segít gyorsabban futni, de gyorsabban megírja őket.

Megjegyzések

• Kevesen használják kifejezetten a local, de úgy gondolom, hogy a legtöbb funkcióra bontott szkriptet író ember továbbra is a tervezési elveket követi. A Usign local csak megnehezíti a hibák bevezetését.
• local elérhetővé teszi a változókat a funkciók és gyermekei számára, ezért ‘ nagyon jó, hogy van olyan változó, amelyet át lehet adni az A függvénytől lefelé, de nem érhető el a B funkcióhoz, amely ugyanolyan nevű, de más célú változót szeretne.Tehát a ‘ jó a hatókör meghatározásához, és ahogy Voo mondta – kevesebb hiba

A kódot funkciókra bontja ugyanazon okból, mint a C / C ++, a python, a perl, a rubin vagy bármely más programozási nyelv kód esetén. A mélyebb ok az absztrakció – az alacsonyabb szintű feladatokat magasabb szintű primitívekké (funkciókba) foglalja össze, így nem kell aggódnia a dolgok elvégzésével kapcsolatban. Ugyanakkor a kód olvashatóbbá (és karbantarthatóbbá) válik, és a A program logikája világosabbá válik.

Azonban a kódját nézve elég furcsának találom, hogy van egy funkció a változók deklarálására; ez valóban szemöldökre késztet.

Hozzászólások

• Alulértékelt válasz IMHO. Javasolja-e a változók deklarálását a main függvényben / módszerben?

Teljesen más ok, mint a többi válaszban már megfogalmazott: az egyik ok, hogy ezt a technikát néha használják, ahol a A legfelső szintű nem-function-definition utasítás egy felhívás a (z) main címre, hogy megbizonyosodjon arról, hogy a parancsfájl véletlenül nem csinál semmi csúnyát, ha a szkriptet csonkolják. Lehetséges, hogy a szkript csonka ha az az A folyamatból a B folyamatba (a shellbe) vezetett, és az A folyamat bármilyen okból befejeződik, mielőtt befejezte volna a teljes szkript megírását. Ez különösen akkor fordulhat elő, ha az A folyamat egy távoli erőforrásból szerzi be a szkriptet. Bár biztonsági okokból ez nem jó ötlet, mégis megtörténik, és néhány szkriptet módosítottak a probléma előrejelzése érdekében.

Megjegyzések

• Érdekes! De aggasztónak találom, hogy az egyes programokban gondoskodni kell ezekről a dolgokról. Másrészt pontosan ez az main() minta szokásos a Pythonban, ahol az ember a fájl végén a if __name__ == '__main__': main() -t használja.
• A python-idióma előnye, hogy más szkripteket import engedélyezi az aktuális parancsfájlok futtatása nélkül, a main futtatása nélkül. Feltételezem, hogy egy hasonló őrt be lehetne írni egy bash szkriptbe.
• @Jake Cobb Igen. Most ezt csinálom az összes új bash szkriptben. Van egy szkriptem, amely az összes új szkript által használt funkciók alapvető infrastruktúráját tartalmazza. Ez a szkript beszerezhető vagy végrehajtható. Ha származik, akkor a fő funkciója nem kerül végrehajtásra. A forrás és a végrehajtás detektálása azon keresztül történik, hogy a BASH_SOURCE tartalmazza a végrehajtó szkript nevét. Ha ‘ ugyanaz, mint az alapszkript, akkor a szkript végrehajtásra kerül. Ellenkező esetben ‘ származik.
• Ehhez a válaszhoz szorosan kapcsolódva a bash egyszerű vonalas alapú feldolgozást használ, ha már a lemezen lévő fájlból fut. Ha a fájl a szkript futása közben megváltozik, akkor a sorszámláló ‘ nem változik, és ‘ rossz helyen folytatja. Minden funkcióba foglalása biztosítja, hogy ‘ minden a memóriába kerüljön, mielőtt bármit is futtatna, így a fájl megváltoztatása nem befolyásolja azt.

Néhány releváns probléma a programozással kapcsolatban:

• A programod megváltozik, akkor is, ha a főnököd ragaszkodik hozzá, hogy ez ne így legyen.
• Csak a kód és a bemenet befolyásolja a program viselkedését.
• A elnevezése nehéz.

A megjegyzések megállásként kezdődnek, mivel nem képes egyértelműen kifejezni ötleteit kódban *, és a változással rosszabbá válik (vagy egyszerűen téves). Ezért, ha csak lehetséges, fejezzen ki fogalmakat, struktúrákat, érvelést, szemantikát, folyamatot, hibakezelést és bármi mást, ami releváns a kód megértéséhez mint kód.

Ez azt mondta: A Bash funkciókban vannak olyan problémák, amelyek a legtöbb nyelven nem találhatók meg:

• A Bash nyelvben a névtér szörnyű. Például a local kulcsszó használatának elfelejtése a globális névtér szennyezését eredményezi.
• A local foo="$(bar)" használatával a elveszti a bar kilépési kódját.
• Nincsenek megnevezett paramétereket, ezért szem előtt kell tartanod, hogy mit jelent a "$@" a különböző kontextusokban.

* Sajnálom, ha ez sért, de miután Néhány évig használjuk a megjegyzéseket, és anélkül fejlesztjük őket ** több évig, hogy teljesen egyértelmű, hogy melyik a jobb.

** A megjegyzések használata licenceléshez, API dokumentációhoz és hasonlókhoz továbbra is szükséges.

Megjegyzések

• Szinte az összes helyi változót úgy állítottam be, hogy nullává nyilvánítottam őket a függvény elején …local foo="" Ezután a parancs végrehajtásával állítsa be őket az eredményre … foo="$(bar)" || { echo "bar() failed"; return 1; }. Ez gyorsan kiszabadít minket a funkcióból, ha a kívánt értéket nem lehet beállítani. A göndör zárójelekre azért van szükség, hogy megbizonyosodhassunk arról, hogy a return 1 csak kudarc esetén kerül végrehajtásra.
• Csak kommentálni akarta a pontjait. Ha a ‘ alhéjfüggvényeket ‘ (zárójelekkel és nem göndör zárójelekkel határolt függvények) használja, akkor 1) don ‘ nem kell használni a helyi nyelvet, de ki kell használni a lokális előnyöket, 2) Don ‘ ne ütközzön azzal a problémával, hogy elveszíti a parancs helyettesítésének kilépési kódját a local foo=$(bar) annyi (mert ‘ nem használ helyi) 3) Ne ‘ ne aggódjon a véletlen szennyezésről vagy a globális hatókör megváltoztatásáról 4) képesek átadni ‘ megnevezett paramétereket ‘, amelyek

A folyamathoz sorrend szükséges. A legtöbb feladat egymás után következik. Nincs értelme a rendeléssel kavarni.

De a programozásban a szuper nagy dolog – amely magában foglalja a szkripteket is – a tesztelés. Tesztelés, tesztelés, tesztelés. Milyen tesztparancsfájlokkal kell ellenőriznie a szkriptek helyességét?

A főnöke megpróbálja elvezetni a forgatókönyv-gyerekektől a programozói létezésig. Ez jó irány a továbbjutáshoz. Azok az emberek, akik utánad jönnek, kedvelni fogják.

DE. Mindig emlékezzen folyamatorientált gyökereire. Ha van értelme a függvényeket abban a sorrendben rendezni, ahogyan általában végrehajtják, akkor tegye meg, legalábbis első lépésként.

Később rájön, hogy néhány funkciója a bemenet kezelése, mások kimenete, mások feldolgozása, mások adatainak modellezése és mások manipulálása az adatokkal, ezért okos lehet hasonló módszereket csoportosítani, esetleg külön fájlokba is áthelyezni őket.

Később még: rájössz, hogy már írt kis segítő funkciók könyvtárai, amelyeket számos szkriptedben használsz.

Hozzászólások a távolság pedig nem eljuthat a függvények olvashatósága közelében, amint azt bemutatom. Funkciók nélkül nem láthatja az erdőt a fák után – nagy problémák rejlenek a sok részlet sorában. Más szavakkal, az emberek nem tudnak egyszerre összpontosítani a finom részletekre és a nagy képre. Ez egy rövid szkriptben nem biztos, hogy nyilvánvaló; mindaddig, amíg rövid marad, elég olvasható lehet. A szoftver nagyobb lesz, bár nem kisebb , és minden bizonnyal a vállalat teljes szoftverrendszerének része, amely bizonyára sokkal nagyobb, valószínűleg több millió sor.

Fontolja meg, hogy adtam-e Önnek ilyen utasításokat:

Place your hands on your desk. Tense your arm muscles. Extend your knee and hip joints. Relax your arms. Move your arms backwards. Move your left leg backwards. Move your right leg backwards. (continue for 10,000 more lines) 

Mire félúton vagy akár 5% -on átjutottál volna, elfelejtetted, mi volt az első néhány lépés. Lehet, hogy nem észlelheti a legtöbb problémát, mert nem láthatja a fákat az erdőben. Összehasonlítás a függvényekkel:

stand_up(); walk_to(break_room); pour(coffee); walk_to(office); 

Ez minden bizonnyal sokkal érthetőbb, függetlenül attól, hogy hány megjegyzést adna soronként egymás után. emellett sokkal valószínûbbé teszi, hogy észreveszi, hogy elfelejtette kávét készíteni, és valószínűleg elfelejtette a sit_down () -t a végén. Amikor az elméd a grep és az awk regexes részleteire gondol, akkor nem lehet nagy képre gondolni – “mi van, ha nincs kávé”?

A funkciók elsősorban az összkép megtekintését teszik lehetővé, és vegye észre, hogy elfelejtette elkészíteni a kávét (vagy hogy valaki inkább a teát részesíti előnyben). Máskor, más szemléletben aggódik a részletes megvalósítás miatt.

Más előnyökről is szó esik Természetesen más válaszok, amelyek a többi válaszban nem szerepelnek egyértelműen, hogy a funkciók garantálják a hibák megelőzését és kijavítását. Ha kiderül, hogy a $_foo változó a walk_to () függvényben hibás volt, akkor tudja, hogy csak a függvény további 6 sorát kell megnéznie, hogy megtalálja mindazt, amit a probléma érinthetett, és mindent, ami lehetséges tévedést okoztak. (Megfelelő) funkciók nélkül az egész rendszerben bármi és minden oka lehet annak, hogy a $ foo helytelen, és bármit és mindent befolyásolhat a $ foo. Ezért nem tudja biztonságosan kijavítani a $ foo-t anélkül, hogy újra megvizsgálná a program minden egyes sorát. Ha a $ foo lokális egy függvény számára, akkor csak a függvény ellenőrzésével garantálhatja, hogy a változtatások biztonságosak és helyesek.

Megjegyzések

• Ez nem ‘ t bash szintaxis.’ mégis szégyen; Nem gondolom, hogy ‘ szerintem van mód arra, hogy a bemenetet átadjuk az ilyen funkcióknak. (azaz pour(); < coffee). Inkább úgy néz ki, mint c++ vagy php (szerintem).
• @ tjt263 zárójel nélkül, akkor ‘ s bash szintaxisa: öntsön kávét. A parensekkel nagyjából minden más nyelv ‘. 🙂

Az idő pénz

Vannak egyéb jó válaszok , amelyek rávilágítanak a technikai okokra, hogy modulárisan szkriptet írjanak, potenciálisan hosszú, munkakörnyezetben kifejlesztett, amelyet személyek csoportja használ, és nem csak saját használatra fejlesztett ki.

Szeretném összpontosítson egy elvárásra: munkakörnyezetben “az idő pénz” . Tehát a hibák hiányát és a kód teljesítményét a olvashatósággal , tesztelhetőséggel, karbantarthatósággal, refaktorálhatósággal, újrafelhasználhatóság …

Írás: ” modulok “ egy kód csökkenti az olvasási időt, amire nemcsak a coder nek, hanem a tesztelők vagy a a főnök. Ezenkívül vegye figyelembe, hogy a főnök ideje általában többet fizet, mint a kódoló ideje, és hogy a főnöke értékelni fogja az Ön munkájának minőségét.

Ezenkívül írjon független “modulok” egy kód (akár egy bash szkript is) lehetővé teszi, hogy “párhuzamosan” dolgozzon a csapat másik összetevője lerövidíti a teljes gyártási időt, és legjobb esetben az egyedüli szakértelmet használja fel, hogy áttekintsen vagy átírjon egy részt, anélkül, hogy mellékhatással lenne a többiekre, és újrafeldolgozná az imént írt kódot “ahogy van” egy másik programhoz / szkripthez könyvtárak (vagy kivonatok könyvtárainak) létrehozása, a teljes méret és az ezzel kapcsolatos hibák valószínűségének csökkentése, az egyes részek hibakeresése és alapos tesztelése … és természetesen logikusan fog szerveződni ossza meg a programot / szkriptet, és javítsa az olvashatóságát. Minden, ami időt és pénzt takarít meg. A hátrány az, hogy ragaszkodnia kell a szabványokhoz és kommentálnia kell a funkcióit (amelyeket nem munkakörnyezetben).

A szabvány betartása lelassítja munkáját az elején, de utána felgyorsítja a többiek (és ti is) munkáját. Ha az együttműködés növekszik az érintettek számában, ez elkerülhetetlenné válik. Tehát például akkor is, ha úgy gondolom, hogy a globális változókat globálisan és nem egy függvényben kell meghatározni, megértek egy szabványt, amely inizializálja őket egy mindig a main() egyik első sorában hívták …

Végül, de nem utolsósorban, ne becsüld le a modern forráskódban rejlő lehetőségeket szerkesztők szelektíven különálló rutinok megjelenítésére vagy elrejtésére ( Kódhajtás ). Ez kompakt módon megtartja a kódot, és újra összpontosítja a felhasználót.

^{Itt fentebb láthatja, hogy kibontja csak a walk_into_bar() függvény. Még a többiek is 1000 sor hosszúak voltak, továbbra is az összes kódot egy oldalon ellenőrizhetitek. Ne feledje, hogy még a szakasz is be van hajtva, ahol a változók deklarálásához / inicializálásához megy.}

Egy másik ok amit gyakran figyelmen kívül hagynak, az a bash szintaktikai elemzése:

set -eu echo "this shouldn"t run" { echo "this shouldn"t run either" 

Ez a szkript nyilvánvalóan tartalmaz egy szintaktikai hibát, és a bash-nak egyáltalán nem kellene futtatnia, igaz? Rossz.

~ $ bash t1.sh this shouldn"t run t1.sh: line 7: syntax error: unexpected end of file 

Ha a kódot egy függvénybe csomagoltuk, ez nem fog megtörténni:

set -eu main() { echo "this shouldn"t run" { echo "this shouldn"t run either" } main 

~ $ bash t1.sh t1.sh: line 10: syntax error: unexpected end of file 

A többi válaszban szereplő okokon kívül:

9. Pszichológia: Az a programozó, akinek a termelékenységét kódsorokban mérik, ösztönzést kap arra, hogy feleslegesen bőbeszédű kódot írjon. a kódsorokra összpontosítva, annál ösztönzőbbnek kell lennie a programozónak, hogy szükségtelenül bonyolultan bővítse a kódját. Ez nem kívánatos, mivel a megnövekedett komplexitás megnövelheti a karbantartási költségeket és megnöveli a hibajavításhoz szükséges erőfeszítéseket.
   • WP, a kód forrássorai; Hátrányok, # 9

megjegyzések

• Ez nem is olyan rossz válasz, mint az elmaradottak mondják. Megjegyzés: az agc szerint ez is lehetőség, és igen. Nem mondja, hogy ‘ nem mondja, hogy ez lenne az egyetlen lehetőség, és nem vádol senkit, csak a tényeket közli. Bár szerintem ma szinte hallatlan közvetlen ” kódsor ” – > ” $$ ” stílusú szerződéses munka, közvetett módon meglehetősen gyakori, hogy igen, a gyártott kód tömegét a vezetők számítják / főnökök.