GCC 6: -Wmisleading-indentation vs. "goto fail;"

 ( trey | 2016. március 2., szerda - 13:19 )

Arról már volt szó január közepén, hogy a GCC 6-ban megjelenik majd egy új figyelmeztetés, a -Wmisleading-indentation. Az új fordító figyelmeztetés szerzője, a Red Hat alkalmazásában álló David Malcolm blogbejegyzésben mutat példát a -Wmisleading-indentation hasznosságára. Például az Apple hírhedt goto fail; mellényúlását használta például...

A blogbejegyzés itt olvasható.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

python:Đ

:-D

Van egy rakat (de egy biztos) statikus analizalo tool, miert nem hasznaljak inkabb azt. Ill. mi ertelme ilyeneket, meg tobbet, implementalni egy gcc szeru forditoba?

egy ellenőrzés vagy a fordító része, ilyenkor gyorsan (remélhetőleg még commit előtt) kapsz visszajelzést, viszont az ellenőrzések a fordítási időt lassítják, vagy valamilyen külső statikus analizáló eszközbe rakod, ilyenkor lassan kapsz visszajelzést, viszont a fordítás gyorsabb.

feltételezhetően a számítókapacitás növekedésével ma már a fordító elfogadható, hogy sokkal több mindenre vizsgál, mint évtizedekkel ezelőtt.

Optimális esetben a fordító már csinált egy modell-t a memóriában, erre lefuttatni még azt a pár ellenőrzést nem igazán nagy effort, de a kód
minőségét nagymértékben javítja.

a redhatesek mindig ilyen faszsagokat csinalnak ha a gcc-hez nyulnak...

Csak nem felvették Diego Biurrunt is? :)

(nemide)

Szerintem is fasság. Az eredeti hiba valami olyasmi volt, hogy az "if(...)" után 2-szer volt egymás alatt "goto fail;", majd jöttek még egyéb utasítások. A 2. "goto fail;" már feltétel nélkül futott, de a buta magyarázat szerint nem szúrta ki senki, mert ugyanúgy volt indentálva, mint a fölötte levő. Ez azért fasság, mert a fordító ilyenkor dob egy "statement unreachable", vagy hasonló warning-ot. Vagyis warning nyilván volt, csak éppen nem foglalkoztak vele. Most akkor majd 2 warning-gal nem fognak foglalkozni.

"Ez azért fasság, mert a fordító ilyenkor dob egy "statement unreachable", vagy hasonló warning-ot. Vagyis warning nyilván volt"

Nem nyilván, csak ha -Wunreachable-code opcióval fordítottak (ami nem része -Wall-nak), és a fordító is elég okos volt hozzá.

Na jó, hogy írod! Utánanéztem, és kiderült, hogy már az sem működik:
https://gcc.gnu.org/ml/gcc-help/2011-05/msg00360.html

Az Atmel Studio-ban 4.4.7-es GCC van, azzal még működött, de a 4.8.4-ben már semmit nem csinál. Akkor a fönti kiszólásom sztornó.

Oh, és tényleg. Az fenti "ha elég okos" kitételem arra vonatkozott, hogy az épp kéznél lévő gcc nem figyelmeztetett egy sebtiben összedobott goto fail tesztkódra, mire azt hittem, hogy nem elég okos. Erre kiderül, hogy a "-Wunreachable-code" már csak noop.

Persze Apple-t ez nem menti fel, ők akkor már javában clang-gel fordíthattak, abban meg műküdik, használhatták volna.

Nagy jóság. Én is beraktam egy ilyen hibát figyelmetlenségből a vte-be (gnome-terminal), enélkül valszeg soha észre nem vettük volna.

Nem lenne amúgy egyszerűbb mindig kiírni azt a { és } karaktert?

Franc se tudja. Vannak előnyei-hátrányai is mindkét megközelítésnek.

Hátránya, hogy úgy nehezebb hibát becsempészni? :)

Boldog python kóderek... Nekik nem kell ilyen kisppolgári csökevényekkel, mint {} foglakozni :-P

Hahaha, csak a tab vs space mixinggel :D

+1

milyen előnyei vannak?
--
blogom

A két karakter leütést megspórol, ami 0.2 másodperc, cserébe 3 órát debuggolhat, miközben a főnök üti, hogy már MEGINT MIÉRT NEM MEGY EZ A SZ*R :)

Helyet nyersz. Függőleges helyet. Formázási stílustól függően 1 vagy 2 sort. Annyival több fér ki egyszerre a képernyőre. (Rakat egyszerű "if"-ecske esetén simán lehet másfeles a szorzó.)

Beirod hogy
if (kaki) {
barna; }

es kesz. Mar igy is latszik, ki kivel van, az editor egybol jelzi, es tenleg 0.2sec a tobb leutes miatti kesedelem. (aki lusta ket karaktert leutni, hogy sporoljon, szerintem nem programozzon ;)

Az menjen python programozónak :-P Bár ott mefg más miatt kell néha sokat billentyűnyomkodni :-D

Gyönyörű! És ha több soros az indentált rész, akkor is az utolsó sor végére teszed a bezáró kapcsot?

Vajon miért nem láttam még sehol sem ezt a stílust??

nem, egy sorosnal
if (aa) {
bbb; }

tobb sorosnal mar siman irjad igy:
if (cc) {
dd;
ee;
ff;
}

ha mar a masodik verzio annyira szornyen pocsekolo neked :)

en mindenhol masodikat hasznalom, egy soros {} pertalomanl is. mert az nekem jo, es legalabb mindig latszik, mi van a scope-on belul.

Remélem, továbbra sem gondoltad komolyan az első verziót :) Nem is értem, miért javaslod, ha Te sem használod, és feltehetőleg Te sem láttad még sehol sem. Valamint szerintem undorítóan néz ki. Továbbá a kapcsot elhagyó stílushoz hasonlóan ugyanúgy megvan az a hibája, hogy a kód utólagos átszerkesztése során könnyen be lehet nézni és hibás kódot hozni létre, melyet csak egy -Wmisleading-indentation segít megfogni.

Félre ne értsd: nem állítom, hogy a kapocs elhagyása egysorosok esetén jobb lenne, mint a következetesen mindig kirakása. BaT és vilmos.nagy kérésére írtam egy szempontot az előbbi mellett, de nem hoztam ítéletet egyik mellett sem.

Nem mondom, hogy szep, de de egy if(a) goto fail; goto fail; -nal BARMI szebb :)

Nagyobb monitor, kisebb betumeret, scroll / zoom, stb, ne adj isten jobban strukturalt kod.

"Helyet nyersz"
Ezt nem kellett volna mondani. Vicces. Itt egy fuggvenynek lehet egy fajlt szentelni. Itt lehet 11446 soros borzadalyt csinalni. Tehat kell a hely...

Wow, belinkeltél két fájlt egy projektből, amelyet aktívan szerkesztgetek, de eredetileg nem én készítettem! Most ezzel mit is akarsz mondani? És tényleg, őszintén, a kód minőségét az alapján ítéled meg, hogy hány soronként van külön fájlra szedve? Igazán menő! (Ja, nem.)

"hely" alatt arra utaltam, ami egyszerre kifér a képernyőre. És hogy fdavid társunk kommentjére reagáljak itt: anélkül, hogy nagyobb monitort kelljen vennem, vagy jobban meg kellene hogy erőltessem a szemem.

"És tényleg, őszintén, a kód minőségét az alapján ítéled meg, hogy hány soronként van külön fájlra szedve?"

tapasztalatom szerint eleg eros az osszefugges

--
NetBSD - Simplicity is prerequisite for reliability

Hany ember lat at egy tobb, mint 11ezer soros fajlt? Szerintem atlathatatlan. Nem normalis kod strukturalasra utal. Hanem ganyolasra. Ilyenek miatt kell a GCC-be ilyen kapcsolok.

Wow, újabb kiba értelmes hozzászólás!

Láttad már a kódot?

Van javaslatod, hogyan struktúráljuk át? Patch?

Tényleg fájlok számában mérjük a kód mennyiségét és minőségét?

Ha szétdarabolnánk több kisebb fájlra, mitől lenne bármivel is átláthatóbb? Mitől lenne számottevően könnyebb 11 darab ezer soros fájlt átlátni, mint egyetlen 11 ezer sorosat?

Miért kell, hogy bárki átlásson egyszerre 11 ezer sor kódot? Te át tudnál látni ennyit? Szerinted nem úgy működik a fejlesztés, hogy azt nézed át, ami épp érint? Hogy a függvényt keresed a neve alapján, és kábé tök mindegy hogy melyik fájlban van?

És leginkább: Ha szétdarabolnánk, miért is csökkenne bármivel az esélye, hogy a tizeniksz évnyi fejlesztés során egyetlenegyszer becsússzon egy indentálásos-kapcsoszárójeles hiba?

Nem azt mondom, hogy így jobb, mintha szét lenne darabolva. Azt mondom, hogy ez van, így fejlődött történelmileg, és hogy rohadtul nem ezen múlik semmi sem.

(Őszinte szívből jövő gratulációmat küldöm mindenkinek, aki azt, hogy bekommenteltem, hogy az új GCC warningnak nagyon örülök, mert megfogott egy hibát, amit én vétettem, és a projekt fő fejlesztője sem szúrt ki, arra használja, hogy nekiálljon kritizálni az egész kódbázisunkat totálisan irreleváns szempontok mentén! Hajrá-hajrá! Mindenesetre ezentúl triplán meggondolom, kommentelek-e bármit is a hup-ra. Inkább fejlesztem tovább a projektet, leteszek valami újat az asztalra, mert a szapulás helyett én erre is képes vagyok. Kis eséllyel lesz benne hiba. Csak az nem hibázik, aki nem dolgozik. Az új gcc warning ezt a kis esélyt legnagyobb örömömre még icipicit tovább csökkenti.)

Mondjuk Cobol-ban tényleg semmi gond egy 11k soros kóddal... Csak aztán lássa át valaki... :-D

En csak annyit mondanek, hogy valamit megertettem a szempontjaidbol, es azert egyet is ertek vele. :)

hogy mekkora egy file, az nem kerdes, hogy tokmindegy, hogy egy funkcio, reszegyseg meretet limitalni erdemes a logika, atlathatosag miatt, az viszont valoszinuleg igaz. Persze, ha tortenelmielg van egy millio soros funkcio, azt en nem mernem refactorolni ;)

Az eredeti kerdesre, hogy mi ertelme elhagyni a kapcsos zarojelet, semmi ertelmes valaszt nem adtal. Helyhiany miatt, hmmm... Nem fontos.
Erdekes, hogy sok ember(Pl. Carmack), kitudja irni. Megerti, hogy ebbol sokkal nagyobb problema lehet. Lasd, Carmack es a doom 3 coding style.
Te is bevallottad, hogy elkovettel ilyen hibat. En meg azt mondom, hogy a fejlesztoknek kene figyelni, nem ilyen Warningokat irogatni. Seged, lehet.
Mi az osszefugges, sajnos nem sikerult megerteni. nem is erekel. Az OSS fejlesztok nem igazan turik, ha valakinek mas a velemenye. Nekem ez jott le. Bocs.
Tovabbi jo fejlesztest.

> Az OSS fejlesztok nem igazan turik, ha valakinek mas a velemenye. Nekem ez jott le. Bocs.

Nekem meg pont az jött le, hogy ez rád vonatkozik, bocs. Nem véleményt nyilvánítottam, mindössze egy szempontot hoztam fel az egyik lehetséges megközelítés mellett, és Te ennek az egy szempontnak a létjogosultságát sem vagy hajlandó elismerni.

Remek, hogy hivatkozol egy coding style-ra, mintha az lenne az egyetlen abszolút igazság, és mintha sehol senki nem használna másmilyen stílust, például olyat ahol az egysoros indentálást nem kötelező kapcsos zárójelbe tenni.

Bevallottam, hogy elkövettem ilyen hibát. Igen, kábé húsz éve programozok rendszeresen, és nem tudom hogy hányszor követtem el ilyen hibát, erről az egy múltkoriról van tudomásom. Ne vonjunk már le ebből olyan messzemenő következtetést, hogy a kapcsos zárójel elhagyását megengedő kódolási stílus úgy szar ahogy van! Mindössze annyi következtetést engedj meg kérlek, hogy hasznos ez az új gcc feature.

Slightly related: "If you need more than 3 levels of indentation, you're screwed anyway, and should fix your program."

Haha, itt egy példa kapásból 5 szintre, amit max 4 szinttel lehetne megoldani, ha ay 5. szint kihiv fuggvenybe...

void factory(const std::vector &enums) {
// 1st level
for(unsigned i = 0, c = enums.size(); i < c; ++i) {
// 2nd level
switch (enums[i]) {
// 3d level
case Value1:
// 4th level
{
/// 5th level
shared_ptr tmp = new MyClass1();
}
[ ... ]
};
}

}

Nem értek hozzá, de szerintem csak kitalálta.

:)

mondjuk egy normális IDE képes a

if (someStatementTrue()) {
    doSomeOtherStuff();
}

kódot a megjelenítéskor egy sorba rendezni.

cserébe a kapcsos zárójel elhagyása olyan error-prone, hogy már attól spriccelek, hogy ránézek.

de legyen, ízlések, és pofonok...
--
blogom

Na, nekem meg egy olyan IDÉ-től lenne herótom, amelyik nem azt mutatja egy az egyben, ami a fájlba le van írva :)

> amelyik nem azt mutatja egy az egyben, ami a fájlba le van írva

akkor karaktereket sem látsz, csak 0-1-eket olvas fel a szerkesztőd? vagy azért a HEX még elmegy? :-D
--
blogom

Próbáljuk már meg nem hülyének nézni egymást, jó? :)

.

De. Csakhogy nem egyedul dolgozunk. Mi van ha nem te rontod el, hanem egy kollega?

Jo ez a warning.

Akkor őt kell péklapáttal megtanítani arra, hogy a kódolási szabvány mit tartalmaz :-P Egyébként meg erre is jó a belső code review, amikor egymás munkáját átnézitek. Már ahol csinálnak ilyesmit :-P

Igény, na, az volna rá... egyébként az ilyen ellen checkstyle véd... :D

Napi szinten csinálunk code-review-kat...

Az igazság az, hogy sokmindent benézünk, jobb az ilyet automatizálni, ha lehet.