Så mycket sämre S01-E02

Vi fick i uppdrag (ja ja, av oss själva) att försämra lite kod. Vi utgick ifrån kod för delar av ett medlemsystem. Och som vanligt bidde det en film av det hela. Kolla här: https://vimeo.com/237063870

Vad var det som skulle göras då? Jo, vi skulle kika på klasserna:

  • Member – en klass som beskriver memdlemmar i systemet
  • MemberCSVFileReader – klass som kan läsa en CSV-fil med medlemmar
  • MemberCSVFileReaderTest.java – klass som testar MemberCSVFileReader

I filmen kommer vi upp med en hel del riktigt bra (alltså dåliga) förbättringsförslag (försämringsförslag). Vi undviker i detta avsnitt att försämra på några av de sätt vi gjorde sist, så du kommer t ex inte att se svengelska namn.

Vi är i dag speciellt nöjda med:

  • en handskriven default-konstruktor – om vi skriver den själv är det ingen default-konstruktor!
  • en interaktiv konstruktor – vem i hela världen vill ha en interaktiv konstruktor??
  • att Member-klassen känner till formatet på en fil – suck, jo visst finns det exempel på detta i riktiga projekt, men yuörgh va fult det blir
  • att vi använder Scanner typ överallt   – kom igen, Scanner, nu får ni släppa Scanner!
  • testkod och main-metod i Member-klassen

Koden finns här:

https://github.com/progund/saa-mycket-saemre/tree/master/Member

 

Advertisements
Posted in Uncategorized | Leave a comment

Intervju med Daniel Stenberg

I fredags intervjuade vi Daniel Stenberg. Tanken bakom denna, föregående kommande intervjuer är att diskutera pedagogik och programmering.

https://juneday.podbean.com/e/interview-with-daniel-stenberg/

 

Posted in Uncategorized | Leave a comment

Intervju med Johan Thelin

I fredags intervjuade vi Johan Thelin. Tanken bakom denna och kommande intervjuer är att diskutera pedagogik och programmering.

https://juneday.podbean.com/e/interview-with-johan-thelin/

 

Posted in Uncategorized | Tagged | Leave a comment

Så mycket sämre – ny videoserie

Vi har börjat spela in en liten filmserie som vi kallar “Så mycket sämre”. Tanken är att vi tar kod som är i ett ok skick och gör den sämre (“så mycket sämre”). Det är ett försök att på ett lite roligare sätt diskutera kodkvalitet.

Kolla in på kanalen Så mycket sämre (borde den heta “Saa mycket saemre“). Oavsett detta, första avsnittet heter Så mycket sämre – avsnitt 1, säsong 2017.

En kort pod om detta finns också: Så mycket sämre

Posted in Uncategorized | 1 Comment

Tankar kring kursbetyg , S01E01

 

Efter att ha funderat länge på ett oväntat dåligt kursbetyg har vi en del reflektioner som vi vill diskutera. Betyget samt en del efterkommande kommentarer har gjort att vi diskuterat kursbetyg en hel del på sistone.

Motsvarande poddcast: https://juneday.podbean.com/e/tankar-kring-kursbetyg-s01e01/

 

Bakgrund till problem med kursvärderingar

Vi börjar med att ta upp två saker vi ser som viktiga när man lär ut programmering.

  • Noggrannhet (t ex kolla returvärdet vid malloc när man skriver C-kod) är, enligt vissa studenter och ibland också lärare, jobbigt eller kanske t o m svårt. Kanske saknar lärarna adekvat kunskap och erfarenhet?
  • Skriva generella program eller delar av program verkar, eftersom det i princip aldrig görs, också svårt. Det upplevs enklare av studenterna om lärare visar speciella lösningar på speciella problem. Vi har sett kod som “parse:ar” 0-2 argument. Koden är komplex vid 2 argument och blotta tanken på 6 argument får en att få rysningar.

Nogrannhet

Vi exemplifierar ovanstående med lite kod:

 char * name = calloc(sizeof(char), length);
 ……
 name = realloc(name, sizeof(char)*length);

Det ser väl ok ut? Men gick det verkligen bra att allokera minnet? Vi måste kolla om det gick bra och vidta en åtgärd om det inte gick bra.

  char * name = calloc(sizeof(char), length);
  if (name == NULL)
  {
      return MEMORY_FAILURE;
  }
 ……
 char * tmp = realloc(name, sizeof(char)*length);
 if (tmp == NULL)
 {
    free(name);
    return MEMORY_FAILURE;
 }

Ok, koden är mer robust. Men den är också mer komplex. Eller är det så att den första kodsnutten är inkorrekt?

Generalitet

Kolla på vår tidigare bloggpost där vi diskuterar en övningsuppgift: https://programmeringspedagogik.wordpress.com/2016/09/21/hur-manga-i-ar-det-i-liverpool/

if (argc == 1)
{
  in_stream = stdin;
}
else if (argc == 2) 
{
  in_stream = fopen(argv[1], "r");
} 
else if (argc == 3)
{   
  in_stream = fopen(argv[1], "r");
  if (strcmp(argv[2], "--long")==0)
  {
  ....
  }
  else 
  {
  ...
  }
}

Det här skalar verkligen inte. Det finns ganska enkla strategier för hur man “parsar” argument given på kommandoraden. Ett enkelt sätt är att loopa igenom alla argument. Vi har skrivit lite om detta på vår wiki: http://virt08.itu.chalmers.se/mediawiki/index.php/Command_line_parser

OBS: felkontroll saknas i koden ovan

Slutkläm

Om man struntar i ovanstående blir det akademiprogrammering av utbildningen. Vi förespråkar det motsatta, dvs skriv generell och robust kod (var noggrann) osv.

Men vi har vissa tvivel eller kanske snarare tankar kring detta. Om man följer de två principerna ovan undrar vi om programmering är svårare att lära sig, kanske t o m svårt? Förmodligen gör det inlärningen av programmering svårare. Men kan vi verkligen ta bort detta moment utan att tappa värde? Vad har sådan här kunskap för värde i fortsatta studier eller yrkesliv. Är det lite som att strunta i hållfasthetslära för arkitekter? Är det verkligen adekvat att lära ut att skriva program som bara funkar under vissa förutsättningar, t e x att det finns en fil som heter people.dat i katalogen där programmet körs istället för att ange filen som argument och läsa stdin om ingen fil anges? Men å andra sidan kan man undra om det är enklare att skita i felhantering och generalitet. Men vad blir då följderna? Dels för kursen och dess betyg, dels för studenterna och deras kunskap.

Vi har sett och jobbat med många som tror sig kunna, men egentligen inte kan, programmera. De slarvar ofta med helheten, t ex felhantering. 

Vi försöker stenhårt att verkligen lära ut grunder, noggrannhet, generalitet osv.

Inom kort kommer vi att diskutera:

  • Sjunker kursbetyget på en kurs om man är noggrann?
  • Hur påverkas synen på läraren av vad man lär ut?
  • Vilka krav kan vi lärare ställa på studenter?

 

Hör gärna av dig, genom at kommentera på denna blogg.

 

Posted in Uncategorized | Leave a comment

Pod om att undvika uppskjuten definition

Ny podd släppt: https://juneday.podbean.com/e/undvik-uppskjuten-definition-sa-langt-det-ar-mojligt/

Podden är baserad på en gammal bloggpost om vikten att undvika uppskjuten definition: https://programmeringspedagogik.wordpress.com/2016/05/15/undvik-uppskjuten-definition-sa-langt-det-ar-mojligt/

 

 

 

Posted in Uncategorized | Leave a comment

Kodstandard i undervisning

Bakgrund

Lyssna gärna på vår podcast i ämnet: https://juneday.podbean.com/e/kodstandard-i-undervisning/

Vi har, när vi förbereder ett Java-projekt i en kurs på GU, läst en hel del på studenters kod. Det är ganska uppenbart att studenterna inte använder kodstandard. Åtminstone inte i en grad där kodstandarden genomsyrar koden. Är detta bra eller dåligt frågade vi oss?

Vi själva, som de Pella-rediga vi är, försöker använda oss av en kodstandard. Numera är det Googles kodstandard vi använder. Blir det enklare för studenterna att vi följer en standard?

Rent generellt är det så klart bra med kodstandard. Men vi kommer inte diskutera kodstandard utifrån det generella. Istället kommer vi diskutera kodstandard i undervisning. Mer specifikt huruvida det är viktigt om vi lärare använder sådan och om det är viktigt att vi kräver av våra studenter att de använder en sådan.

Bör lärare använda kodstandard?

Vad tycker du själv?

Kostar det något för en lärare att faktiskt använda kodstandard? Det kan väl knappast ses som något jobbigt att följa åtminstone delar av en standard?

Tror du att ansträngningen att vara konsekvent påverkar elevernas möjlighet att lära sig läsa och skriva kod?

Kan man vinna något ytterligare på att använda kodstandard? Hur uppfattar studenterna dig om din kod ser olika ut, särskilt om du uppmanar studenterna att följa en standard eller att vara konsekventa.

Bör studenter krävas använda kodstandard?

Det är uppenbart att det är bra att följa och lära sig en standard. Men är det verkligen så pass viktigt för nybörjare och deras inlärning av Java att följa en standard strikt? Vi tycker att man kan slappna av lite granna här och istället uppmuntra dem att följa en standard.

Fundera på om det är ok att:

  • du som lärare inte följer en standard
  • du som lärare  kräver av studenter att följa en standard

Saker vi ser som viktiga när du som lärare skriver kod som ges ut

I kort tycker vi att följande är viktigt:

  • Bra namn på variabler, metoder osv
  • Indentera på ett sätt
  • Bra namn på variabler, metoder osv
  • Skilj på små och stora bokstäver

Bra namn på variabler, metoder osv

Ett skräckexempel på nam är oddOrNot som vi hittade på https://www.javacodegeeks.com/2015/06/java-programming-tips-best-practices-beginners.html. Varför är det inte ett bra namn? Vad borde den heta istället?

Om du vill hålla reda på antalet studenter med hjälp av en variabel. Kalla den då t ex för numStudents. Använd inte b1, num, antal ….  

Indentera på ett sätt

Det är enklare att läsa kod om den ser samma ut. Varför inte bjuda på detta då för studenterna. Om det blir lättare för dem att läsa din kod ser vi inget skäl till att inte göra detta.

Det kan ju dessutom ge ett intryck av att det är olika författare som skrivit koden. Tyvärr har vi sett kod som florerar på internet som dyker upp här och där på olika kurser och i material. Att låna kod må vara hänt (nja, mer om detta senare) men var då konsekvent.

Använd engelska namn

Sluta direkt med att kalla din klass för något av följande:

  • Raenta
  • Ranta
  • Ränta

om det är menar ränta som man förr fick på sina pengar på banken. Kalla hellre klassen för Interest.

Skilj på små och stora bokstäver

Det finns en uppsjö regler i kodstandarder som specar namn. Följande är, enligt oss, viktigast:

  • Klasser, interface och enum skall (ja, skall!) ha namn med stor initial bokstav.
  • Variabler och metoder skall (ja, skall!) liten initial bokstav.
  • Undantag kan gälla konstanter.

Återigen är det enklare att läsa kod som följer en standard. Särskilt har nybörjare svårt att lära sig skillnad på typ och identifierare. Varför då bidra till förvirringen? Ta till exempel följande syntaktisk korrekta kod:

package a;
class a{
  a a;
  a(a a){
    this.a = a;
  }
  a a(){
    return a;
  }
}

Är detta bra kod? Är det lätt för en student att tolka koden?

 

Posted in Uncategorized | Leave a comment