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

Szerszám

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ó.

( crown v | 2016. 03. 02., sze – 14:26 )

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.

( arpi_esp v | 2016. 03. 02., sze – 15:05 )

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

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.

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.

( egmont | 2016. 03. 02., sze – 20:12 )

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.

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.

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.

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.)

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.

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();
}
[ ... ]
};
}

}