Ciklus és feltételes blokkokon belül, ha csak egy utasítás van...

Programozás

...akkor is mindig kiteszem a { } -eket
55% (389 szavazat)
...csak akkor teszem ki a { } -eket, ha zavarja a hiánya az olvashatóságot
26% (182 szavazat)
...sosem teszem ki a { } jeleket, mert csak több utasítás esetén muszáj
6% (43 szavazat)
Egyéb leírom hozzászólásban
2% (15 szavazat)
Nem tudok programozni
11% (79 szavazat)
Összes szavazat: 708

( gojruht | 2012. 04. 04., sze – 10:24 )

A "...sosem teszem ki a { } jeleket, mert csak több utasítás esetén muszáj"-t választottam, mert erre törekszem, néha lustaságból/figyelmetlenségből bent hagyom a { }-t persze. Szerintem az olvashatóság javul azzal, ha nem teszem ki, mivel ezzel is hangsúlyozom, hogy csak egy utasítás van.

( uid_15426 | 2012. 04. 04., sze – 10:26 )

Attol fugg, hogy az adott kornyezetben mi a konvencio, gondolom.

----------------------
while (!sleep) sheep++;

( crystal88 | 2012. 04. 04., sze – 10:27 )

akkor is kiteszem a {}-eket, kivéve, ha az az 1 utasítás megszakítja a szülő-blokk futását, tehát pl. break, continue, throw esetén

( kelytha | 2012. 04. 04., sze – 10:28 )

Mindig kiteszem, kivéve ha éppen golfozunk. :)

( nevergone v | 2012. 04. 04., sze – 10:29 )

Kiteszem a jeleket és alkalmazom a Drupal Coding standards-ot.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Pedig nem csak őket. Szerintem bárki lehet fáradt, akadhatnak kódolás közben más teendői is, illetve szükség lehet nagyon gyors hibajavításra. Érdemes már a kód írásakor kizárni minél több hibalehetőséget.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Szerintem olyan nincs, hogy te döntöd el, milyen legyen a konvenció. Ha zárt forrású és teljesen új dolgot csinálsz, akkor talán. De egyéb esetben mindenképpen alkalmazkodni kell valamihez.
Speciell én azokat a kódolási szabványokat jobban szeretem, amikben nem kell kitenni a {-t (pl. MFC), de azok eltűnőben vannak.

( uid_194 | 2012. 04. 04., sze – 10:31 )

Milyen nyelvrol van szo? Van amelyik megkoveteli, hogy kitegye az ember, van amelyik megengedi, hogy ne. Es van ahol nincs {}, de nyilvan nem ez utobbiakrol szol a szavazas.

--
|8]

( Exit | 2012. 04. 04., sze – 10:39 )

A projektben beallitott automatikus kodformazora bizom.
Ha nekem kell beallitani a formazot, akkor a "sosem teszem ki a { } jeleket, mert csak több utasítás esetén muszáj"-t preferalom.

( mn3monic v | 2012. 04. 04., sze – 11:01 )

Jobb az ha ki van téve. Nem lesz tőle lassabb a program, kevesebb hiba lehetőség, ráadásul szerintem áttekinthetőbb.
--
HUPbeszolas FF extension

Az adott esetben gyakorlatilag 0 eselye van annak, hogy kesobb tobb soros legyen az if. Olyan esetekben en is kipakolnam, de ugyanakkor azok nem is ismetlodnek annyit, tehat nem rontja az olvashatosagot.
+ eleg szigoruan veszem a kommentezest. Altalaban annyi kommentet irok, hogy ha a kod elveszne, akkor is ujra tudjam irni a programot. (Nem azert, mert ez elofordulhatna, hanem mert igy lehetek biztos abban, hogy elegendo kommentem van.) Ez azt jelenti, hogy az if-eken belul is szokott lenni legalabb egy sor ami megmagyarazza, hogy mi tortenik itt. Azt meg mindenkeppen kulon sorba veszem.
Szoval en nem vallasi ugyet csinalok a dologbol, hanem igyekszem a kod olvashatosagat figyelembeveve donteni.

Miert ne lenne egyszeru? vprintf, vsprintf... En kezdo C-s vagyok, de csinaltam mar ilyet.

A verbose meg lehet #define is, vagy a konfig resze is (get_param('verbose')), vagy akarmi. A lenyeg, amit meg akartam mutatni, az az, hogy ha ezt refaktoralod egy fuggvenybe, akkor a kodod atlathato marad, es csak egy helyen van dontesi logikad.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

"A verbose meg lehet #define is, vagy a konfig resze is (get_param('verbose')), vagy akarmi."

Nade pont az a lenyeg, hogy fuggvenyenkent/alrendszerenkent eltero lehet. ;)

Persze, lehet ra talalni mas megoldast is, de igazabol az egy soros if tökéletesen megfelelt a célnak. Miért ne használnám?

Mert ha EGYSZER rájössz, hogy mégse úgy akartál logolni... Sosem kopipasztázunk, ha már kopipaszta valamiért, akkor #define, az ugyanazt csinálja, csak nem kézzel.

"fuggvenyenkent/alrendszerenkent eltero lehet"

Ezt neked is kezelned kell az if-eidben, egy darab asszociatív tömb a megfelelő paraméterezéssel simán letárolja neked akárhány függvény és subsystem paramétereit.
----
Hülye pelikán

"Mert ha EGYSZER rájössz, hogy mégse úgy akartál logolni... Sosem kopipasztázunk, ha már kopipaszta valamiért, akkor #define, az ugyanazt csinálja, csak nem kézzel."

Ebben a programban nem fogok így járni. Nagyobb projektnél meg eleve máshogy kezeltem volna a logolást. Szerintem problémához kell választani az eszközt és nem meggyőződésből használni valamit.

Felmértem a projekt méretét (~2000 sor kommentek nélkül), a program élettartamát (~6 hónapra kell) és jövőbeni újrafelhasználhatóságát (nagyon feladatspecifikus) és arra a következtetésre jutottam, hogy az if(verbose) pontosan illeszkedik a feladathoz. Amennyiben a jövőben tényleg át kell majd írnom, komolyan írni fogok ide. Be is írtam kommentbe a téma címét.

Biztos, hogy kell ez így? :)

Miért nem valami logger framework-öt haszálsz? Amiben így nézne ki (a loglevel-nek megfelelően): 


log.trace(...);
log.debug(...);
log.error(...);

És a loglevelt menet közben is tudod állítani. Nem hinném, hogy C/C++ esetén nincs ilyen lehetőség, mint a log4j vagy slf4j, és rettentő sok szívástól mentesülsz, illetve a program is sokkal olvashatóbb lesz.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

( asch v | 2012. 04. 04., sze – 11:03 )

Egyetemen egyik barátom felvett egy választható programozós órát. A végén megkérdeztem tőle, hogy mit tanultak ott. Azt válaszolta, hogy a tanár szerint a blokk jelölő zárójelet mindig ki kell tenni.

( _Franko_ v | 2012. 04. 04., sze – 11:25 )

Régebben nem tettem ki, aztán jöttek mindenféle elemző szoftverek, amelyeknél jelentősen rontja a metrikákat (és ezzel növekszik a technical debt), ha nem átlátható és könnyen karbantartható a forráskód. Ha nem tesszük ki mindig a blokk elejét-végét, akkor ezzel jövőbeli magunkat vagy másokat szivatunk meg, tehát többe kerül majd a módosítás -- és ezzel egyet is tudok érteni, szóval érdemes elgondolkodni, hogy bizonyos dolgok mit okoznak.

Java esetén a Sonar-t érdemes használni ilyesmire, itt egy példa: http://sonar.javaforum.hu/dashboard/index/209
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

OFF: azt hogy csinaltad meg, hogy a Jenkinsben zold pott egybol a konzol kimenetre visz a Build History-ban? Ilyet szeretnek en is itthonra, Jenkins mar van.

Kozben meglett. Kar, hogy ezt csak erre a pottyre lehet automatizalni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A megoldas nagyon banalis: default igy van, de csak es kizarolag a build historynal. Nekem olyan kellene, hogy ha elfailedezik egy job, akkor a job nezetbol tudjak odanavigalni a konzoljara, mert altalaban ugyis valami egyszeru hibaja van (tegnap pl. volt egy connection timeout-om mert doglodott a slave netje).
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( ishida | 2012. 04. 04., sze – 12:10 )

A zavarja az olvashatóságot az mit jelent? "Szerintem" vagy valamilyen standard szerint?
Pl. gondolom van akit nem zavar egy ilyen:

if (feltetel1)
if (feltetel2) {
utasitas1;
utasitas2;
utasitas3;
...
utasitasn;
} else {
utasitas1;
utasitas2;
};

Hisz a külső if-nek a belső csak egy utasításnak számít, legyen az bármennyire összetett is. Így ident nélkül az igazi :)
Jobb ha az ember valamilyen jól definiált szabály (coding style) alapján kódol és nem saját szubjektív ítélete alapján. Pl: http://leaf.dragonflybsd.org/cgi/web-man?section=9&command=style

Hat, ebben az esetben pont, hogy zavarja az olvashatosagot, mert elo kell venni az epp hasznalt nyelv kezikonyvet/szabvanyat, es megkeresni a kevesbe gyakorlott programozonak, hogy szemantikailag az az else az elso vagy epp a masodik if-re vonatkozik -- ellenkezo esetben kellemetlen meglepetesek erhetnek.

Kétségtelen, hogy egy 5-10 fős csapatban mindig lesz 1-2 olyan ember, akit még az is zavar, hogy az egysoros elágazások nincsenek zárójelezve. Bár ezeket az embereket más is zavarni szokta, így nem túl nagy karriert futnak be projekteken belül. A legutóbbi ilyen pl elment szülni...

Én úgy vagyok ezzel, hogy ne egy-két ember legyen, akit ez zavar, egyszerűen kell release folyamatba jónéhány elemző program, amelyek majd ügyelnek arra, hogy az adott forráskód az értelmes és hasznos metrikák mentén fejlődjön.

Már említettem volt a Sonar-t (pl.: http://sonar.javaforum.hu/dashboard/index/209), kérlek futtasd le a projektedre és mondj néhány jellemző értéket, ha Téged zavar az a néhány ember, akit zavar a jó minőségű kód... :)
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Fogalmazzunk úgy h a jelenlegi projektjeinkkel kapcsolatban nem lenne korrekt a részemről :)
Másrészt meg a kód formai része épp az imént említett eszközök miatt sem kifejezetten a minőség részhalmaza, inkább csak van egy kisebb metszete.

Engem inkább az zavar ebben az egészben, hogy pár ember képes ennyire fennakadni a kisebb formai eltéréseken, akár support/bugfix, akár review a szempont.

Sok kicsi sokra megy, elég egy tucatnyi ilyen elvárást figyelmen kívül hagyni és csak növekszik-növekszik a végtelenségig a technical debt.

Ha support/bugfix kapcsán nem javul ki a hibás kódformázás, abból könnyen újabb hibajegyek esnek be, amelyek tudábbi hibajegyeket generálnak... a review-nál is oda kell eljutni, hogy automatikus eszközök végezzék a review nagy részét, és ne egy drága senior ideje menjen arra, hogy kitegye a szükséges megjegyzéseket, zárójeleket és szóközöket, hogy olvasható(bb) legyen a kód, mert ezzel több idő jut a valódi review-ra, szóval ha valakinek review kapcsán szólnia kell, hogy nem megfelelő a kódformázás, az már régen rossz...
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Hát az tény h eléggé le vagyunk maradva az automatizálással, de ennyire azért ne áss el.

A kódformázás megváltoztatásával kapcsolatban nekem elég szar tapasztalataim vannak. Merge-nél állati nagy galibákat okozott. Meg nem is arról beszéltem, hogy van egy konvenció, és attól eltér mindenki egy kicsit, hanem h ilyen esetekben rugalmas a konvenció.

Engem inkább az zavar ebben az egészben, hogy pár ember képes ennyire fennakadni a kisebb formai eltéréseken, akár support/bugfix, akár review a szempont.

csúnyává teszi a diff-et.

http://hup.hu/szavazasok/20120404/ciklus_es_felteteles_blokkokon_belul_…

Értsd jól: Hozzáadsz egy plusz sort és a diff-ben már nem csak a plusz sor fog látszódni, hanem feleslegesen a blokk nyitó-záró jelek is. És igen, egy nagyobb review-nél ez okozhat gondot.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

Hát igen. Vegyük azt, hogy az utasítások valóban egyszerűek. Hogy ezt is egy példával szemléltessem (tegyük fel, hogy valamiért nem használunk feltételes kifejezést) Kinek melyik az átláthatóbb forma:

if (kifejezes) utasitas1;
else utasitas2;

vagy:

if (kifejezes) { utasitas1; }
else { utasitas2; }

esetleg:

if (kifejezes) {
 utasitas1;
} else {
 utasitas2;
}

Nálam ez úgy működik, hogy beírom: 


    if (3==2) System.out.println("");
    else System.out.println("");

Nyomok egy Ctrl-Alt-F kombinációt, és lőn: 


    if (3 == 2)
    {
      System.out.println("");
    } else
    {
      System.out.println("");
    }

Gyakorlatilag semmibe nem kerül.
--
http://wiki.javaforum.hu/display/~auth.gabor/Home

Ötletnek nem rossz, de nem is annyira jó. Így a fejlesztő a saját kódjára sem ismer rá egy összetettebb esetben...

Mindegy, kezd egy kicsit teoretikus lenni a dolog. Pusztán arra akartam kilyukadni, hogy ha egy kódnál az a legnagyobb probléma, hogy az egysoros elágazások hogyan vannak formázva, akkor az egy álomprojekt :)

( fabian-bros | 2012. 04. 04., sze – 12:22 )

Nekem kettő is igaz.
Mindig kirakom (későbbi bővíthetőség nevében)
ÉS
Nem tudok programozni

--------------------------------------
Unix isn't dead. It just smells funny.

( numen v | 2012. 04. 04., sze – 12:25 )

Mindig kiteszem, de feltételes blokk helyett gyakran használok ternary operatort, amennyiben az az olvashatóságot nem rontja/javítja.

int getRandomNumber() { return 4; }  // ← aláírás
//szabályos kockadobással választva. garantáltan véletlenszerű.  xkcd

( uid_5143 | 2012. 04. 04., sze – 12:31 )

Szeretem az IDE autoformázásokat (NetBeans-t használok), így ő mindig kiteszi helyettem. Egyébként is ki szoktam tenni, de fájl mentés előtt mindig kódformázok :)

( emberk | 2012. 04. 04., sze – 12:47 )

A másodikra szavaztam (én C,Cpp-re gondoltam elsősorban), de nem csak ennek függvénye. PL ha egy ciklusnak még nem tudom a pontos megoldását akkor kirakom, mert ha nem csak egy sor, akkor bármi lenet, és jobb ha megvan hogy mi tartozik a magba.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

( xea v | 2012. 04. 04., sze – 12:58 )

Mindig kiteszem a zarojelet es masokat is erre buzditok. Eleg volt parszor beleszaladni abba az (amator) hibaba, hogy tobb emberes munkaknal valaki kiboviti az adott feltetelhez/ciklushoz tartozo blokkot, de a zarojelet mar elfelejti, majd csodalkozunk a program erdekes mukodesen. Ha ott a zarojel, kevesebb a hibalehetoseg.

Tovabba azt gondolom, hogy azokban a fuggvenyekben/metodusokban/muveletekben, amiknek az olvashatosagat ket zarojel jelentosen lerontja, ott ennel sulyosabb problemak is vannak. Azon az allasponton vagyok, hogy a kod legyen konzisztens.

- Not even the slightest bit -

Nézd, én az olvashatóságot tekintem elsődlegesnek a formázásnál is. Volt egy ismerősöm, aki iszonyat olvashatatlanul írt kézzel, így anno fősulin, egyetemen a jegyzetei használhatatlanok voltak, de később dolgozni sem volt vele egyszerű. De amikor megláttuk, hogy a kezéből kiadott kód is ugyanolyan eszetlen ronda, akkor kínunkban már csak röhögtünk, pedig zárójelezett a szerencsétlenje szorgosan.

Arra akarok ezzel kilyukadni, hogy nem a zárójelen és a sortörésen múlik az olvashatóság, és ezzel együtt a review/support minősége.

Nekem meg éppen hogy nem. Az if amúgy is kijelöli a blokk elejét, a lezáró kapocs pedig a végét. Indentálással teljesen jól látszik, de még anélkül is szerintem jobban mint ha a kezdő kapcsos zárójel a sor elején állna. Úgy kicsit olyan, mintha az if egy magában álló utasítás lenne, és utána jönne egy blokk, amelyik nem tartozik hozzá.
De elismerem, ez leginkább csak szokás kérdése. Ahány ember annyi féle. Neked így tetszik, nekem úgy.

( uid_2813 | 2012. 04. 04., sze – 13:44 )

Amig nem muszaj nem szoktam kirakni a zarojeleket, nem emlekszem olyan esetre hogy ebbol problema lett volna. Hozza kell szokni, hogy a plusz utasitas irasakor nem vaddiszno modjara nekiugrunk a begepelesnek, hanem eloszor kitesszuk a zarojeleket. Normalis indentalasnal meg egyenkent is rogton szurna a szememet, hogy valami nincs rendjen.

Jobban utalom az olyan kodokat ami az elso kategoriaba esik es szinte olvashatatlanna/atlathatatlanna* teszi a kodot, igy inkabb kockaztatok.

*A kod nem kitalacio es nem en irtam(csak modositottam rajta annyira, hogy a keszitoje talan nem ismer magara, de egyebkent az eredetiben is egysoros kifejezesek vannak). :)

Igazából ezt a plusz sorok-, utasítások hozzá/beleírását nem is tudom értelmezni. Van egyáltalán olyan, aki úgy folytat egy kódot, hogy "na most beírok mondjuk a 115. sorba egy új utasítást, leszarom, hogy mi van körülötte"?
Akinek nem tűnik fel, hogy ahová ír, az már nem egy blokk része, az menjen inkább malacokat őrizni (vagy szülni :))

( pampipudli | 2012. 04. 04., sze – 14:08 )

Konvenctiotol fugg nalam, a konvencio pedig a nyelvtol.
Azert orok szabaly szamomra, hogy ha az egyik agnal kiteszem, akkor mindenkeppen a tobbinel is.

( mogorva v | 2012. 04. 04., sze – 14:28 )

A fenti hozzászólások alapján sokat segítene az eredmény értelmezésén, ha azt is lehetne tudni, hogy a válaszadó
- mennyi 1 személyes
- mennyi 1-3 személyes
- mennyi 3+ résztvevős
projektben vett részt.

( KoGa v | 2012. 04. 04., sze – 15:36 )

Akkor most johet a szavazas a {} elotti/utani sortoresrol :)

( Finder | 2012. 04. 04., sze – 17:29 )

"...csak akkor teszem ki a { } -eket, ha zavarja a hiánya az olvashatóságot"
Alapvetően ezt követem. Ha rövid a dolog, pl. if(verbose) vprint(...); akkor ott rontja az olvashatóságot a {}, azonban ha túl hosszú a sor és ketté kéne szednem, akkor mindenképpen kirakom a {}-t. Ugyanez a helyzet akkor is ha az if ágon belűlre tartozik egy komment. Inkább kirakom a {}-t és abba írom a kommentet is, így aki arra a részre nem kíváncsi, az ki tudja hagyni. Nem szokott gondom lenni a programjaim megértésével. :)

( phaul | 2012. 04. 04., sze – 20:37 )

mindig kiteszem a {}-et, mindazonaltal az iparban eltoltott n+1 ev C programozas es masok altal irt kodok debuggolasa soran nem emlekszem hogy akar egyszer is elojott volna mint bug (ahol ures a ciklus mag pedig eredetileg a kovetkezo utasiasnak a ciklusmagnak kene lenni). Viszont ha ures ciklust akarok, vagy direkt kihagyom a break-et egy switch-bol odabigyesztek egy kommentet hogy igen, ezt akartam. vhogy igy: 


for(i = 0; i < 2; i++) ; /* ; intended */

/* don't break in this switch */
switch (n)
{
  case 2: n++;
  case 1: n++;
}

Lint operal hasonlo kommentekkel btw

( hokuszpk | 2012. 04. 04., sze – 22:07 )

eddig abban a hitben eltem, az igazi programolók a prog.hu -n tombolnak.

( gaby | 2012. 04. 05., cs – 10:18 )

Még az ilyen apró "programnál" is mindig kiteszem. :-D
:(){ :|:& };: