Új figyelmeztetés a GCC6-ban: -Wmisleading-indentation

 ( trey | 2016. január 12., kedd - 10:16 )

Mark J. Wielaard a napokban arról blogolt, hogy a kiadás előtt álló GCC6 egyik új, számára hasznos funkciója a -Wmisleading-indentation figyelmeztetés lesz (csak C és C++).

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 is right for you.

Mondjuk sokkal egyszerűbb, ha az ember soha nem spórolja le azt a két darab kapcsos zárójelet... Eleve kár volt anno megengedni ezt a szintaxist.

+1
Lehetne akár már a hiányzó {} jelekre figyelmeztetni.

Teljesen egyetértek. Bár a létezéséről tudok, soha életemben nem használtam ezt az írásmódot.
---
Science for fun...

Én gyakran használom, ebből látom, hogy valami egyparancsoscucc van az IF-ben. Persze a behúzásra figyelek, autoformatter is rendben rakja az ident-eket. Mondjuk, ha a blokk kétparancsosra vált (pl: egy log.debug() kell bele), akkor ki kell tennem a {}-t.

Furcsállom, hogy preprocessor-ok környékén nem működik, pont ott lehet elnézni, ha a process-ált kódban áll elő valami furcsa.

Apropos: ha már valamit rühellek, akkor az a blokk-"vezérlő" (if, while) illetve a függvénynévvel EGY SORBA írt kezdő kapcsos-zárójel. Attól szem-tikkesedést kapok... szvsz.


function Valami(int a) {
...
}

Szerintem ez a Borland C++-os időkből maradt ránk, amikor max. 20-22 sor fért ki a képernyőre.
Ma már nyilván semmi értemle, az egymás alatti kapcsoszárójelek sokkal szebbek, számomra könnyebben követhet, ki kivel van.

Fuszenecker Róbert

P.S. tetszik a júzerneved :-)

> Ma már nyilván semmi értemle, egymás alatti kapcsoszárójelek sokkal szebbek
szerintem meg nem. no, akkor ki nyert?

(semmi bajom azzal, sőt, semmi közöm hozzá, hogy a saját kódodat, a saját környezetedben lévő emberekkel hogyan formázod, de a „semmi értelme” kijelentés erős.)
--
blogom

Ha a '}' a '{'-lel áll párban, akkor miért ne legyen mindkettő ugyanúgy indentálva?
Mennyivel jobb az, ha a '}'-re viszem a kurzort, és azt kell keresnem, hogy hol a nyitó zárójel ahelyett, hogy csak felfelé kell vinnem a tekintetemet?

Így értettem az "értelmetlen"-t.

Fuszenecker Róbert

kiemeli az IDE, nem akarom én egy oszlopban keresni.
ezek a dolgok messzemenően ízlés dolga, szerintem, s abból meg egyikre sem illik azt mondani, hogy rossz. mert a te ízlésed semmivel nem rosszabb, mint az enyém. csak más.

de én meg jöhetek azzal, hogy a képernyő alsó felét elviszi a debugger - s akkor ugyanott vagyunk, hogy a hely kevés, húzzuk össze. no?
--
blogom

Méóiért takarná ki a debugger? Nem a 80-as években élünk :-)

Fuszenecker Róbert

Mert hala isten a nagy monitoron igy tobb adat elfer, a dual monitor meg a gyakorlatban kenyelmetlenebb, mint nem. :)

---
pontscho / fresh!mindworkz

Korábban én is mindig új sorba raktam a nyitó karaktert, most viszont már az lenne a furcsa, ha nem egy sorba kerülne. Viszonylag gyorsan át lehet állni egyik stílusról a másikra (olyan 1-2 hónapot tippelnék).

Egyébként onnan is megközelíthető a kérdés, hogy a szép kód rövid, ideálisan egy kódblokk 1-2 utasítás*. Ekkor túlságosan szellőssé tenné a kódot, ha a kapcsos zárójelek mindig önálló sort kapnának.

*: Mielőtt ebbe valaki beleköt, javaslom ezen az oldalon a Session 4, 5, 6 bekezdést.

" ideálisan egy kódblokk 1-2 utasítás"
Ez így nem teljesen igaz. 1 kódblokkban azonos absztrakciós szintű utasításokat hajtunk végre. Ha az adott absztrakciós szinten ott egymás után bizony több dolgot is végez a szoftver (például egy 5 lépéses folyamatot), akkor bizony az több utasítás lesz.
Ami szabályt be kell tartani: egy utasításblokkban csak azonos absztrakciós szintet használunk, lásd composed method pattern.
És így bizony sok esetben csak 1-2 utasításod lesz, de lehet, hogy több, attól függ, mit kell csinálnia a kódnak.

A szépség relatív, a követhetőségen pedig inkább a helyes és egységes indentálás segít. Azért egy nyitó kapcsos zárójelre elpazarolni egy sort elég fura nekem. A záró kapcsos zárójel az más.

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

Szerintem meg nem véletlenül hívják K&R style-nak, a '78-as első kiadásban már úgy szerepel. Ami jóval a Borland előtt volt ugyebár. De persze nyilván a kevés képernyőre kiférő sor az oka.

hát nem... nem kell a C-ből sem lispet sem pythont csinálni. Aki nem akar C-ben kódolni az ne abban kódoljon. A C az C.

--
GPLv3-as hozzászólás.

goto fail;

Nekem is ez volt az elso gondolatom

http://astyle.sourceforge.net/astyle.html#_Bracket_Style_Options

A legkényelmesebb talán az volna, ha a tooljaimnak beállíthatnám, hogy mi legyen a nálam megjelenő stílus és hogyan commitolja be. Jelenleg ehelyett alkalmazkodom a környező kódokhoz.

"A legkényelmesebb talán az volna, ha a tooljaimnak beállíthatnám, hogy mi legyen a nálam megjelenő stílus és hogyan commitolja be."
Igazából ehhez az kéne, hogy lenne minden free-form (azaz whitespace-t lenyelő) nyelvhez (nyelvenként) egységes formátuma az AST-nek, amit aztán úgy renderel ki az IDE, ahogy neked tetszik.

De ehhez azt az absztrakciós szintet kell elérni, hogy te nem egy szövegfájlt szerkesztesz valójában, hanem egy programkódot.
A programkód meg eleve egy formális nyelvtan szerinti strukturált adat, az egy dolog, hogy karakterekből áll.

És amikor kommitolsz, akkor igazából te AST-változtatást kommitolsz be, és nem azt, hogy 'na nézd, az ötödik sorban átírtam a hatodiktól a tizedik karaktert'. Mert ez utóbbi semmitmondó önmagában. Az, hogy átneveztem a foo függvény bar függvényre, annak a nyelv szintjén van jelentése.

Dolgoztam teljesen AST alapu DSL-eket tamogato eszkozzel (mbeddr). Egy ido utan nagyon idegesito tud lenni a kod szerkesztese. Aki "csapong" a kod irasa kozben (mint en) annak elegge megneheziti a dolgat. Persze ha van mar egy jol kidolgozott modelled, amit csak implementalni kell, akkor mar mas teszta.

Én sokkal fapadosabban képzeltem el. Egyszerűen az IDE a fájl beolvasásakor átalakítja a kedvencemre és íráskor át az egyezményes formába. Ez utóbbi azért kell, hogy a verziókövető ne lásson olyan változtatásokat, amiket nem is csináltam. Mondjuk az IDE meg is jegyezhetné, hogy melyik sorokhoz nem nyúltam.

Igazából én nem szeretem a kapcsoszárójelezést. Úgyhogy az IDE ezt is figyelembe vehetné. Az indentálásokat magától kapcsoszárójelezhetné íráskor. Vagy ha éppen Scratch őrület tör ki rajtam, akkor úgy szerkeszthessem. Ez persze már valóban az AST irányába mutat.

Fene ebbe a GCC-be, dobalja itt a warningokat a szep kodokra:
https://github.com/ncw/ioccc2012/blob/master/prog.c