Moved the project to an IDEA project & wrote part of README.txt

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#
-
-