For ciklus esetén van-e olyan eset, amikor elhagyjuk a ciklus fejlécéből a feltételt és a ciklusmagban if+breakkel állítjuk le a ciklust?

Szóval te gyakorlatilag egy while(true){if(...) break} ciklust szeretnél?

Határozottan nem szerencsés ilyet írni. Ha csak így tudsz valamit megoldani, érdemes végiggondolni, hogy korábban a kódban hol tudnád azt refaktorálni hogy ne kelljen ilyet írnod.

Ha egy for ciklusból elhagyod a feltételet akkor az nem for ciklus. Pont ez a lényege és ez különbözteti meg a kolléga által írt "while" ciklustól. A for ciklus lényege, hogy a feltételben szereplő ciklus változót minden futáskor a megadottak szerint "lépteti" és nem neked kell minden ciklusban még ezzel is foglalkozzál. Nem tudom milyen könyvből meg milyen rendszerben tanultad de ez egy nagyon alapvető fogalom, és nagyjából 50 éve biztosan így van.

És pont az ilyenek miatt van több féle ciklus szervezési módszer, hogy ezek elkerülhetőek legyenek, és mindig tiszta legyen, hogy mikor melyiket használjuk. A for ciklus nem arról szól, hogy csinálunk egy végtelen ciklust vele. Arra ott a while (legelterjedtebben). És pl. egy esemény ciklusnál van értelme (bár ott is vannak elegánsabb megoldások) mint a while(true){if(...)break...} megoldás. Eleve az a szerencsés ha egy ciklusban tudjuk mikor lépünk be és mikor ki. A break nagyon ritkán használt, illetve olyanok használják akiknek minimális fogalmuk van a programozásról. Lehet neked is kéne még párat lapozzál a tankönyvedben.

Összefoglalva: Egy normális környezetben for ciklus esetén "nem életszerű" ennek a használata. Ott valami baj van ha egy for ciklusból break-kel kell kiszállni. Nem is emlékzem olyan esetre, hogy valaha használtam volna for ciklusban break-et.

#3

az még hagyján, hogy a breakkel lép ki for ciklusból (szerintem egy do-while ciklussal sokkal elegánsabb lenne), még a külső ciklus számlálóját is a cikluson belül manipulálja.

az a baj, hogy habár technikailag ez jó megoldás, és neked akár még érthető is, ha elkezdesz valahol csapatban dolgozni, ezekért nagyon utálni fognak.

sokaknak nem esik le, de a kód olvashatósága iszonyúan fontos hosszú távon. ezért léteznek különböző íratlan szabályok, konvenciók, hogy ezt egységesítsük. nem szerencsés ezektől eltérni.

A legjobb példa amúgy erre a goto. Van egy két nagyon ritka use case, ahol nem feltétlenül rossz ötlet (érdemes utánanézni, hogy pl a linux kernelben hogy használják)

de az esetek 99.99999%ában menekülj. lehet, hogy éppen abban a pillanatban kellemes megoldás lesz egy problémára, de hosszú távon olyan spagetti kódot eredményez, hogy megéri inkább kicsit többet ülni egy probléma felett és másik megoldást találni.