Skip to content

Commit d8f8f12

Browse files
committed
..
1 parent d140b36 commit d8f8f12

File tree

1 file changed

+9
-13
lines changed

1 file changed

+9
-13
lines changed

data/osa-3/1-virheiden-etsimisesta.md

Lines changed: 9 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
2-
path: '/osa-3/1-virheiden-etsimisesta'
2+
path: "/osa-3/1-virheiden-etsimisesta"
33
# title: 'Virheiden etsimisestä'
4-
title: 'On searching errors'
4+
title: "On searching errors"
55
hidden: false
66
---
77

@@ -12,12 +12,12 @@ hidden: false
1212

1313
</text-box>
1414

15-
1615
<!-- Olemme tähän mennessä harjoitelleet ohjelmointikielen perusrakenteiden kuten muuttujien, ehtolauseiden, toistolauseiden ja metodien käyttöä. Tutustutaan seuraavaksi lyhyesti ohjelmien ymmärrettävyyteen vaikuttaviin tekijöihin sekä virheiden etsimiseen. -->
1716

1817
We've so far been practicing the fundamentals of the language, such as variables, conditionals, loops, and methods. Let's now move on to look at some of the factors affecting the understandability of programs, and how errors are found.
1918

2019
<!-- ## Ohjelmoija sokeutuu koodilleen -->
20+
2121
## A programmer becomes blind to their own code
2222

2323
<!-- Ohjelmoija sokeutuu omalle koodilleen. Tutustutaan tähän efektiin alla olevan lyhyen videon avulla. Laske alla olevalta videolta kuinka monta kertaa valkopaitaiset pelaajat syöttävät palloa toisilleen. Videossa on mukana englanninkieliset ohjeistukset. -->
@@ -36,13 +36,11 @@ Fortunately, however, applying oneself to a given task lessens the occurrence of
3636

3737
<!-- Ohjelmoinnin harjoittelun kannalta tahaton sokeus näkyy muunmuassa siinä, että tiettyyn ohjelman osaan keskittyminen vie huomiota muista osista, jotka saattavat mielessä tällöin näyttää oikeellisilta vaikka niissä olisi virhe. Esimerkiksi ohjelman tulostuksen oikeellisuutta tarkasteltaessa ohjelmoija saattaa keskittyä tulostuslauseisiin ja vahingossa jättää osan logiikasta huomioimatta. -->
3838

39-
4039
One way in which perceptual blindness manifests itself in programming practice is when concentrating on a specific part of a program draws attention away from seemingly correct, yet erroneous parts. For instance, while inspecting the correctness of a program's output, a programmer may fixate on print statements, and mistakenly neglect aspects of the program's logic.
4140

4241
<!--
4342
Vastaavasti toistolauseen sisältävässä ohjelmassa olevaa virhettä etsiessä ohjelmoija saattaa keskittyä monimutkaisimpaan asiaan ensin, vaikka virhe on täysin muualla. Esimerkkinä alla oleva käyttäjän syötteiden keskiarvon laskemiseen tarkoitettu ohjelma, jossa on virhe -- virheen etsinnässä tyypillisesti keskitytään ensin toistolauseeseen. -->
4443

45-
4644
Likewise, a programmer may focus on the most complicated aspect of a program featuring a loop, although the error lies somewhere else completely. An example of this is the program below used to calculate the average of user-inputted values. It contains an error, and focus is typically first placed on the loop when searching for it.
4745

4846
<!-- ```java
@@ -91,17 +89,15 @@ if (sum == 0) {
9189
}
9290
```
9391

94-
9592
<quiznator id="5c3740e43972a914740fe479"></quiznator>
9693

9794
<!-- Tahaton sokeus on asia, jota ei voi varsinaisesti kytkeä pois päältä. Ohjelmoija voi kuitenkin muutamien kikkojen avulla vähentää sen esiintymistä -- näistä ensimmäinen on taukojen pitäminen, joka luonnollisesti vaatii työn ajoissa aloittamisen. Lisäksi esimerkiksi koodin kommentointi, nimentä ja "debug"-tulosteet auttavat myös. -->
9895

99-
Perceptual blindness is something that cannot be switched off completely. However, there are ways by which a programmer can lessen its effect - the first one being taking breaks. This, of course, requires that work is begun early. Additionally, commenting code, the naming of things, and "debugging" prints are examples of things that help too.
100-
96+
Perceptual blindness is something that cannot be switched off completely. However, there are ways by which a programmer can lessen its effect - the first one being taking breaks. This, of course, requires that work is begun early. Additionally, commenting code, the naming of things, and "debugging" prints are examples of things that help too.
10197

10298
<!-- ## Lähdekoodin kommentointi -->
103-
## Commenting the source code
10499

100+
## Commenting the source code
105101

106102
<!-- Kommenteilla on useita käyttötarkoituksia, joista yksi on ohjelman toiminnallisuuden itselleen selittämiseen esimerkiksi virhettä etsittäessä. Alla melko yksinkertaisen ohjelman suoritus on kuvattu auki kommentein. -->
107103

@@ -131,7 +127,6 @@ while (luku > 0) {
131127
}
132128
``` -->
133129

134-
135130
```java
136131

137132
/*
@@ -161,7 +156,6 @@ while (value > 0) {
161156

162157
Comments have no impact on the execution of the program, i.e., the program works in the same way with the comments as it does without them.
163158

164-
165159
<!-- Edellä käytetty ohjelmoinnin opetteluun tarkoitettu kommentointityyli on toistaalta ohjelmistokehityksene kelpaamaton hyvin raskas. Ohjelmistoja rakennettaessa pyritään siihen, että **lähdekoodi kommentoi itse itsensä**. Tämä tarkoittaa sitä, että ohjelman toiminnallisuus tulee ilmi luokkien, metodien ja muuttujien nimistä. -->
166160

167161
The commenting style used above for learning programming is, however, quite burdensome in real development, where the goal instead is for the source code to be **self documenting**. This means that the functionality of the program should be evident from the way classes, methods, and variables are named.
@@ -189,6 +183,7 @@ public static void tulostaLuvutIsoimmastaPienimpaan(int mista, int mihin) {
189183
}
190184
}
191185
``` -->
186+
192187
```java
193188
public static void printValuesFromTenToOne() {
194189
int value = 10;
@@ -209,9 +204,8 @@ public static void printValuesFromLargestToSmallest(int start, int end) {
209204
```
210205

211206
<!-- ## Virheiden etsintä print-debuggauksella -->
212-
## Searching for errors with print debugging
213-
214207

208+
## Searching for errors with print debugging
215209

216210
<!-- Eräs ohjelmoinnissa tarvittava taito on testaus- ja debuggaustaito, jota käytetään virheiden etsimisessä. Yksinkertaisin tapa ohjelmissa olevien virheiden etsimiseen on ns. print-debuggaus, joka käytännössä tarkoittaa rivikohtaista viestien lisäämistä. Viestejä käytetään ohjelman suorituksen seuraamiseen, ja viestit voivat sisältää myös ohjelmassa olevien muuttujien arvot. -->
217211

@@ -243,6 +237,7 @@ if (summa == 0) {
243237
System.out.println("Lukujen keskiarvo: " + (1.0 * summa / lukuja));
244238
}
245239
``` -->
240+
246241
```java
247242
Scanner scanner = new Scanner(System.in);
248243
int values = 0;
@@ -333,4 +328,5 @@ if (sum == 0) {
333328
<!-- Kun ohjelman suorittaa useampaan otteeseen sopivilla syötteillä, ohjelmasta löytynee siinä piilevä virhe. Sopivien syötteiden keksiminen on myös oma taitonsa -- tärkeää on pyrkiä tarkastelemaan ns. corner caseja, eli tilanteita, joissa ohjelman suoritus voisi olla poikkeava. Tällaisia tilanteita ovat esimerkiksi tilanne, missä käyttäjä ei syötä yhtään hyväksyttävää lukua, käyttäjä syöttää pelkkiä nollia, tai käyttäjä syöttää hyvin isoja lukuja. -->
334329

335330
When a program is executed multiple times with the appropriate inputs, the hidden error is most likely found. Coming up with suitable inputs is a skill in its own right. It's essential to test the so-called corner cases, i.e., circumstances where the program execution could be exceptional. An example scenario is one where the user only inputs unacceptable numbers, or zeros, or very large numbers.
331+
336332
<quiznator id="5c385de6ddb6b814af31d7d0"></quiznator>

0 commit comments

Comments
 (0)