Child pages
  • Fejtörők
Skip to end of metadata
Go to start of metadata
Azért nyitottam ezt a topicot,hogy Java-fejtörőket írjatok ide(nem kell túl nehéz).
Az a kihívás,hogy minél kevesebb karakterből kell megoldani ezeket:.
Szabályok 
  •  a Space nem számít karakternek,de minden más igen,kivéve az importálásokat.
  • természetesen a megfelelő eredményt kell adni.
  • nem válthat ki el nem kapott kivételeket!
  • mindig függvényt kell írni.
Itt is van egy feladat:
     Írjatok függvényt, aminek át kell adni egy egész (int) számot, és a függvény visszatér egy vektorral,ami a számig található prímeket tartalmazza.

Pl. hogyha meghívom  a függvényt a 10-es számmal,akkor visszaad egy vektort,aminek elemei : 2,3,5,7.

Nemsokára írom a megoldásomat a feladatra,addig írhattok megoldást,vagy feladatot is ;)

      
      
Page viewed times
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels

19 Comments

  1.  Van még egy szabály:
        A deklaráció sem számít bele a karakterszámba.
  2. Jajj !!!!

    Nekem nem tetszenek a szabályok, vagyis mondjuk úgy nem szeretek gány kódot írni, márpedig a feltételek erre inspirálnak. Borzalmas csúnya csak egykarakteres változó neveket használni, nem kommentelni, betűket spórolni. Még az a szerencse hogy a sortörés nem számít 2 karakternek különben egysoros programok születnének. A feladat sem izgalmas, így én átfogalmazom ha szabad:

    Írjunk olyan KOMMENTEZETT TISZTESSÉGES programot (java application) mely prímszámokat állít elő. Elindíthatod, és leállíthatod bármikor. Ha leállítottad akkor valahol eltárolja az addig előállított prímszámokat. Ha másnap újraindítod, innen folytatja. Így minél többször futtatod annál nagyobb prímszám halmaz áll rendelkezésedre. Érdemes elgondolkodni a sebességen, az óriási adathalmaz kezelésen stb. Ezt nagyon régen Oracle környezetben találtuk ki egy kollégámmal, ott egy PL/SQL eljárás csinálta volna a dolgot, és természetesen adatbázisba irogatta volna a prímszámokat.
  3. Csak a vicc kedvéért itt van egy scala megoldás. Nem biztos hogy a lehető legrövidebb: 
    def a(n:Int) = (2 until n).filter(n => !(2 until n).exists(n%_==0))
    A kevesebb karakter -amellett hogy olvashatatlan kódot eredményezett- itt most szuboptimális megoldás készítésére sarkallt. !(2 until n/2) hatékonyabb lett volna, de az két karakterrel több.

    Clojure-ben gyanítom hogy még rövidebben le lehetne írni.
    Java-ban szerintem nincs értelme rövidségre menni, legfeljebb poénból, mert a nyelvhez szorosan hozzátartozik a ceremónia és a kódzaj. Pl. objektumokat kell készíteni hozzá, hogy függvényt tudj írni.
  4.  Persze,ezt csak a buli kedvéért írom.
    Amúgy kollégákkal szoktunk tisztán kódolós versenyt rendezni.
    Valaki lebonyolíthatná itt is,az is jó megmérettetés.
    Egyébként én is a clean coding híve vagyok,de jó agytorna lehet egy jó kis ilyen fejtörő is.
    Ja,amúgy xesj.hu-nak írom,hogy mint azt Robert C. Martin is mondja:"A kommentelés azt jelenti,hogy a kód nem fejezi ki önmagát,
    pedig ez a Clean Coding lényege".
    De a feladat tetszik,elkezdek dolgozni rajta.
    Mindenki írhat új feladatot,csak írja oda,hogy tisztán,vagy röviden kell elkészíteni.
  5.  Egyébként még annyit,hogy tisztán kódolási feladatként imádom a sima prímgenerátort,már vagy egy éve tökéletesítgetem a kódját.
  6. Nem érdekel mit mond Robert C. Martin, mert nincs igaza !
  7. "Nem érdekel mit mond Robert C. Martin, mert nincs igaza!"
    Ehhehe, ez azért elég ütős beszólás. :)
  8. Egyébként még annyit,hogy tisztán kódolási feladatként imádom a sima prímgenerátort,már vagy egy éve tökéletesítgetem a kódját.
    Ez elég tömör?
      public static void pl(List<Integer> p, int n)
      {
        int i = 2; if (n >= i) { while (i < n - 1 && n % i != 0) i++; if (n % i != 0 || n == i) p.add(n); pl(p, n - 1); } else Collections.reverse(p);
      }
    :)
     
  9. Hátha valaki hülyeséget beszél akkor arra minimum így reagálok.
    Azért az nem vita tárgya hogy kommentezni egy programot jó dolog.
    Ha ennek a fickónak a beszólását elfogadjuk akkor a java is úgy szar ahogy van ugyanis agyon van kommentezve az alaposztályok forráskódja.
  10. A java forráskódja főleg javadoc kommentekkel van tele. Az nem gáz hogy az bő lére van eresztve, mivel az a publikus API doksi része. R.C.Martin szerint az a gáz, ha több soros inline kommentekkel kell megmagyarázni, hogy egy kódrész mit csinál, vagy miért azt csinálja amit. Nem osztom én sem mindig 100%-ban a véleményét, de ő olyan ember, hogy amikor nincs igaza akkor is felettébb elgondolkodtató amit mond, vagy inkább ír.
  11. Én erre a mondatra reagáltam, amit Aksi írt:

    "A kommentelés azt jelenti,hogy a kód nem fejezi ki önmagát, pedig ez a Clean Coding lényege".

    Szóval ez a mondat így magában nagyon false. Ugyanis az is komment hogy vonalat húzok hogy jobban lássam a forrást és nem üres sorokkal tagolom. Az is komment hogy ki a szerző, ezt hogy a fenébe fejezné ki egy sima kód ? Látszik a kód stílusa ? Talán Pistike "a"-betűs változókat használ, Bandika v1, v2, v3-at ? Egyes részeket úgy veszünk ki a kódból hogy nem töröljük hanem kommenteljük, mert később vissza kell kerülniük, de ezek szerint ez tilos mert így nem clean coding. Mi van ha a kollégám kódjába piszkálok mert ő beteg, és a beírt sorok elé beszúrom hogy:

    // módosítás: xesj.hu 2012.03.01
    // módosítás vége

    ...stb stb stb, szóval még sorolhatnám miért is jó kommentezni.

    Az viszont nincs ebben a mondatban hogy természetesen a kommentezésnek is lehetnek hátrányai pl. a többsoros inline kommentek. De ezekről te szóltál, nem pedig R.C. Martin ! Tehát nem árt tisztázni miről beszélünk, én egyetlen mondatra reagáltam.

  12. A kikommentezett kód bennhagyás és a módosítások logjának beírása kommentbe pont rossz szokások. Azért vannak verziókezelő eszközök, hogy ezeket kezeljék. Az ASCII-art díszítősorok is rossz szokások. Én is használom néha, de olyankor tudom hogy azt az adott osztályt vagy metódust illene szétvágni. Azok a kommentek amiből doksi generálódik vagy formális okokból léteznek (pl. licensz szöveg) nem tartozik ide. 
  13.  Természetesen,nem pontosan így gondoltam.
     A szerzőkre utaló és ilyen kommentek elviselhetők.
     Arra gondoltam,hogy pl. ahelyett,hogy :
             int a = 0;  //az eltelt napok száma 
     helyett  használjuk inkább ezt :
             int elteltNapokSzama = 0;

    Ha ilyen nyilvánvaló változó-,objektum- és függvényneveket használunk,akkor nem indokoltak a "normális" kommentek(amik a kódot magyarázzák).

  14. Ezzel a példával teljesen egyetértek. Már sokszor mondtam de volt egy olyan kollégám aki mindenhol minden programjában csak és kizárólag v1, v2, v3, ..., vN változóneveket használt !
  15. Sziasztok !

    Hol vannak a többi fejtörők ?

    Én egyszer egy olyan java feladaton gondolkodtam, amiben kapunk egy matematikai kifejezést tartalmazó stringet, és ezt kell kiértékelni pl: "2*(3+1/3-(567.8/2*8))"

    Ilyet kiértékelőt csináltatok már ?
    Még én sem, csak jó kis feladatnak tartom.
    Szóljatok ha a JDK-ban erre van egy külön metódus, és már meg sem kell írni :)

    Joe

    1. Anonymous

      Egy könnyen megvalósítható algoritmus

  16. Kézzel nem annyira érdemes nekimenni.
    Parser generátort vagy lexert érdemes használni. Java környezetben ez a Javacc, vagy az antlr.
    Formálisan leírod a nyelvtant, erre generálódnak neked mindenféle java osztályok, amik az absztrakt szintakszisfát reprezentálják és amiket fel tudsz használni a szemantika megvalósításához.
  17. Pedig szép feladat. Egyszer meg akarom csinálni...
  18. Egy másik könnyebb fejtörő, amit érdemes lenne megcsinálni, én egyszer már megcsináltam. Szóval az úgy volt hogy megtetszett az adatbázisok ügyeskedése a tranzakciók terén vagyis ha valaki módosít az adatokon azt addig ne lássa más amíg el nem commit-álja, de ha ő lekérdezi az adatbázist akkor ő lássa a módosulásokat. Természetesen itt tiszta java alaposztályokkal kell megoldani a dolgot, a standard edition osztályokkal, nincs mögötte adatbázis és semmi segédeszköz.

    Legyen egy Database nevű osztály a következő metódusokkal:

    insert(int session, Elem elem)
    update(int session, Elem elem)
    delete(int session, Elem elem)
    select(int session, int elemKulcs)
    rollback(int session)
    commit(int session)

    Valami egyszerű kötött típusú objektumot lehet csak belepakolni (legyen Elem osztály 2 taggal: int kulcs, String ertek) az "adatbázisba" természetesen ennek az objektumnak van egy int típusú kulcsa)
    S hogy ne kelljen mondjuk szálakkal játszani, a metódusok első paramétere mondja meg melyik melyik adatbázis session végzi a műveletet. Tehát pl:

    Elem elem = new Elem(400, "paprika");
    database.insert(33, elem);
    database.select(33, 400); // ő látja az elemet
    database.select(25, 400); // ő NEM látja az elemet
    database.commit(33);
    database.select(25, 400); // most már ő is látja az elemet

    Na nem ragozom tovább, remélem értitek mire gondoltam, szerintem ez is jópofa dolog !
    Azt hiszem amikor az egyik session módosította az elemet, de még nem commit-álta, akkor egy másik session ugyenerre az elemre vonatkozó update-je nem várakozott a commit/rollback-ig (default adatbázis működések), hanem úgy oldottam meg hogy exception-t dobtam ("az objektum foglalt, nem módosítható"), de erre már nem emlékszem pontosan hogy csináltam...