Kapcsos zárójelek mint blokkhatárjelzők kikényszerítése C alatt egyetlen utasítás esetén is

Főleg a nem konzisztens indentálás miatt zavar ez téged, nem?
Ha minden mentéskor meghívnád a clang-formatot is a kedvenc coding styleoddal, akkor is zavarna?

"Tehát, a bajom az hogy én szinte mindig C nyelven programozom"

Akkor ideje lenne végre megtanulni azokat a nyelvi eszközöket is, amik szintén a nyelvhez tartoznak. Az, hogy ez téged összezavar, nem a nyelv problémája.

A fordító meg ilyet nem fog tudni, amit te szeretnél, az egy format checker, azt meg úgy paraméterezed ahogy szeretnéd

Tehát, a bajom az hogy én szinte mindig C nyelven programozom

Ha ez a bajod (megértem, miért baj), miért nem váltasz másik nyelvre? :)

BlackY

Teljesen áttekinthetetlenné tudja tenni a kódot.

Nekem annó azt tanították, hogy a goto az amivel a kód átláthatatlan lesz, nem a fenti probléma :D

Én a változó nullazast tetetnem kötelezővé. Nem az érték adást a nullazast.

Így még átláthatóbb lenne:

if(a>b) 
{
	g++;
}

XD

És akkor lehetne még azon is elmélkedni, hogy a nyitó { új sorba kerüljön-e vagy legyen az if sorában, hány karakter legyen a behúzás, tab vagy space.

Először működjön a kód, és ha már semmi másra nem tudod elb*szni az idődet, akkor ráérsz ilyesmivel szuttyogni.

( haroldking | 2020. 03. 07., szo - 21:41 )

A problémám azzal van hogy egyszerűen nem bírom megszokni, hogy egy nyelvnél a forráskód KÜLALAKJA(!!!!!), gyakorlatilag a behúzások - a szintaxis szerves részét képezik!

Előbb-utóbb eljutsz te is oda, hogy a C mellett a Rust lesz neked is a másik barátod. A C-ben meglevő nem kevés problémát újragondoltak ebben a nyelvben, és bátran bevállalták a radikális szemléletváltást.
Nem csoda, hogy a hype-listán előkelő helyen van. Mielőtt megkérdezed: jól tudok C-ben is programozni. Nemrég Rust + C közös kódot írtam, mert a rádiófrekvenciás jel decimálására a C tempója verhetetlen.

Alább a kapcsos zárójel példa Rust esetén:


$ cat teszt.rs 
fn main() {
    if 4 == 4 println!("Azonos");
}

$ rustc teszt.rs 
error: expected `{`, found `println`
 --> teszt.rs:2:15
  |
2 |     if 4 == 4 println!("Azonos");
  |     --        ^^^^^^^------------
  |     |         |
  |     |         expected `{`
  |     |         help: try placing this code inside a block: `{ println!("Azonos"); }`
  |     this `if` statement has a condition, but no block

error: aborting due to previous error

Odarakod a kapcsos zárójeleket, lefordul.
És hogy a kódnak egységes kinézete legyen, ne függjön a fejlesztő személyétől:

$ rustfmt teszt.rs

A rustfmt által javított kinézetű kód pedig ebben az esetben ilyen lesz:

fn main() {
    if 4 == 4 {
        println!("Azonos");
    }
}

Cargo használatával további tool, amely a hülyeségre figyelmeztet:

$ cargo clippy
    Checking t v0.1.0 (/tmp/hup/pelda)
error: equal expressions as operands to `==`
 --> src/main.rs:2:8
  |
2 |     if 4 == 4 {
  |        ^^^^^^
  |

Hát én ezeket az IDE-re bízom. IDEA esetén Ctrl-Shift-Alt-L és minden ilyen lófaszt megcsinál, céges esetben van config repository lehetőség, ahonnan a projektfüggő mindenfélét le lehet húzni a projekttel együtt.

A modern szoftver fejlesztésben a minőség biztosítás első lépcsője a "clean-code". Ehhez igazodva lett a pythonban nyelvi elem az indentálás, illetve mint hg2ecz bemutatta a rust -ban is hasonló a helyzet. Az C azokból az időkből származik amikor ez a bölcsesség még nem állt rendelkezésre, ezért itt a szemlélet más, a CC -t külső eszközökkel, illetve code-review -val kell kikényszeríteni.

A CC két részre bontható:

1. coding-style: ami a forrás olvashatóságát célozza, és mint ilyen nagyrészt olyan dolgokat rögzít ami ízlés kérése. Pl. hol legyen space és hol ne. C -hez készült egy talicska ilyen tool, illetve egy csomó IDE -nek van beépített sajátja. Pl. Eclipse-CDT -ben nyomsz egy "CTRL+SHIFT+F" -et és máris megtörténik a csoda.  Van 1-2 elterjedt, szabványosnak mondható stílus, pl. a Linux kernel féle, vagy a K&R, szerencsés lehet ezek egyikére rászokni. Ajánlom figyelmedbe az Universal Indent GUI -t a témakörben. Én legtöbbször az "Artistic Style" -t használom, de állítólag a clang-format jobb nála. Megemlíteném még a CheckPatch nevű toolt, ami ilyen jellegű hibák automatizált tesztelésére való.
2. Coding parctices: olyan programozási fogások gyűjteménye, melyek a tipikus programozási hibák elkerülését célozzák (hogyan csináld, illetve hongyan ne). C -ben az undefined behavior, illetve az implementation defined behavior a fő ellenség, azaz a nyelv olyan mechanizmusai amelyek működése specifikáció szerint nem definiált. Ide tartozik sok más buktató is, mint pl. az integer promotion, vagy az implicit casting finomságai, a nem inicializált változók tiltása, stb... A MISRA-C szabvány sok mindent definiál ebben a témakörben.
   Ezen témakör ellenőrzésére valók a static analyzer -ek. Bonyolult eszközök ezek, általában 1-2 talicska pénzért adják őket, bár ma már a fordítók is elég jól ellenőriznek ilyesmit. Vannak ingyenes programok, pl. a clang-tidy vagy a CppCheck, illetve 1-2 nagy játékos ingyenesen használható open-source fejlesztésben (pl. Coverity Scan).

További olvasnivaló pl. itt: https://en.wikipedia.org/wiki/Coding_conventions

Az a kisebbik baj a C szintaxisú nyelvekkel, hogy olyat megengednek, hogy

for(i=0;i<max;i++) a[i]=b[i];

Az sokkal nagyobb baj, hogy ezt is megengedik:

for(i=0;i<max;i++);
{
	a[i]=b[i];
}

Teljesen áttekinthetetlenné tudja tenni a kódot.

Az, hogy nem kell kitenned a kapcsoszárójeleket? Hogyan teszi ez áttekinthetetlenné? Nem igazán értem.

Számtalan hibalehetőség forrása

Szerintem ez addig volt igaz, amíg nem volt -Wmisleading-indentation. Vagy tudsz olyan esetet mutatni, amit gyakran el lehet rontani, és nem fogja meg ez a warning?

Ha tiszta kódot akarsz, akkor használj mbeddr-t! Nekem nem volt türelmem hozzá, de tény hogy magán az AST-n dolgozni és a részfeladatokra megfelelő DSL-eket alkalmazni / írni igazi felüdülés a spagetti kódok után. Ha persze megfizetnék, akkor szívesen dolgoznék olyan cégnek, aki alkalmazza, de nálunk általában a "csak működjön" a cél sajnos.

A programod által include-olt header fájlok jó eséllyel használják ezt a stílust makrókban, illetve inline függvények definíciójában. Tehát ha lenne ilyen opció, hasalna a fordításod, vagy pragmázni kéne agyba-főbe hogy a te hatáskörödön kívüli include fájlokra kapcsold ki ezt az ellenőrzést.

Ez már megint... mintha a kódokban ez lenne a legnagyobb probléma.

Millió dolgot lehetne csinálni a C-vel, de NEM ezek a problémái. Az integer meg a float osztás összekeverése sokkal szemetebb dolog pl.

Ettől még ez a szabvány. Ha nem tetszik, használj kód formattert, ha nincs, akkor írj egyet. Nyitó {-t pedig csak függvényekkel szokás külön sorba tenni, legalábbis ott, ahonnan én jövök. De a whitespace-nek épp az a lényege, hogy ne vesszünk rajta össze.

És ne is warningoljon, hanem ha nincs ott, akkor simán ERROR és kész.

Ajánlom a gcc -Werror flag-ét.

https://clang.llvm.org/extra/clang-tidy/checks/readability-braces-aroun…

Hatrany: clang-tidy kell, szoval nem a fordito oldja meg neked. Persze git pre-commit hook-kal kombinalva mar okes a helyzet. Ha a junior nem csinalja jol a dolgot, akkor visszadobja a git commit-ot.

Elony: szerintem a clang-tidy ki is tudja javitani a kodformazasi bakikat.

Alapjaban veve ertem a haborgast a temaban. En erre a konkret dologra nem vagyok erzekeny, dehat mindenki masra ugrik. Csak szerintem nem feltetlenul a fordito a forraskod-kinezet-naculas legjobb eszkoze.

működik így is, úgy is... hol a bibi?

Most lusta vagyok vegigolvasni es kiprobalni is, de ket opcio:

-Wno-misleading-indentation

-Werror

Elobbi a szar behuzasnal warningol, asszem ebbe beletartozik az is, ha ezt irod:

if(a<b)
  g++; h++;

masik meg minden warningot errorkent kezel. Ezzel nem fogod kikenyszeriteni a {} hasznalatat, de ha valahol ennek ellenere benezed, azt eszreveszed.