Szökőév eldöntése Javában?

> Szökőév eldöntése Javában?

Azok számára akik a válaszért jöttek, a standard Java-ban implementálva van LocalDate-ben, Year-ben és sima int számára is a függvény:

LocalDate.now().isLeapYear();

Year.now().isLeap();

Year.isLeap(2019);

A fentebbi függvények évszámtól függetlenül a Gergely-naptár szabályai alapján számolnak. Ha figyelemebe szeretnénk venni hogy 1582 előtt a Julán napárat használták akkor ezt érdemes a GregorianCalendar osztályt használni:

new GregorianCalendar().isLeapYear(2019);

"GregorianCalendar implements proleptic Gregorian and Julian calendars. That is, dates are computed by extrapolating the current rules indefinitely far backward and forward in time. As a result, GregorianCalendar may be used for all years to generate meaningful and consistent results. However, dates obtained using GregorianCalendar are historically accurate only from March 1, 4 AD onward, when modern Julian calendar rules were adopted. Before this date, leap year rules were applied irregularly, and before 45 BC the Julian calendar did not even exist."

#14

Te pedig légy szíves a választ. Nem a kérdezőnek írtam hanem azoknak akik esetleg idetévednek és a címben feltett kérdésre keresik a választ, azaz erre: "Szökőév eldöntése Javában?".

Tisztában vagyok vele hogy a kérdező valami iskolai feladatot szeretne megoldani és nem konkrétan arra kíváncsi hogy hogyan lehet eldönteni egy évszámról hogy szökőév -e.

"Soha nem értettem azokat akik képesek egy

if (expression) return true;

else return false;

kódod írni. Vajon mi veszi rá őket erre?:D"

Azok írnak ilyet, akik gondolnak az utánuk következő programozóra, aki majd a projektet viszi.

Ez a példa még viszonylag egyszerű, de a hajamat tudom kitépni olyanoktól, hogy valaki csak azért is összesűrít valamit 2-3 átlathatatlan sorba, ahelyett, hogy írna egy normálisan áttekinhető, picit hosszabb kódot.

De itt pont hogy nem átláthatóvá teszi, hanem komplikálja. Sokkal érthetőbb, ha csak simán visszadod a logikai értéket.

Ettől már csak az a rosszabb amikor invertálva van.

Illetve még az if(kifejezes == true) is hasonló kategória.

Nem hiába javítják ezeket ki a fejlesztést segítő eszközök, pl ReSharper.

Kijavítják, tehát egyszerűbbé, átláthatóbbá teszik a kódot mások számára is.

Persze nyilván lehet úgy tömöríteni a kódot, hogy rövidebb legyen és átláthatatlanabb, ahogy mondtad. De a fenti eset nem az.

Nekem az a tapasztalatom hogy egy rutinosabb fejlesztő számára sokszor a tömör kód nem megzavaró hanem lényegre törő. Én az asztalt fejeltem le mikor a múlthéten többször is belefutottam a következő két sor egyikébe:

return kifejezés ? true : false;

return !kifejezés ? false : true;

Ettől csak egy lépésre van a

if (kifejezés) {

return true;

} else {

return false;

}

Én nem vagyok abban biztos hogy ez átláthatóbb mint a sima "return kifejezés;", de ha le akarjuk a logikát mindenképpen választani a return kifejezésről (van benne ráció), akkor is inkább változó(ka)t használunk, illetve felbontjuk a kifejezést kisebb részekre, if-else hálók helyett.

Mellesleg szerintem igen csak zavaró hogy az IDE (én IntelliJ IDEA-t használok), illetve a Sonar (kódminőség ellenőrző) folyamatosan warningol meg besárgít az ilyen kódok miatt és eltereli a figyelmet a valós, figyelmetlenségekből származó hibákról.

Függetlenül ettől még lehet hogy egy kezdőnek átláthatóbb ha körülményesen kiír mindent, hiszen van különbség azok gondolkodása között akik évek óta a szakmában vannak és azok között akik csak most kezdik, viszont én ha valakit tanítok akkor igyekszem mindig clean kódot mutatni amit érdemes megtanulni és nem olyan kódot ami miatt mások összevonják a szemöldöküket.