Blbinky (8) - hľadáme súbory s odsadzovaním medzerami

17.6.2009 01:41 | Přečteno: 868× | iné

#!/bin/bash
find | grep -v '.svn' | grep -e '.js' -e '.php' -e '.sh' |
  while read i; do
    # zo suboru odstranime taby, co zostane a zacina medzerou je zle
    V=`sed 's/\t//g' "$i" | grep '^ '`
    E=`echo "$V" | wc -l`
    if [ "$E" != "0" ] && [ "$V" != "" ]; then
      printf "%-6s %s\n" $E "$i"
      echo "$V" | sed 's/^/  ==  /g'
    fi
  done

V aktuálnom adresári nájde všetky .js/.php/.sh súbory a ak nepoužívajú odsadzovanie tabulátormi tak vypíše názov súboru a riadky kde je chybné odsadenie.

       

Anketa

Komentáře

[l4m4]

Proč? Jednak je tabelátor přežitek sedmdesátých let, který doufám už brzy vyhyne, druhak pokud používám konzistentní odsazování, tak mohu říci vimu (případně jinému programu, když nemám vim rád), aby celý soubor odsadil tímto stylem, a je to, nemusí se s tím patlat člověk.

[CEST]

FLAAAAME!!:))

No vidis, ja mam tab radsi nez mezery, protoze mam rad odsazeni 2 znaky. Jenze kdyz pak nekdo naseka odsazeni 8 mezer, tak s tim nehnu (resp. ve vimu je to otazka set ts=8 :%!retab set ts=2, ale muze to zpusobit problemy, kdyz to odsazeni neni jenom odsazeni kodu). Proto bych pro odsazovani naopak preferoval taby. Logicky je to pak kazdej level odsazeni pouze jeden znak (tab) a navic si kazdej muze urcit velikost pro zobrazeni, jaka mu vyhovuje.

At je to tak nebo tak, nekdo pouziva taby nekdo mezery, a proto byla totalni kravina python bloky zalozit na odsazeni. Protoze kdyz pak do kodu s mezerama naperu jeden tab, vypada to sice dobre zarovnany, ale poctem whitespace je to blbe.

[l4m4]

Potíž se změnou ts (resp. ekvivalentní veličiny v jiném editoru) je, že lidi používající tabelátory jsou vesměs prasata, tudíž v kódu

1 {
2     volání_funkce(dlouhý_argument, 
3                   další_argument);
4 }

použijí pro odsazení řádku 3 tolik tabelátorů, kolik jim zrovna vychází podle jejich oblíbené hodnoty ts. Jediný způsob, jak zajistit nerozbití odsazení je ovšem použít právě jeden (tj. stejný počet jako na předchozím řádku) a na zbytek mezery:

1 {
2 TTTTvolání_funkce(dlouhý_argument, 
3 TTTTMMMMMMMMMMMMMMdalší_argument);
4 }

Ve výsledku tudíž stejně musíš používat přesně stejnou hodnotu ts jako člověk, co to psal, a v tom případě jsou tabelátory zbytečná komplikace.

> Protoze kdyz pak do kodu s mezerama naperu jeden tab

ASCII znak 09 je kontrolní znak, který nemá ve zdrojovém kódu co dělat. Nejlepší je nastavit svůj VCS, aby takový soubor ani nepovolil commitnout :o) Naneštěstí se s ním nedá než smířit v Makefile či podobných souborech s historickou syntaxí...

[CEST]

Jo, tady mas pravdu. Ale to bych pak klidne prezil, kdyby to vypadalo spis takhle

1 {
2   volání_funkce(
3     dlouhý_argument, 
4     další_argument
5   );
6 }

Ono je fakt nechutny, kdyz nahodou musis na terminalu 80x25 delat neco ve zdrojaku, kterej ma jako odsazeni 8 mezer. To uz pak u 5.odsazeni jsi v polovine obrazovky. Takze kdyz bys tam mel pak nejakou funkci z tvyho prikladu, ktera ma dlouhej identifikator, tak se dostanes nekam hodne k pravymu kraji obrazovky a vlevo bude mit pouze mezery, coz je ti docela k nicemu.

Pak by naopak s TABem zadny problem nebyl, at bych ho mel uzivatel na 2, 4 nebo 8 znaku

1 {
2 Tvolání_funkce(
3 TTdlouhý_argument, 
4 TTdalší_argument
5 T);
6 }

ASCII znak 09 je kontrolní znak, který nemá ve zdrojovém kódu co dělat.

No, ASCII 13 a 10 jsou taky kontrolni znaky a taky jsou ve zdrojacich. Znaky ASCII 13, 10 a 9 (a dalsi) jsou whitespace, stejne jako mezera.

[l4m4]

Ano, jsou klasifikovány jako bílé, s tím se nedá nic dělat. Dokonce GNU coding standard doporučoval (a možná to pořád dělá) vkládat do zdrojáku za konec logických celků form feed (ASCII 12) kvůli lepšímu stránkování vytištěného kódu. Taky dobrá rada ze sedmdesátých let...

Ostatně právě zmatek s označováním konců řádků pomocí různých kombinací ASCII 10 a 13 pěkně ilustruje, že jsou to kontrolní znaky, které byly pouze nesystematicky zneužity k jiným účelům.

[Miloslav Ponkrác]

Já si taky myslím, že jakékoli řídící znaky by se měly ve zdrojovém kódu omezit. A za druhé stopnout všechna pravidla, která se řídí tiskem na tiskárně.

Já se naopak tabelátorům striktně vyhýbám, a pokud dostanu opravit zdroják s odsazováním pomocí tab, první jej překonvertuji na mezery a vrátím v tomto mezerovém tvaru. Nikdo, ani žádný zastánce tabů, ani původní autor ještě nikdy nepřišel na to, že jsem zkonvertoval tabelátory na mezery, takže i z toho jsem vyvodil, že používání tabelátorů je naprosto samoúčelné. Kontrolní znaky nemají (pokud k tomu není vážný důvod ve zdrojáku co dělat).

Samozřejmě, že pokud bych se zúčastnil projektu, který by měl strikně v coding standards odsazování taby, tak bych na konci práce přechroustal zdrojáky na konverzi do tabů. Výše uvedené triky, kdy by bylo nutné odsazovat kombinací tabů a mnoha mezer ve zdrojácích nepoužívám, takže no problem.

Jinak nic proti, ať si každý používá co chce – jsem naprosto přesvědčen, že používání tabelátorů je přejatým nekritickým prvkem z open source projektů a dodržuje se spíše z hrdosti na to, že ten který člověk podporuje danou ideologii, a nektriticky přejme cokoli. Když bude v linux kernel coding style napsáno, že na druhé řádce zdrojáku se musí napsat „Ať žije Alláh“, tak to řada lidí bude dělat a obhajovat to jako nutné, nezbytné, žádoucí a správné, protože je to tak napsáno.

Ohledně konců řádků jsem zavedl, že konec řádku bude znak 10, a znaky 13, pokud se budou vyskytovat se ignorují. Opět lze jednoduše zkonvertovat.

Ještě jsem před časem rozhodl ignorovat pravidlo o 80 znacích na řádek. Není k tomu důvod. Pokud budu ladit delší zdrojový kód, nebudu ho ladit na terminálu s 80 znaky. Pokud si kód budu chtít tisknout, není problém (a u většího balíku zdrojových kódů je to dokonce v rámci úspor silně žádoucí) jej tisknout menším monospaced písmem, takže dostat na výšku na A4 čitelně 120 i více výborně čitelných znaků na řádku není naprosto problém.

Také si myslím, že by se měla silně zrevidovat pravidla ze sedmdesátých let. Řada z nich má stejné odůvodnění jako kdysi moudré nařízení nosit sebou kuš, kopí a štít na svou obranu do nebezpečných míst. Podle mě pravidla „odsazuje se tabelátory“, „dávám do zdrojáku jakékoli kontrolní znaky kromě EOLN“, “omezuji se na 80 znaků na řádek“ jsou už naprostý přežitek nemající opodstatnění. Stejně tak se v DOSu ukončil textový soubor znakem Ctrl-Z, a stejně tak je chybné jakékoli počítání sloupců, či řádků na tiskárně.

Dodržování historických pravidel má pak za následek někdy dost zhoršení projektu. Není to jen v tomto, například řada projektů dodržuje coding style v C++ podle pravidel, která byla užitečná před 15 lety. Firefox je zářným příkladem, doporučuji přečíst, divím se, že někdo podle těchto pravidel chce vůbec programovat.

[CEST]

Hmmm, pri mazani bych mezery misto tabu poznal a pokud bys nemel sirku odsazeni na 2 znaky, tak bych to taky poznal hned.

Me se jenom zda trapny, mazat 8 mezer, kdyz potrebuju snizit odsazeni. Jak jsem psal, zda se mi lepsi pouzivat pro odsazeni jeden TAB, nez ruznej pocet mezer. Nekdo ma radsi 8 znaku, jinej 4 znaky, ja mam rad 2 znaky. kdyz pak dostanu do ruky zdrojak s 8 znakama na odsazeni, abych to bud jak debil konvertoval, cimz se rozhodi to zarovnani u funkci, nebo tam budu cpat svoje 2 znaky a bude to vypadat priserne.

A to neni o nejakych historickych pravidlech. Proste mi to pripada takhle lepsi. Ale budiz.

[Miloslav Ponkrác]

Pokud ten někdo, co používá tabelátory to strojově přesně dodržuje, což jsem ještě nikdy za svých 15 let neviděl.

Druhá věc je si zvyknout, že každý člověk má svůj „pravopis“ zdrojáků mezi což patří individuální počet mezer k odsazování, nebo třeba to, jestli { píše za příkaz, či na další řádek, nebo třeba to, jak pojmenovává proměnné, parametry. Zda raději vypisuje plain typy, nebo si hojně definuje typedef. Způsob rozdělování funkcí/metod/proměnných do více souborů atd..

Pokud člověk není prase, je mi fuk, zda odsazuje 2,3,4,8 mezerami – což jsou tak hodnoty, které jsem viděl používat.

Ale jinak pokud někomu vyhovují tabelátory, budiž, nechť tak píše. Pokud bych dělal v týmu pod někým, kdo by ty tabelátory vyžadoval, dostane je ode mě.

A pokud je někdo prase, tak to žádné tabelátory nezachrání.

Důvod, proč se dříve používaly tabelátory byl úplně jednoduchý. Představte si, že sedíte u počítače, který ma 6 MB hard disk (rok 1990 plus mínus), na kterém se sdílí místo pro celou řadu uživatelů. Pak použitím kombinace tabelátorů a mezer se dal dosti užitečně zkrátit zdroják. Často i řada editorů uměla „smart tab optimalization“, kdy se prostě automaticky řada mezer nahrazovala tabelátory kdykoli to šlo a dělal to editor automaticky. Tehdy se tím ušetřilo dostatečně významné místo, aby to stálo za to. Kvůli odsazování to nikdo nedělal, tabelátory se používaly na zkracování zdrojáky – byl to takový primitivní komprimační algoritmus.

Ostatně můj první program v C jsem psal (pominu-li předchozí pokusy na Amize, na unixech a na VAXu) na počítači bez hard disku jen se dvěma diketovými 360 KB mechanikami. Do jedné mechaniky jsem strčil disketu, kde byly hlavičkové soubory a binární knihovny a musel jsem to sám proházet, aby se to vše do 360 KB vešlo. Na druhé disketě jsem měl binárku kompilátoru + editoru v jednom, to jsem spustil, celé se to nahrálo do paměti. Pak jsem disketu vyráhnul a strčil třetí disketu, na které byly zdrojáky, které jsem vytvářel a ladil.

Čas od času mechanika schroustala disketu, nebo to disketa vzdala, takže jsem měl připravenou novou a jenom jsem prohodil a pokračoval.

Tehdy úspora místa byla naprostá nezbytnost. Takže možnost uspořit bajtíky pomocí nahrazení osmice mezer tabelátorem byla vítaná. Mimochodem, vzpomínám si třeba na Smalltalk – celé prostředí včetně bootování včetně samotného operačního systému pro Smalltalk bylo uloženo na jediné 1,44 MB disketě. Na té disketě byl boot loader, operační systém, plné grafické prostředí, interpretr Smalltalku včetně jeho IDE a persistentní úložiště všech objektů Smalltalku a ještě místo zbylo.

Odsazovalo se tabelátorama hlavně proto, že výsledný soubor byl menší. Zbytek jsou side efekty.

[l4m4]

> Me se jenom zda trapny, mazat 8 mezer, kdyz potrebuju snizit odsazeni.

A proč bych přesouval kursor na začátek řádku a něco mazal, když chci změnit odsazení? Ctrl-T/Ctrl-D fungují i uprostřed řádku. Navíc v 90% případů vim dokáže odsadit správně sám. Většina z těch zbývajících 10% je Python, kde použiji < a > na celé bloky textu a nebudu jako trubka upravovat odsazení po jednom.

[CEST]

Jenze pak musis mit spravne nastaveny shiftwidth, ale mas pravdu CTRL-D/T znam, ale jeste jsem si to tolik nezazil, zatim je proste pro me jednodussi mackat TAB nebo BACKSPACE.

[happy barney]

zamazať 8 medzier?
vi: 8x, resp 8X emacs: [tab] (o.i. i reindent aktuálneho riadku) Ctrl-Alt-\ (reindent aktuálneho bloku)

inak existuje aj program indent, podobné existujú aj pre pre iné jazyky

[default]

Souhlasím.

Ještě jsem před časem rozhodl ignorovat pravidlo o 80 znacích na řádek.

Já zarovnávám maximálně na 100 sloupců. Dělám to hlavně pro sebe (jak sobecké).

Jsem externista a se svým notebookem nemám přístup do internetu, do LAN natož do produkčních systémů. Když už přístup putřebuji, musím jít zpravidla ke kolegovi. A u něho je mi můj terminál 200 na 50 trošku k ničemu. Ti kolegové totiž zpravidla používají výchozí nastavení PuTTY, což je tak trošku málo. Ikdyž na to jejich gzip -cd … | tar -xvf - je to více než luxus. No zkrátka: nechci ztrácet čas ničením jeho zvyků, tak PuTTY zmaximalizuji, čímž se na nějakých 100 sloupců zpravidla dostanu — a jsem v pohodě.

Jiný příklad: vysype se server. Musím jít do serverovny, kde je jen textový terminál. Když server nahodím, můžu hned zkontrolovat to, co jsem nemohl z důvodů výpadku udělat ze své pracovní stanice. Ušetřím tak start několika aplikací a bůhvíco jinýho.

A pro ortodoxní vimaře: je sice hezké, že umíte přepnou klávesnici do binárního režimu a zadat něco podobnýho Wordovýmu dokumentu, čímž se vám tabulátory zobrazí menší. Ale: jak vám to pomůže ve výsledcích grepu? Moc né, že?

[Michal Kubeček]

Vidíte, napsat "ja mam tab radsi nez mezery" už zní o poznání lépe než "spatne odsazeni".

[Karel Zak]

find | grep | grep  ? ... co treba "man find" ?

[CEST]

tak to je drsny. hele, chtel bych pokracovani serialu, ale zkus se nejdriv podivat do manualovych stranek, nez to zacnes bastlit. hned prvni radek jde napsat jenom s pomoci find

find -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*'

Dale, nepise to radky, kde jsou mezery, ale pouze celkovy pocet radku, na kterych je spatne odsazeni. Kdybys chtel cisla radku, tak by to cele bylo nejak takhle

find -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*' \
|while read file ; do
  nl -b a  -s '|' "$file" \
  | grep --label="$file" -H -E '^[[:space:]]*[[:digit:]]+\|\t* +'
done

A jenom bych doplnil, ze testovani prazdnych nebo neprazdnych retezcu je mozna lepsi delat pomoci -n "$str" nebo -z "$str" a testovani cisel se da resit pomoci -gt , -lt, -eq, -ne,.... Oba druhy testu jsou popsany bud v man test nebo v man bash sekce CONDITIONAL EXPRESSIONS

[l4m4]

Borci, když už to předěláváte, tak si přečtěte grep(1), především:

  -n, --line-number
         Prefix each line of output with the line number within its input
         file.

[CEST]

No, vida, grep s cislovanim nepouzivam, takze opet neco novyho:) btw, ten --label jsem taky zrovna nedovano nekde videl:)

No sakra, to by bylo, abychom to nakonec neudelali poradne:) Kdyz uz jsme u toho, tak s pouzitim -n u grep to jde udelat i bez while:)

find -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*' -exec grep -n -H -E '^\t* +' {} \;

pripadne pres pipe na xargs - sice je tam pipe, ale nespousti se na kazdej soubor grep znovu

find -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*' -print0 | xargs -r0 grep -n -H -E '^\t* +'

[hikikomori82]

find | grep -v '.svn' | grep -e '.js' -e '.php' -e '.sh'

vs.

find -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*'

Moj zapis je imbo prehladnejsi a lahsie zapamatatelny, cely skript zbehne za cca 5 sekund. Premature optimizations is root of all evil. Strojovy cas je lacny, programatorov cas nie, etc. etc. etc...

% find ./ -type f \( -name '*.js' -o -name '*.php' -o -name '*.sh' \) -not -path '*/.svn/*'
find: bad option -not

% uname -srv
SCO_SV 3.2 5.0.7

[CEST]

no, jenze pokud timhle stylem budes tvorit dalsi skripty, tak se ti muze stat, ze uz ten skript nepobezi 5 sekund, ale vic.

navic je opravdu videt rozdil, kdyz neco spustis -exec grep a kdyz to spustis -print0 | xargs -0r grep - minimalne na linuxu na x86 je rozdil videt, mozna na unixech ne:)

to neni tak o optimalizaci, jako spis o tom, ze to jde delat jednim prikazem. navic ten tvuj find prochazi i ty .svn adresare, z posila grepu vsechny jmena souboru, pritom by vubec nemusel a mohl by to filtrovat uz ten find, do adresaru .svn vubec nelezt a posilat pouze ty pozadovany jmena souboru. navic, grep provadi zbytecne regexp, kdezto find aplikuje jednoduchy file-pattern.

jde proste o to, nedelat to prasacky, kdyz to jde lip

jinak co se tyka OS, tam bude asi nejvetsi kamen urazu, protoze nektery veci proste na klasickych unixech nejsou. stejne bych ale tomu findu rikal, aby hledal pouze ty vybrane soubory, a pokud opravdu ten find nema neco jako "not", tak pak teprve vyfiltrovat pres grep ty .svn, ale to bych pak filtrovat radsi grep -Fv /.svn, pokud ovsem SCO grep ma -F (ale je to tusim zakladni vec, tak by snad mohl):)

[perdy]

Je lepšie používať sed 's/\t//g' alebo tr -d '\t'?