Jump to content
GSForum - Segélyvonal

continue és break


kléni

Recommended Posts

kléni

Az informatika tanárom azt mondta, ne használjam egyiket se. Rákérdeztem, mi a baj ennyire velük. Adott két linket:

https://infoc.eet.bme.hu/ea05.php

http://prog.hu/cikkek/293/Elagazasok+kilepesek.html

 

A 2013 októberi érettségi feladatait kellett megcsinálnom. Én ilyen kódot írtam:

Console.WriteLine("A keresett rendszám:");
string rszam = Console.ReadLine();
Console.WriteLine("Találatok:");
for (int i = 0; i < ell.Count; i++)
{
   bool c = true;
   for (int j = 0; j < rszam.Length; j++)
   {
       if (rszam[j] == '*')
           continue;
       if (ell[i].rendsz[j] != rszam[j])
           c = false;
   }
   if (c)
       Console.WriteLine(ell[i].rendsz);
}

Ezt persze fel tudtam volna írni continue nélkül is. Lehetne jobb a kódom. Ő viszont így oldaná meg:

static bool egyforma(string latott, string igazi)
{
   for (int i = 0; i < latott.Length; i++)
   {
       if (latott[i] != '*' && latott[i] != igazi[i])
           return false;
   }
   return true;
}
static void Main(string[] args)
{
   Console.WriteLine("A keresett rendszám:");
   string rszam = Console.ReadLine();
   Console.WriteLine("Találatok:");
   foreach (ellenorzes i in ell)
   {
       if (egyforma(rszam, i.rendsz))
           Console.WriteLine(i.rendsz);
   }
}

Az biztos, hogy nem fogok sose függvényt használni a cointinue / break helyett, főleg ilyen helyzetben nem, de mit mondtok ti? Tényleg én vagyok az egyedüli, aki azt mondja, az én megoldásom sokkal átláthatóbb, rövidebb, egyszerűbb, mint a tanáré?

Link to comment
Share on other sites

Fujitsu

A continue és a break utasításokkal az a bibi, hogy nem strukturált elemek. Gyakorlati szempontból nem hiszem, hogy egyszerűbb programoknál ennek bármi jelentősége lenne.

 

Ha nem akarod átszervezni a ciklusodat, a Fujitsu-féle parasztmódszer különféle flagek hadrendbe állítása, amiket eseménytől függően billentesz vagy nem billentesz, aztán a ciklusban maradás feltételénél vizsgálod, hogy mi a stájsz. De ha más nem indokolja, feleslegesen nem bonyolítanám a kódom ilyesmivel, avagy én is continue-párti vagyok. :)

Link to comment
Share on other sites

KGigi

<p>Alapvetően a continue, a break és a go to használata erősen ellenjavallott, mert ahogy Fujitsu is írta, nem strukturált elemek. Ugyanígy elvileg nem "szabadna" használni függvényben a return utasítást ciklusból való kilépésre. Néhányan ezekre egyenesen allergiásak. Ritkán jól jönnek, és egyszerűsítik a megoldást, az esetek nagy részében viszont rosszul szervezett kódra utalnak.

  • go to: nem tudok elképzelni olyan esetet, amikor ezt használnám. Még ha hatékonyabb kódot eredményezhet is egyes esetekben, teljesen átláthatatlanná teszi azt. Ez alól az egyetlen kivétel a C# switch szerkezete állapotgépként használva, az egyszerűen zseniális.
  • continue: az esetek nagy részében nagyon egyszerűen kiváltható plusz feltételek bevonásával, ugyanakkor a használata egy sor problémát okozhat. Például valaki később átszervezi a for ciklusodat while ciklussá, és nem érti, hogy miért nem növekszik a futóváltozó egyes iterációk végén. Ez nyilván nem ilyen 10 soros esetekben jön elő. :) A lényeg, hogy csak akkor használd, ha nagyon átlátod a kód működését, és akkor is elsősorban hatékonyságnövelésre. Normál esetben ha ilyenekre van szükséged, akkor rosszul szervezted a ciklust. Például egyszerűen azt mondhattad volna, hogy if (rszam[j] != '*' && rszam[j] != ell.rendsz[j]). Ne mondd nekem, hogy ez nem jobban átlátható.
  • break és return: ebben az esetben mindegy, a lényeg a nem strukturált kilépés egy ciklusból. A három variáció közül messze ez a legelfogadhatóbb, nyilvánvaló hatékonysági és olvashatósági előnyei vannak. A legtöbb esetben viszont kiváltható egy extra logikai változóval a ciklusfeltételben. És ez a legtöbb nyelvben még csak azt sem jelenti, hogy fel kell áldoznod a for ciklust. Simán írhatsz olyat, hogy for (int i=0; i < n && !end; ++i). Szerintem az is elég jellemző, hogy ha valahol break-et használnál, akkor már érdemes a műveletet kiszervezni ciklusba, és break helyett visszatérni a függvényből. Sokkal tisztább. Ha már break, akkor érdemes tudni, hogy sok nyelvben címkézni is lehet, ezzel jelölve, hogy a belső, vagy valamelyik külső ciklusból szeretnénk kiugrani.

Link to comment
Share on other sites

kléni

A goto-t én se használtam sose, de a continue/break-ot rendszeresen látom máshol is, és még sose okozott problémát a használatuk. Az OOP-vel is így vagyok. Meg tudom oldani rendesen OOP nélkül is a dolgokat, és csak bonyolításnak tartom azt. A jquery pl. 21 break-ot tartalmaz, mégsem azok okozzák az átláthatatlanságot, hanem az, hogy 8 ezer soros a kód, van benne x^6 funkció, és mire megérti valaki az egész felépítését, eltelik egy év. Ha én meg tudom érteni, hogy mit csinál a break, minek rakjam a for elejébe a !end feltételt? Sőt, miért van benne ősidők óta minden programnyelvben, ha ennyire kerülendő a használata? Tényleg sok helyen látom a gyakorlatban, és nem tudom elfogadni, hogy a tanár a másik módszert etesse meg velem. A C# "előnyeit" is korlátozottan használom. (bár abban igaza van, a where, orgerby meg first függvényeket gyorsabban meg lehet írni az érettségin, na de ne azért tanuljak már meg egy nyelvet, mert azzal gyorsan tudok leérettségizni.)

 

Judit: Ez az egész úgy néz ki, mint a windows vs linux vita. Mindkettő jobb lehet valakinek, másnak pedig hátrányt okozhat. :D

Link to comment
Share on other sites

Fujitsu

A goto-t kicsit különvenném ezektől. Egyrészt ha goto-t használsz, azzal brutálisan áttekinthetetlenné tudod varázsolni a kódod pillanatok alatt, míg azért break vagy continue esetében erről általában nincs szó, hiszen az adott ciklusra vonatkoznak, goto-val meg bárhová elugorhatsz. És innen jön a goto "főellenség" titulusa is, mivel ezzel az ugrálgatással szerintem simán szét tudod kefélni a stacket. Persze a mai fordítók már valószínűleg lekezelik ezt, de akkor sem egy biztonságos megoldás. Hogy az egyik mesteremet idézzem: "aki olyat leír, hogy goto, az egy apagyilkos". :)

 

A break meg a continue ehhez képest ártatlan bárányok, hiszen azokkal nem tudsz kiugrani csak úgy egy szubrutinból. Jó, hát nem elegáns egyik se, de pl. a break egy switch–case szerkezetnél eléggé indokolt lehet. ;) A continue valóban teljesen kiváltható, de szerintem azért nem tragédia, ha valaki használja. Én is szoktam.

 

Ugyanígy a return is teljesen veszélytelen, most hogy nem elegáns a függvénytörzs közepén... Több is veszett Mohácsnál. :)

Link to comment
Share on other sites

payskin

Én is a klasszikus strukturális programozás alapjain nevelkedtem, ahol nincs goto, és a szubrutin pedig egy ponton kezdődik, és egy másikon ér véget. Amikor először láttam breaket meg continue-t ciklusból való kiugrásra, biztos el is sírtam magam, aztán rájöttem, hogy if/else-hegyeket lehet velük megspórolni.

 

Azt gondolom, egy icipicit túllépett már a világ a klasszikus strukturális programozáson. Ha például felütjük Robert C Martin programozókörökben Bibliaként tisztelt Clean Code című könyvét, látni fogjuk, hogy Bob bácsi szerint sokkal fontosabb, hogy ne írjunk iszonyú, többszörösen összetett if-hegyeket, és hogy egy function maximum 2 rétegű legyen (indentek szempontjából), de a legjobb, ha 1. Na, ebben azért nagy segítség lehet a continue meg a break. (Most nézem, hogy a tanár úr megoldása is bizony ezt az alapelvet követi, amikor kiszervezi az összehasonlítást egy külön függvénybe, és a konkrét példában tényleg viszonylag egyszerűen elkerülhető a continue használata, úgyhogy muszáj igazat adnom neki. ;))

 

Sőt van egy talán die early nevű alapelv, hogy adatok ellenőrzésénél nem újabb és újabb if-else rétegeket építenünk, hanem rögtön a rosszra vizsgálunk, és ha gond van, akkor die/return/throw exception, ami szükséges. Így minden, ami ezután jön az az else ág volna, csak épp nem kell else ágba tenni. A strukturális programozás kitalálói valószínűleg rituális öngyilkosságot követnének el, ha ezt meglátnák, pedig sokkal tisztább, olvashatóbb kódot eredményez.

 

Goto-ra nincs mentség. Azt soha.

 

Az OOP-vel is így vagyok. Meg tudom oldani rendesen OOP nélkül is a dolgokat, és csak bonyolításnak tartom azt.

 

Ó, ifjú padawan, elején vagy még az utadnak. :) Egyébként azért nem érted az OOP lényegét, mert az OOP-ről szóló oktatás (könyvek) 90%-a szerint az OOP az, hogy csinálunk egy AUTÓ class-t, legyen két tulajdonsága, a gyártó meg a szín, meg egy metódusa, hogy milyen hangot ad. Csináljunk belőle két külön objektumot, egy kék Mercédeszt meg egy fehér BMW-t, a Mercédesz azt mondja: brumm, a BMW meg azt, hogy brümm (hm, lehet, hogy nem a legjobb példa volt :P), és ez volt az OOP. Haladó esetben, csinálunk egy JÁRMŰVEK classt, és abból AUTÓT származtatjuk, na, ez az öröklődés, ez volt az OOP. Hát ahogy azt a Móricka elképzeli. Az OOP majd ott "üt be", hogy hordozható kód, meg design patternek... Majd akkor érteni fogod, mi a jó benne.

 

Ja, még egy okosság eszembe jutott: amíg iskolába jársz, úgy kell programozni, ahogy a tanár elvárja. Például 2. vagy 3. féléves voltam már, amikor a Pascal (!) gyakorlati tanár, mindenkit kiosztott, hogy hogy merjük a begint sor végére írni. A begin az valaminek az eleje, annak bizony a sor elején kell állnia. Vért izzadtam, amíg átszoktam, de többek között ennek következménye mind a mai napig, hogy az összes kapcsos zárójeles szerkezetet így írom:

 

if (....)
{
   ...
}

 

Noha a világ 90%-a így írja:

if (...) {
   ...
}

 

:hááát:

 

 

Még valami:

 

for (int i = 0; i < ell.Count; i++)
{
       bool c = true;
       for (int j = 0; j < rszam.Length; j++)
       {
               if (rszam[j] == '*')
                       continue;
               if (ell[i].rendsz[j] != rszam[j])
                       c = false;
       }
       if (c)
               Console.WriteLine(ell[i].rendsz);
}

 

kléni, abba gondolj bele, hogy ha a rendszám, tegyük fel, 1848483 karakteres, nincs benne * és már az első karaktere sem egyezik a másikkal, a te megoldásod akkor is végignézi mind a 1848483 karaktert, a tanárod-é kiszáll az elsőnél. Innentől nem igazán van miről beszélni. ;) Tudom, nehéz elfogadni, de néha igaza van a tanárnak. :igen: Amikor olvastam a Bob bácsi könyvet, kb. minden második oldalon azt gondoltam, hogy "ez mekkora hülyeség már!", aztán kicsit gondolkodtam, és rájöttem, hogy lehet, hogy mégis igaza van...

Link to comment
Share on other sites

Fujitsu

Tényleg, végül is a throw is ilyen strukturálatlan elem. :)

 

A tanár megoldásában általában az a legjobb, amikor jó sok gondolkodás után kiötlesz egy 10 soros megoldást a problémára, és büszke vagy magadra, hogy azt csinálja, amit kell, és ahhoz képest milyen elegáns. :P Aztán meglátod a tanár megoldását, ami 3 sor. Első reakció: "ez hülye, ez nem is azt csinálja, amit kell", aztán lefuttatod, és rájössz, hogy sajnos az övé is pont azt csinálja... :lol:

 

Hogy hol legyen a függvénytörzs/ciklustörzs nyitó zárójele, az egy örök hitvita a programozók között. Még nekem is úgy tanították, hogy egy sorba írva a függvényfejjel/ciklusfejjel kevesebb helyet foglal, hiszen -1 sor. Ez igaz, cserébe szerintem nehezebb átlátni a kódot, úgyhogy én ezzel a +1 sorral sohasem spórolok. Na meg bizonyos kódszerkesztőkben így anélkül lehet egy kattintással elrejteni a függvénytörzset, hogy a függvényfej, illetve a ciklusfej is eltűnne.

Link to comment
Share on other sites

KGigi
A jquery pl. 21 break-ot tartalmaz, mégsem azok okozzák az átláthatatlanságot, hanem az, hogy 8 ezer soros a kód, van benne x^6 funkció, és mire megérti valaki az egész felépítését, eltelik egy év.

8 ezer sorban 21 break arányaiban pont jó is. Van egy olyan érzésem, hogy te ennél lényegesen sűrűbben használod.

 

OOP. Képzeld el az egész dolgot úgy, hogy nem metódusokat írsz, hanem ha az osztályod T, akkor f(T this, ...) szignatúrájú függvényeket. Így a származtatott osztályok metódusait el tudod képzelni függvénytúlterhelésként. A túlterhelés előnyeit gondolom ismered, például megírsz egy függvényt char-ra és string-re, vagy int-re és double-re.

 

Képzeld el ugyanezt nagyban. Tegyük fel, hogy ki akarsz rajzolni egy csomó dolgot a képernyőre. Ahelyett, hogy túlterhelsz egy függvényt annyiféleképpen, ahány típusú objektumod van, vagy rosszabb esetben nekiállsz if-ben vizsgálni a típusokat (ilyet soha!), létrehozol egy Drawable ősosztályt vagy interfészt, amelynek csinálsz egy draw metódust. Ebből az osztályból leszármaztatod a rajzolható objektumokat, és felüldefiniálod a draw metódust. Minden osztályban egy ilyen lesz, egyértelmű funkcióval, tökéletesen áttekinthető a kódod. Kirajzoláskor pedig nincs más dolgod, mint egy ciklussal végigmenni a kirajzolandó objektumaidon, és azt mondani, hogy akarmi.draw().

 

Menjünk tovább, tegyük fel, hogy nem egy beadandót írsz, hanem értelmes éles programon dolgozol. Ha minden egy helyen, vagy esetleg egy osztályban lenne (antipattern), az nagyon nehézzé, ha nem lehetetlenné tenné a közös munkát, a feladatok felosztását, illetve a program tesztelését. Ha az ilyen műveleteket kiszervezed osztályokba, azzal egyrészt lehetővé teszed, hogy minden objektumra az a programozó írja meg a kirajzolást, aki egyébként a komponenst fejlesztette, másrészt neked is csak annyit kell tudnod, hogy ezek kirajzolható objektumok. Nem kell tudnod, hogy pontosan milyenek, még csak azt sem, hogy hány és milyen fajta lehet. Ha egyszer később hozzá kell adni egy új kirajzolható objektumot, akkor nem kell millió helyen belenyúlni a kódba (rajzolás, mentés, visszatöltés mind különböző helyen), hanem elég csak hozzáadni egy darab új osztályt. Tessék elfelejteni azt a baromságot, amit Balázs is leírt. Az osztály nem egy struct sok függvénnyel, hanem egy szolgáltatásokat nyújtó entitás, amelynek az egyik legfontosabb tulajdonsága, hogy nem kell/szabad ismerned a működését, csak a szolgáltatásait leíró felületét.

Link to comment
Share on other sites

payskin

Jó, de ez meg kicsit túl mély "merítés", mert ebből jó, ha minden második szót érti. :D 20+ év fejlesztéssel a hátam mögött most találkoztam először a függvénytúlterhelés kifejezéssel, de azért sejtem, hogy mire gondolsz. :upsz:

 

Az "if-ben vizsgálni a típusokat", pillanatok alatt vezethet a switch szerkezethez, amit Robert bácsi kategorikusan elutasít a Clean Code-ban, mint tűzzel vassal irtandó antipatternt. Egy esetben tud elképzelni switchet, amikor egy factory gyárt különböző objektumokat egy közös interfész alapján készült osztályokból. Azért ezek kemény dolgok, nagyon kell kapaszkodnom, mikor olvasom, és persze vitatkozom is vele. A boltkód tele van switchcsel, viszont elkezdtem "látni", hogy hol kéne Róbert bácsi elveit alkalmazni helyette. Persze lefejleszteni nem tudnám, az egész boltban nincs egyetlen factory vagy interfész. :hááát:

 

Ha valaki fiatalon így tanul meg programozni -- mint valószínűleg te, KGigi --, neked ez nyilván teljesen természetes. Piszokul irigyellek érte. :D

Link to comment
Share on other sites

KGigi

Engem egyetem előtt senki nem tanított programozni. Vettem egy Programozzunk C++ nyelven című könyvet, ami igazából olyanoknak íródott, akik C-ről állnak át. Elkezdtem olvasni, néha napokat töltve pár oldal felett, és egy idő után elkezdtem érteni. Közben persze próbálgattam a gépen, és iszonyatosan örültem, amikor magamtól sikerült írni egy for ciklust, ami kiírja az első tíz számot a képernyőre. Bevallom őszintén, hogy a mutatók és az osztályok bizony már megfeküdték a gyomromat. De a túlterhelést innen ismerem. :)

 

Egyetemen első félévben elvileg tanítottak programozni, ez a gyakorlatban úgy nézett ki, hogy a tanárnak fogalma nem volt a C++-ról, sokszor az óra fele azzal ment el, hogy a tapasztaltabbak a kódját javítgatták. Aztán eljött az évfolyam-zh ideje, és megtudtuk, hogy míg nekünk a legkomolyabb programunk egy while ciklust tartalmazott, addig zh-n fájlból beolvasós + számolós + fájlba írós feladat lesz. A tanár megígérte, hogy utolsó gyakorlatra hoz egy példaprogramot, amiből aztán majd gyorsan megértjük, semmi gond nem lesz. Ebből az lett, hogy a kód nem hogy nem működött, de nem is fordult. Néhány nap volt hátra a zh-ig, jobb híján beírtam a Google-be, hogy C++ fájlkezelés, elkezdtem példakódokat csinálni, majd gond nélkül 5-ös zh-t írtam. Magával a kódolással/algoritmizálással szerencsére addigra nem volt gondom, mert ezzel párhuzamosan volt Linuxunk, ahol a végén már szkriptelgettünk. A tanár ott sem volt egy ász, a csoport nagy része megbukott, de ha nagyon akartad, megértetted. Én meg nagyon akartam.

 

Második félévtől kezdve már szabadon választhattunk tanárt, addigra a baráti társaságom is bejáratódott, áramlott az információ, így egyrészt tudtam, hogy kinél kell órát felvenni, másrészt nem kellett már egyedül agyalni. Negatív oldalon bejött a programozáselmélet matematikai modellje úgy, hogy igazából még lövésünk sem volt, hogy a programozás az úgy egyébként micsoda azon kívül, hogy pár tíz soros, szkriptnek is béna konzolos programokat gányolunk össze horribilis idő alatt. Aztán szerencsére jöttek az értelmes dolgok: algoritmusok, programozási nyelvek C++, adatbázisok, szoftvertechnológia. Az eseményvezérelt alkalmazások sajnos egy vicc volt, a grafikus programokat gyakorlatilag magunktól tanultuk meg a már leírt módszerrel. Webprogramozást specinek vettem fel. OOP-n zsák osztályt meg komplex számot csináltunk, a szoftvertechnológiáig körülbelül úgy voltam az egésszel, mint te. Mesterszakon jöttek be a gyártók, interfészek, tervminták, és ehhez hasonló szép és tényleg hasznos dolgok. Ott már tényleg tanítottak, és tervezni, nem gányolni. Mondjuk a tárgyak harmadában-felében. A maradék része khm.

 

Szóval igen, valamennyire tanították, de alapvetően ez egy egyemberes dolog. Ha akarod, és rászánod az időt, illetve megvan hozzá az érzéked, akkor elsajátítod. Megtanítani az életben nem fogják, különösen az ELTÉ-n nem. :P A clean coding egyébként egy nagyon hasznos olvasvány, a cégnél, ahol dolgozom, éppen most állunk át rá.

Link to comment
Share on other sites

Fujitsu
20+ év fejlesztéssel a hátam mögött most találkoztam először a függvénytúlterhelés kifejezéssel, de azért sejtem, hogy mire gondolsz.

 

Én is, mivel ilyesmi nem létezik. :)Függvénynév-túlterhelés, olyan igen. :P De akkor, ha jól sejtem, még nem nagyon fordítottál C++ programot, mert ez kb. a második C++ óra anyaga egy egyetemen, plusz a fordító is orrba-szájba nyomja az ilyen-olyan overload kifejezéseket. :)

 

Én a switch–case ideális felhasználását egy állapotgépnél simán el tudom képzelni. Én is ezzel írtam meg a sajátom, amikor anno ez volt a feladat.

 

Nekem a programozás korábban évekig csak fogalmatlan kódsor-kopipésztet jelentett különféle tutorialokból, amik jó esetben azt csinálták, amit szerettem volna, és ideális esetben értettem is, hogy mi miért van. De a dolog hátteréről nem sok fogalmam volt, és ha bármi összetettebbet kellett volna írnom, amire nincs előttem egy sablon, meg lettem volna lőve. Biztos meg lehet tanulni autodidakta módon is programozni, de sokkal nehezebb.

 

Ehelyett nálunk onnan indult a dolog (középiskolában), hogy két évig tanultunk digitális technikát, mire eljutottunk oda, hogy huzalozott számítógép meg sínes számítógép, és mindegyiknek megtanultuk leírni a működését APL-lel (Iverson-nyelv, szimbolikus leírás). Persze hogy megtanultuk, az kis túlzás, inkább kapiskáltuk a lényegét, mert az APL mint olyan nem embernek való. (Ez az Iverson egy zseni volt, aztán hogy ezzel együtt jártak olyan mellékhatások is, mint hogy esetleg nem húzta le a sliccét hugyozás előtt, az már más kérdés.) Aztán ötödéven jött a Z80-architektúra, Z80 assembly, perifériák (ITC, PPI, USART, DMA stb.), kezdetben még olyan is volt, hogy papíron fordítottuk az assembly-listát gépi kódra. (Egyetemen is hasonló van, csak kicsit mélyebben, és persze itt 8085 van Z80 helyett.)

 

Na, ezek után jött az egy másik tárgyból, hogy tanuljunk C-ül. Egész más úgy, hogy van elképzelésed arról, mi a szart csinál a processzor a kódoddal, mi íródik a stackbe, valójában hogyan történik egy szubrutinhívás stb. Amíg ezeket nem látod (mondjuk egy, az assembly-listádat soronként végrehajtó szimulátorban), és valaki elmondja, hogy hát ez valahogy így van, addig csak bólogatsz, de nem lesz teljesen korrekt elképzelésed arról, hogy mi történik. Persze ha valaki nem a hardver irányából közelít, annak talán ez nem is annyira fontos. Mondjuk épp ezért érdekes, hogy mifelénk az egyetemen előbb van a Programozás alapjai 1., mint a Digitális technika 2., ahol assemblyzés folyik, de ez engem annyira nem izgatott már, mert volt fogalmam az alapokról, mire odakerültem. :)

 

Hozzá kell tennem azt is, hogy nekem programozással kapcsolatban infótanár soha nem tanított semmit, igazából még informatikus se. Ilyesmire csak doktori végzettségű mérnökök oktattak. :)

Link to comment
Share on other sites

Dani991

KGigi: Tisztára ledöbbentem azon, amit írtál az ELTE-ről. Igaz, van köztünk némi korkülönbség -- én még csak az alapképzés 3. félévénél járok. Tény, hogy hallottam innen-onnan rossz gyakorlatvezetőkről, de személyesen sosem találkoztam eggyel sem, még az első félévben sem. Akik eddig tanítottak az ELTE-n, mindenkivel maximálisan meg vagyok elégedve, meg úgy az egész egyetemmel is. Azelőtt én is autodidakta módon tanulgattam programozni, és úgy mentem egyetemre, hogy éppen csak kapiskáltam az OOP lényegét, de nem sok mindent tudtam kezdeni vele. Mára már sokkal világosabb az egész, előadásokon kiválóan elmagyaráztak sok mindent.

 

Nálunk már most, így a harmadik félévben volt/van szó interfészekről és tervmintákról (igaz, még nem mentünk bele túl mélyen). Az eddigi tapasztalataim alapján a következő félévben rendesen is átvesszük ezeket a dolgokat.

Link to comment
Share on other sites

KGigi

Járhattam volna sokkal rosszabbul is. Még mindig nem rúgták például ki az L.I. monogramú tanárnőt, akinek elképzelése sincsen a programozásról, de legalább elképesztő magabiztossággal képes oltári nagy marhaságokat beszélni. Ezt leszámítva volt egy nagytakarítás, amióta végeztem, a gyakorlati része például nagyon sokat javult, amióta Roberto átvette. Nálunk ő még csak pár gyakorlatot tartott. Fülöp felolvasóestjei megvannak még? :lol: Én őt is megúsztam, de volt helyette két félév Járai Maple-lel és kommunistákkal. Mondjuk még mindig jobb, mint Pál Jenő Fidesz-kampánya analízis 3 előadáson.

 

Nálunk is előkerültek, főleg szoftvertechnológián, de csak érintőlegesen. MSc-n viszont volt egy egész tárgy a tervmintákról, az például az egyik leghasznosabb kurzus volt az öt év alatt.

 

@Fujitsu

Minden ilyen írás újra és újra meggyőz arról, hogy nagyon jól döntöttem, hogy nem mérnök infora mentem tovább. :D

Link to comment
Share on other sites

Fujitsu

Csakhogy én egy büdös szót nem írtam ám a mérnökinfóról. :lol: Mondjuk ott is van digit2, de az kicsit más világ. :)

Link to comment
Share on other sites

Dani991

Az L.I. monogramú tanárnőről hallottam már, de eddig sikerült elkerülnöm. Előző félévben az egyik gyakorlatvezető kiküldött egy kurzusmailt (az összes gyakorlati csoport hallgatóinak), hogy jelentkezzünk át másik csoportba, mert "szervezési feszültséget okoz a csoportok aránytalan létszáma, egy csoportban maximum 20 fő lehetne". Egy olyan csoport volt, amelyikbe 8-an jelentkeztek, a többibe 25-en. :lol:

A Fülöp-féle felolvasóestet viszont nem sikerült elkerülnöm. Na, az volt eddig a legrosszabb az egyetemen, ami történt velem. De szerencsére átmentem nála, mert a gyakorlatvezető piszok jól elmagyarázott mindent.

Link to comment
Share on other sites

KGigi

A programozás módszertan csoportok néztek ki úgy, hogy Fóthihoz háromszoros túljelentkezés, GT-hez elég erős túljelentkezés, LI-hez pedig 2-3 kósza ember, aki valószínűleg kimaradt az információáramlásból. Ott is szóltak, hogy ez így nem lesz jó. Ez szerintem mindent elmond. Ha eddig Fülöp volt a legrosszabb, akkor számodra van még egy pár dolog az ELTE tarsolyában. Ne legyen igazam.

 

@Fujitsu

Tudom. De egyetemi szinten ott tanítanak ilyeneket. Az ELTÉ-n BSc 6. félévében, fordítóprogramokon van egy kevés assembly, annál gépközelibb nincs. Én mondjuk nagyon élveztem azt a tárgyat, már a formális nyelveket is nagyon szerettem. Így kerültem azon kevesen közé, akik értették a C++ fordító hibaüzeneteit, nem csak megtanulták a jelentésüket.

Link to comment
Share on other sites

Fujitsu

Maradjunk annyiban, hogy ott is tanítanak ilyet (bár nem biztos, hogy pont azt, amit én írtam, hiszen pl. a digitet nekik egy másik tanszék tanítja). A mérnök informatikusok informatikusok (mindig az utolsó szó számít egy szakma nevében :D), a legtöbbet ők is a magas szintű programozással, szoftvertechnológiával, adatbázisokkal, algoritmusokkal, kódolástechnikával, hálózatokkal stb. kapcsolatban tanulnak. A különbség köztetek és köztük az, hogy ők hallanak olyat is, ami kicsit hardveresebb (digit, elektronika, jelek, számítógép-architektúrák stb.), meg szívatják őket a fizikával. :P De biztos jár errefelé is pár kolléga, aki kompetensebb a témában.

 

Én amúgy sohasem értettem azokat, akik tartanak az assemblytől, szerintem ugyanis semennyivel se nehezebb megérteni, mint egy magas szintű nyelvet. Hogy több pöcsölés van vele, azt aláírom. A fordítás se nehéz, és nem kell feltalálni a melegvizet, mert elég mechanikus, csak járatni kell az agyat hozzá. Amolyan agytorna az egész, mint a sudoku. :) Persze ezzel a tudással még nem mész át egy vizsgán, de én most nem is erről a részéről beszélek. :P

Link to comment
Share on other sites

Garono

BMGE?! Kb. 1 percbe telt, mire leesett. :D

Link to comment
Share on other sites

Fujitsu

A vicc az, hogy egy másik fórumon is jött egy hülye, hogy ő másfél milliót keres havonta a GDF-es diplomájával, mert le mertem írni, hogy a GDF évek óta a ranglista legalján van. Nem fogta fel a szerencsétlen, hogy azért, mert ő Hollandiában (vagy a franc tudja, hol, de azt hiszem, ott) másfél milliót keres, az még semmit se jelent globálisan a GDF-es diploma színvonalával kapcsolatban. Aztán két hozzászóláson belül kiderült, hogy egy fogyatékos, vitaképtelen idióta.

 

Szerintem az ilyenek minimálbéren melóznak valahol, csak tombol bennük a kisebbségi érzés, és jó nagy a pofájuk.

Link to comment
Share on other sites

[OP]Destroy-man

A legszebb az egészben, hogy tök mindegy, hogy hol tanulsz, mert megcsinálod valahol a tantárgyakat (akár a GDF-en), beiratkozol egy másik iskolába (mondjuk legyen a BME), ahol elfogadtatod a tantárgyakat (BSc rendszer esetén ez simán megtehető), majd lediplomázol a BME-n. Hol kaptad a diplomát? BME. Ja, hogy nem ott tanultál... Ezt már senki nem fogja tudni rajtad kívül. A fizetés meg a szerencsén is múlik, hogy milyen állást sikerül szerezni. Pesten még csak-csak találni jól fizető munkahelyet, de vidéken alig van rá lehetőség, hogy egyáltalán állásod legyen. Arról nem is beszélve, hogy lehet nem is a szakmádban fogsz dolgozni, mert oda nem keresnek senkit sem. Persze, hogy ott nem fognak annyit fizetni.

Link to comment
Share on other sites

KGigi

Az is egy vicc, hogy egy kalap alá veszik a néhány szakra specializálódott vagy egy adott területet oktató intézményeket a tudományegyetemekkel. Szerintem még mérnök szakok között is nagy a szórás, de hogy egy ELTE esetén ez a szám nem mond semmit, az biztos.

Link to comment
Share on other sites

Fujitsu

Az teljesen mindegy, itt csak a nyers számok alapján csinálnak összevetést. Nyilván ezer és egy szempontot fel lehet hozni, amit egy ilyen összehasonlítás nem vizsgál, de itt nem ez a lényeg. Ezekből az adatokból is kiderül pár dolog, ráadásul két hasonló profilú egyetem nagyjából össze is hasonlítható.

 

Ide csak azért linkeltem, mert van benne egy olyan félmondat, hogy:

 

A legmagasabb pályakezdő-keresetre az informatikai karon végzettek számíthatnak; az első két helyen a Pázmány és a Műegyetem informatikai karai állnak

 

Ha már szó esett az informatikáról a felsőoktatásban, gondoltam, ennyi megjegyzés elfér itt. :)

 

Destroy-man' timestamp='1385842803' post='460681']megcsinálod valahol a tantárgyakat (akár a GDF-en), beiratkozol egy másik iskolába (mondjuk legyen a BME), ahol elfogadtatod a tantárgyakat (BSc rendszer esetén ez simán megtehető), majd lediplomázol a BME-n.

 

Aha. Hát sok szerencsét ehhez a mutatványhoz. :D Azt azért megnézném, mennyire megy simán egy GDF-es tárgy kötelező mintatanterviként történő elfogadtatása a BME-n. A "lediplomázás" pedig szintén bonyolultabb egy pöppet, mert kissé más a követelményszint, és egyáltalán nem biztos, hogy más iskolákból hozott tudással megugrod a szintet.

 

Egyébként is butaság az egész, mert még ha így is lenne, az igazság az, hogy nem magának a diplomának van piaci értéke. Hanem annak a tudásnak, ami mögötte van. Lobogtathatsz te egy BME-s papírt, ha nincs mögötte a tudás, nem ér az egy kalap guánót sem. A komoly cégeknél pl. nem a diplomádra adják a fizetést, hanem a munkakörödre. Azaz ha van diplomád, de nem vagy alkalmas arra a munkakörre, amit azzal végezhetnél is akár, akkor más munkakörben leszel, más fizetéssel.

 

Tehát nem, nagyon nem mindegy, hol tanulsz és kiktől. Ez még annál is fontosabb, mint hogy milyen diplomád van. Persze vannak még jó egyetemek a BME-n kívül is, ne legyünk soviniszták. :)

Link to comment
Share on other sites

kléni

Arról nincs statisztika, hogy diploma nélkül, de viszonylag nagy tudással mennyit kereshetnék? :D

Link to comment
Share on other sites

[OP]Destroy-man

Ha van hozzá kapcsolatod, hogy felvegyenek, és jól végzed a feladatodat, akkor valószínűleg ugyan annyit, mintha lenne papírod.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...