Jak formátovat kód

31.3.2007 17:46 | informatika | poslední úprava: 16.8.2018 10:11

edited.        

Komentáře

[Petr Zelenka]

A jestli to stihneš vše v jednom zdrojáku, tak jsi überprase (bez urážky) :). Používej, co ti vyhovuje (nebo co je dané v coding standardu projektu, je-li nějaký), ale hlavně se toho drž pořád.

[blogsm]

Právě že stihnu. Např když je if($podminka){jenomECHO "chyba";} tak to klině napíši do jednoho řádku, protože je podmínka velmi krátká.. Já chci vědět co se asi používá nejvíce a já se přizpůsobím a všchny php zdrojáky přepíšu. Hodně je i problém, že mi někdo dodá nějaké skripty, ten má svoje návyky...

[Michal Vyskočil]

No, podle mých zkušeností se většina jednořádkových bloků časem natáhne na několik řádek, takže nemá cenu takto šetřit prostor. Ale jak říkal kolega, je naprosto jedno jaký styl odsazování si vybereš, důležitější je, abys ho dodržoval. Nic jako univerzální styl odsazování není ...

[kozzi]

no tak nejčastěji vidím asi tyto návyky:

if( tmp_int == 1)
{
    tmpStruct.Version = pkgData[index].Version; # komentar
    tmpStruct.Update = 1;
    pkgData[index] = tmpStruct;
}

if( tmp_int == 1){
    tmpStruct.Version = pkgData[index].Version; # komentar
    tmpStruct.Update = 1;
    pkgData[index] = tmpStruct;
}

jinak já doporučuji tu první možnost je to nejlépe čitelný. Jinak jak už jsem psal také záleží na názvech proměných, funkcí, tříd a objektů

[Luk]

Raději:

if (tmp_int == 1)
{
    tmpStruct.Version = pkgData[index].Version; # komentar
    tmpStruct.Update = 1;
    pkgData[index] = tmpStruct;
}

Nesnáším lepení otevírací závorky těsně za if (také for, while apod.). Téměř bych za to vraždil

[#Tom]

Mně to přijde velmi dobré lepit tu složenou závorku k podmínce nebo else, přehlednosti to podle mě neubírá. Takže se připojuju k těm, kteří píší toto:

if (...) {
} else {
}

Ale dřív jsem měl stejný názor jako vy, ani nevím, proč jsem jej změnil… Snad kvůli malému monitoru.

[andree]

presne tak to robim aj ja - setri to miestom a je to najviac prehladne, ked si clovek zvykne (a v takom pythone ten zvyk potom oceni este viac :))

iny (rovnaky) priklad: while (true) { xxx }

tusim ze je to nejaka "norma" od K&R, ktora sa pouziva aj v zdrojakoch kernelu, nie?

co ma ale irituje viac je pouzivanie medzier miesto tabov! kopa programov sa sice v dokumentacii tvari, ze dokaze s medzerami pracovat, ako keby to boli taby.. ako teraz pracujem napr. s eclipsom, ktory snad ani nevie pouzivat taby aj keby mu to clovek prikazal, furt mi po editovani ostane kod alla

if (xx) { abc cde eeer efd }

a to by som fakt ze vrazdil to potom opravovat za editor ]:->

[disorder]

tak to je spravne, 1TBS! K&R nie su hlupaci :)

[Luk]

Jenže já jsem měl na mysli něco úplně jiného. Psát složenou závorku nahoru nevidím jako problém (a dokonce ji i u if/while/for píšu). Nemám rád lepení kulaté závorky na slovo if.

[#Tom]

No fuj, něco takového mi na mysl ani nepřišlo. Tady se shodneme.

[data, not dahta]

Nesnáším lepení otevírací závorky těsně za if (také for, while apod.). Téměř bych za to vraždil

Ja bych zase vrazdil pokud tam nekdo pise mezeru. Proc si tam vy prasatka nenapisete treba tabulator a nebo rovnou 2 at je to poradne prehledny :-/

if              (tmp_int == 1)
{
    tmpStruct.Version = pkgData[index].Version; # komentar
    tmpStruct.Update = 1;
    pkgData[index] = tmpStruct;
}

A pak by jeste mohl prijit nejakej magor co prohlasi, ze taby jsou spatny a tak tam misto nich bude psat 16 mezer

Tohle pouzivaji vsichni co maji IQ vyssi nez sklenicka vody:

if(x != 1) {
	xxx();
} else {
	yyy();
}

[disorder]

> Tohle pouzivaji vsichni co maji IQ vyssi nez sklenicka vody

a nizsi nez prumerny idiot.

[Luk]

No fuj, odsazovat vnitřek bloku o 8 znaků, to přímo bytostně nesnáším. Optimální odsazení jsou 2 znaky (á la většina konvencí C a C++), případně 4 znaky (á la sunovský styl pro Javu). Ale 8 už je opravdu moc.

[disorder]

co ja sa tu nedozviem. takze Sunu dakujem za vynajdenie nastavenia tabov na 4 medzery a tebe, ze nebudem s mojim nastavenim na 8 alebo 4 dalej mrhat svojim zivotom...

[data, not dahta]

No fuj, odsazovat vnitřek bloku o 8 znaků

Ne o 8 znaku, ale o jeden tab, a ten si muzes nastavit libovolne dlouhej. Ja ho budu mit 8 a kaciri at ho maji klidne minus 3.14159

[kozzi]

No já osobně mám podobné potíže, ale většinou jen při psaní než ten zdroják někde ukážu tak to elý převedu do jednotného stylu, který si zrovna zvolím podle nálady . Jinak občas je to fakt nádhera když si pročítám svůj kód a některé proměné jsou psány česky některé anglicky, jedna začíná velkým písmenem druhá malým, jedna na začátku názvu používá název typu druhá má zase na konci za podtržítkem, názvy tříd a funkcí to samé atak dále a tak dále. No ale to platilo pro c/c++. Ale teď si hraju s pythonem a tam se mi celkem daří udržet i při psaní některé zásady čitelnosti. Jinak dopručuju to psát tak jak ti to vyhovuje klidně i jako überprase, je to jen tvá věc teda pokud na tom kdódu nedělá víc lidí. Většinu lidí zajímá funkčnost ne jak to vypadá

[Michal Vyskočil]

Většinu lidí zajímá funkčnost ne jak to vypadá

Ovšem to, jak to vypadá by mělo zajímat toho nejdůležitějšího z nich

[mess]

Preferuju ten první způsob. A odsazovat tabulátorem.

[freshmouse]

/*
reaguje na pritomnost freshmouse
*/
if($freshMouse === 1) {
	# vytiskne hlasku
	print('Je to on!');
} else {
	# vytiskne hlasku
	print('Není to on!');
}

Používám taby a jejich (zobrazenou) velikost mám nastavenou na 3 mezery.

[kozzi]

no tak to je děs

[disorder]

if_(

[disorder]

a tie

/*
 * komentare
 */

a nazvy_premennych su oproti tomu uz len malickost :)

[freshmouse]

Mně se to víc líbí bez mezery, ale je mi to nějak jedno... Komentáře s hvězdičkami na začátku moc nechápu. Mám zvýrazněnou syntaxi, tak to není ani přehlednější, jen to zdržuje, když chci komentář předělat... A promĚnné vs. prom_ěnné? To už je úplně jedno. Stejně jako názvy funkcí (v PHP ).

[disorder]

Komentáře s hvězdičkami na začátku moc nechápu.

oni su hlavne vyraznejsie a prehladnejsie nez tie tvoje

jen to zdržuje, když chci komentář předělat...

ty asi nepouzivas emacs, ze? :) ak ano, tak skus M-j v rozpisanom komentari.

A promĚnné vs. prom_ěnné? To už je úplně jedno. Stejně jako názvy funkcí (v PHP ).

viem, bavime sa o PHP, ale preco to zhorsovat? esteze je tu zase emacs a glasses-mode :)

[freshmouse]

A promĚnné vs. prom_ěnné? To už je úplně jedno. Stejně jako názvy funkcí (v PHP ).

viem, bavime sa o PHP, ale preco to zhorsovat? esteze je tu zase emacs a glasses-mode :)

To se nezhorší! Jde jen o to, používat jeden styl -- pro jeden se člověk musí rozhodnout. Osobně se mi zdá, že se směřuje k promĚnným a funKcím, tzn., že tak 65% nových funkcí / tříd je v tom stylu.

Emacs? Zatím mi GNU/Linux docela stačí.

[disorder]

To se nezhorší! Jde jen o to, používat jeden styl -- pro jeden se člověk musí rozhodnout. Osobně se mi zdá, že se směřuje k promĚnným a funKcím, tzn., že tak 65% nových funkcí / tříd je v tom stylu.

nie, horsie uz to mozes pisat len zo srandy. kazdy si moze smerovat kam chce, ja budem pisat to co sa lahsie cita (preco sa to asi v C tak osvedcilo, ze)

Emacs? Zatím mi GNU/Linux docela stačí.

ty sa stazujes, ze sa ti tazko pisu komentare.

[freshmouse]

Neříkám, že se to čte lépe nebo hůře (mně osobně se to čte stejně dobře). V C se mohlo osvědčit co chtělo, ale důležité je se řídit jazykem, v kterém píšu -- dělat něco jinak oproti vestavěným funkcím nebo třídám není dobré... Je to jako do Pythonu chtít mermomocí přidávat složené závorky na okraje bloků...

Já si nestěžuju, že se mi špatně píšou komentáře! Psaly by se mi špatně, kdybych psal /* *\n*\n*\n* */. Jenže to já nepíšu, není třeba -- přehlednost to podle mě nezvýší -- to bych si raději nechal komentáře zvýraznit tučně nebo zadal barvu pozadí textu (což ostatně mám nasatveno).

[disorder]

důležité je se řídit jazykem, v kterém píšu -- dělat něco jinak oproti vestavěným funkcím nebo třídám není dobré...

a preveze je to este lepsie, pretoze jasne uvidis, ze to je tvoja funkcia. neviem kde je problem ked ti interpreter/kompilator berie podtrzitka

Já si nestěžuju, že se mi špatně píšou komentáře!

ale no, priznaj si to. teraz to len zahovaras, pretoze si nevedel, ze sa to da pisat pekne a lahko zaroven :P a v kazdom pripade je to prehladnejsie pre vela ludi

[Ladicek]

Psaly by se mi špatně, kdybych psal /* *\n*\n*\n* */. Jenže to já nepíšu, není třeba --

píše to vývojové prostředí.

[CandySan]

Komentare s hvezdickama na zacatku kazdeho radku mohou mit i zasadni vyznam.

[freshmouse]

U PHP?

[CandySan]

myslim, ze se to jazyka nikterak netyka. Spis vic se to tyka cehosi jako eclipse apod nebo ruznych documentoru ale take samotneho psani. Ja jsem si osvojil tento postup a vyuzivam jej i k ocisteni bloku kodu od pozdejsich nasilnych uprav Zastavam nazor, ze lepe se modifikuje, skrta a maze lidsky text nez blok kodu, takze kdyz uz nic, tak alespon me to donuti nejprve do detailu promyslet a popsat vnitrek tridy, funkce ci metody a az pak ten blok kodu pisu dle teto predlohy. Doporucuju zkusit! V eclipse pak jako bonus staci najet mysi na instanci classy, nebo na jmeno funkce a hned se mi v bubline objevi muj komentar (tedy jen cast - popis te veci) a vsechny vstupy,vystupy a jejich typy. dokumentacni soft mi zase udela manual (pro me) abych v nem mohl najit vec co chci (je-li tech samostatnych bloku hodne moc) atd... Aktualne delam na projektu, ktery by me bez techto "komentaru s hvezdickami" jiz davno prerostl a ztratil bych se v nem, protoze ja jsem hlava derava a opravdu nic si nepamatuju. Obdivuju kolegy, kteri se ke svemu kodu vraceji i po letech po pameti (vlastne bezpecne vim jen o jednom a jeho kod tedy moh byt megaprasarna a taktez megaprasarnou byl a je), ale ja si musim za sebou vzdy drobit chleba

[happy barney]

všade, aj u PHP, porovnaj si výsledok:

cat <<EOF > a.php
   $dbname = 'ostra';
/*
 * $dbname = 'testovacia';
 */
EOF

grep dbname a.php

[deda.jabko]

btw. je dobre minimalizovat pocet komentaru oprostred kodu.... spousta lidi ma ve zvyku komentovat opravdu kazdy krok a pak je to brutalne neprehledne.... idealni je komentovat jenom funkce/metody... a pokud je v kodu nejaky nepochopitelny kod, mel by byt ve vlastni metode, kde z nazvu a pouziti parametru jde poznat co dela...

/**
 * Vypise hlasku na standardni vystup
 */
function vytiskniHlasku($text) {
        print($text);
}

....

if ($deda->jabko == 1) vytiskniHlasku("Jsem to ja");
else vytiskniHlasku("Nejsem to ja");

[freshmouse]

Jasně, já to tam napsal jen proto, že komentáře uvnitř funkce / metody píšu s "#". Taky nekomentuju každé print().

[Abraxis]

Myslim si, ze:

a, v dobe "indentu" je formatovani kodu celkem jedno - preformatovat si jej k obrazu svemu je otazka jednoho prikazu - spise se jedna o to spravne pojmenovat promenne, fce apod.

b, cat /usr/src/linux/Documentation/CodingStyle

[finc]

V době superuživatelských IDE, nejde ani o ten název proměné či metody, k čemu bychom pak používali refactoring :) Jinak je to spíše o dlouhodobějším programování. Každý ti doporučí něco jiného. Dobré se držet jednotného fotmátování a ten už neměnit. Osobně mi je nejsympatičtější Java style.

[Ladicek]

Jak už bylo řečeno, hlavně konsistentně. Formátování není od toho, aby prudilo při psaní, ale aby usnadňovalo čtení. Automatické formátovače můžou napomoci (miluju Ctrl+Alt+L ), ale nejsou samospasitelné.

[Milo Kmeť]

Ja sa držím tohoto coding standardu. ...teda väčšinou...