1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
|
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#
|
