diff options
Diffstat (limited to 'tyylimaare.txt')
| -rw-r--r-- | tyylimaare.txt | 157 |
1 files changed, 0 insertions, 157 deletions
diff --git a/tyylimaare.txt b/tyylimaare.txt deleted file mode 100644 index 2de2c18..0000000 --- a/tyylimaare.txt +++ /dev/null @@ -1,157 +0,0 @@ - -Scala-tyylimääre tekstipeliin -============================= - - -Seuraa kurssin tyyliopasta ja tätä ohjetta. Noudata tätä ohjetta, jos ohjeiden -välillä on ristiriita. Kirjoita mieluummin vähemmän koodia paremmin kuin -enemmän koodia laiskasti. Näin vähennetään tulevaisuuden työtä, joka syntyy -kun koodi on lähtenyt lapasesta eikä kenelläkään ole enää mitään käsitystä -ohjelman struktuurista. Tee näin etenkin, kun kirjoittamamme koodin laatua ja -yhtenäisyyttä arvioidaan palautuksessa. - -=> https://docs.scala-lang.org/scala3/book/ca-multiversal-equality.html -Kannattaiskohan käyttää? ^^ - - -This-sanan käyttö ------------------ - -This-sanaa tulee käyttää aina, kun se on mahdollista. Se selventää sitä, kenen -muuttuja on kyseessä ja missä se on määritelty. - - -Merkkijonojen muodostaminen ---------------------------- - -Käytä s"Arvo: $a, toinen arvo: ${this.b}" jos se ei ole aivan tajuttoman -kömpelö ratkaisu tilanteeseen. Se on lähes aina parempi ilmaisu kuin merkki- -jonojen summaaminen. - - -Tyyppien kirjaaminen --------------------- - -Nimellisiin funktioihin kirjoitetaan aina paluutyyppi, vaikka se olisi Unit tai -funktio ei olisi julkinen. Paluutyypin kirjoittaminen pakottaa miettimään vielä -kerran funktion todellista tarkoitusta. Kun sen on kirjoittanut, Scalan tyyppi- -järjestelmä huomaa virheet aikaisemmin ja ne saadaan korjattua. Julkisilla -funktioilla tyyppimääre toimii hieman kuin dokumentaatio. - -Julkisille muuttujille (etenkin ohjelman laajuisille vakioille) tulee kirjata -tyypit. - - -Rivien pituudet ---------------- - -Rivin maksimipituus on 80 merkkiä. Tässä sisennykset lasketaan kahdeksaksi -merkiksi. Tämä rajoitus on ikiaikaista perua siitä, kun terminaalien standardi- -koko leveyssuunnassa oli 80 merkkiä. Tämä rajoitus on kuitenkin nykyäänkin -kätevä, koska kahta 80-merkkistä riviä on helppo pitää vierekkäin melkein näy- -töllä kuin näytöllä. Lisäksi ylipitkä rivi voi olla oire epäselkeästä koodista, -joka muutenkin kuuluisi jakaa osiin. - -Alla on esimerkkejä, miten ylipitkiä rivejä saa (ja kuuluu) jakaa. - -Esim 1 -``` -def jokuNimi(parametri1: tyyppi1, parametri2: tyyppi2, parametri3: tyyppi3): paluutyyppi = - ??? - -def jokuNimi( - parametri1: tyyppi1, - parametri2: tyyppi2, - parametri3: tyyppi3 -): paluutyyppi = - ??? -``` - -Esim 2 -``` -kokoelma.filter(_ % 2 ==0).flatten.map(_.muutaHauskallaTavalla).contains(condition) - -kokoelma - .filter(_ % 2 ==0) - .flatten - .map(_.muutaHauskallaTavalla) - .contains(condition) -``` - -Esim 3 -``` -val pitkäMuttaHyväMuuttujanNimi = PitkäOlionNimiJotaEiTahdotaMuuttaa(jokuParametri) - -val pitkäMuttaHyväMuuttujanNimi = - PitkäOlionNimiJotaEiTahdotaMuuttaa(jokuParametri) -``` - -Esim 4 -``` -val olio = MoniparametrisenOlionLuoja(parametri1, parametri2, parametri3, parametri4, parametri5) - -val olio = MoniparametrisenOlionLuoja( - parametri1, - parametri2, - parametri3, - parametri4, - parametri5 -) -``` - -Esim 5: Huomaa myös tyhjän tilan käyttö ja kommentin alku- ja loppumerkkien - paikat. Tuollainen muotoilu on nättiä ja suotavaa. -``` -/* Pitkä dokumentaatiokommentti funktiolle, jonka kuuluu olla useammalla rivillä, koska muuten koodin dokumentaatiosta ei saa selvää ja on näin ollen turhaa*/ - -/* Pitkä dokumentaatiokommentti funktiolle, jonka kuuluu olla useammalla - rivillä, koska muuten koodin dokumentaatiosta ei saa selvää ja on näin ollen - turhaa. */ -``` - - -Sisennykset ------------ - -Sisentämiseen käytetään sisennyksiä eikä välilyöntejä. Näin jokainen ohjelmoija -saa katsoa koodiansa sillä sisennyspituudella josta pitää ja säästetään muisti- -tilaa. - -IntelliJ IDEAn tapauksessa tulee siis muuttaa asetus -File - > Settings - > Editor - > Code Style - > Java - > Tabs and Indents - > Use tab character - -Kuten Linus Torvalds on sanonut, jos tiedostossa on enemmän kuin kolme -sisennettyä tasoa ([tab][tab][tab]), olet todennäköisesti eksyksissä koodissasi -ja ohjelmasi sisäinen logiikka ja rakenne kaipaa parantamista. - -Kolmen sisennyksen sääntö ei ole kiveen hakattu, koska me ei olla yhtä hyviä -ohjelmoijia kuin Torvalds. Jos kuitenkin huomaat olevasi sisennysten -viidakossa, josta ei saa selvää, niin voi olla hyvä miettiä, voisiko ohjelman -rakennetta muokata vaikkapa lisäämällä apufunktioita yms. - - -If, match, for, while jne... ----------------------------- - -Jos saatavilla on ohjelman toimintaa ja datan virtausta kuvaavia korkeamman -asteen funktioita, ja et tiedä niiden suorituskyvyn olevan heikkoa verrattnua -itse tekemääsi toteutukseen, käytä korkeamman asteen funktioita. Jos et heti -keksi sopivaa korkeamman asteen funktiota, ei se tarkoita ettei sellaista ole. -Lue läpi korkeamman asteen funktiot Scalan dokumentaatiosta, esim. - -Vector-luokan dokumentaatio: -=> https://scala-lang.org/api/3.x/scala/collection/immutable/Vector.html# - -Buffer-luokan dokumentaatio: -=> https://scala-lang.org/api/3.x/scala/collection/mutable/Buffer$.html# - -Option-luokan dokumentaatio: -=> https://scala-lang.org/api/3.x/scala/Option.html# - - |