Lite problem med stebarn i Java!

[Bro2]

Derfor ber jeg om en forklaring.

Har du lest kontrakten Modell_grensesnitt (merk også at selve navnet bryter med de facto standard på navngiving, i.e. «CamelCase»)?

 

Har du lest kontrakten Modell_grensesnitt (merk også at selve navnet bryter med de facto standard på navngiving, i.e. «CamelCase»)?

 

Au, au, au for et navn. Da jeg var gruppelærer på Ifi dyttet jeg kodekonvensjoner inn i hodene til mine stakkars studenter hele tiden, dette gjør vondt for meg å se.

 

Sukk. Trist.

Jeg synes nesten synd på deg...

 

Har du lest kontrakten Modell_grensesnitt (merk også at selve navnet bryter med de facto standard på navngiving, i.e. «CamelCase»)?

 

Au, au, au for et navn. Da jeg var gruppelærer på Ifi dyttet jeg kodekonvensjoner inn i hodene til mine stakkars studenter hele tiden, dette gjør vondt for meg å se.

 

Sukk. Trist.

Meget trist. Spesielt med tanke på at det ikke engang er INF1000, men INF1010, objektorientert programmering. Alle som programmerer Java i større skala vet om de forskjellige diskusjonene rundt navngiving på grensesnitt (e.g. IClassName og implementasjonen ClassName, eller ClassName med implementasjonen StandardClassName eller ClassNameImpl osv.), men å kalle det _grensesnitt, ja, det er hinsides enhver programmerer å forstå.

 

I tillegg er jeg sterk motstander av å kode på norsk. Jeg mener all kode, i.e. klassenavn, grensesnittnavn, metodenavn og feltvariabler (inkl. lokale variabler) bør være på engelsk, og det gjelder også kommentarer og dokumentasjon.

 

Shit, den bryter med navnkonvesjonen!

Wow! Jeg må si meg helt overbevist!

 

At navnet inkluderer "grensesnitt" er mest sannsynlig for å gjøre det tydelig at det faktisk er et grensesnitt. Ordet grensesnitt brukes nemlig på forelesning.

 

Hvis dette er det beste argumentet for at denne oppgaven er idiotisk må jeg si meg lite imponert.

 

Min erfaring med denne oppgaven er at studentene lærer svært mye. Hvis dere påstår noe annet kan det være en fordel å komme med et bedre argument enn "uff, den bryter med navnekonvensjonen".

[pgdx]

Jeg anså meg stort sett som ferdig med denne diskusjonen, men siden du ikke er fornøyd ...

 

Konvensjoner er svært viktig når man programmerer. Jeg skal ikke anta mye om deg, men det virker nesten som om du enten har et personlig forhold til denne oppgaven (laget den, eller på en annen måte tilknyttet dette kullet eller UiO) eller at du bare ikke har programmert særlig mye.

 

	/**
 * Registrerer en ny person i personregisteret.
 *
 * @param	 nyPerson   den nye personen som skal legges inn i personregisteret 
 * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
 */
public String leggTilPerson(Person nyPerson);

null skal faktisk returneres dersom ingen feil oppstår. Vel ... hva skal man si? Ingen steder i Collections returneres null ved suksess. Jeg forstår at studentene ikke kan exceptions, men å returnere null ved suksess er bare uintuitivt og misbruk av nullpekere. Det samme gjelder for mange andre metoder i grensesnittet.

 

	/**
 * Registrer en ny far eller ny mor for en person.
 *
 * @param	 person		 navn på person som får registrert ny far eller mor
 * @param	 nyFarEllerMor  navn på den nye faren eller moren
 * @param	 mor			angir om det er en ny far eller ny mor som skal registreres
 * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
 */
public String nyFarEllerMor(String person, String nyFarEllerMor, boolean mor);

Skal strengen person få en ny far- eller mor-streng? Tja ... ikke overbevisende, og ihvertfall ikke tilknyttet virkeligheten på noe som helst plan.

 

	/**
 * Finner helsøsken til en person. 
 *
 * @param	 navn		navn på person man skal finne helsøsken til
 * @return	helsøsken i et array. Hvis ingen helsøsken ble funnet returneres null
 */
public Person [] finnHelSosken(String navn);

Jeg ser jo her til min overraskelse at man skal returnere Person-objekter og ikke strenger, det er positivt. Hvorfor da må inputen være String navn og ikke Person person? Det samme gjelder alle tilsvarende metoder inkl. public boolean erSoskenbarn(String denEne, String denAndre);

 

Jeg skjønner hvis du forsvarer oppgaven fordi den (liksom) skal være mer pedagogisk enn andre, men det er mye rart som må virke forvirrende for nye Java-ere. Du kan få komme med svar her hvis du vil, men hvis ikke du har noen direkte spørsmål, kommer jeg til å si meg ferdig med denne diskusjonen.

[steingrim]

Jeg synes nesten synd på deg...

Nuvel, det skal du få slippe.

 

Men jeg må si, jeg tok en nærmere titt på grensesnittet man skal implementere i denne oppgaven. Det var såpass rotete og lite konvensjonelt at det ser ut til å være laget av en førsteårs-student og ikke en foreleser. Noe av poenget er jo å lære hvordan skrive god kode, ikke hvordan sause i hop alt og allverdens i Modell_grensesnitt. Og hvis man ønsker å lære bort objekt-orientering så er ikke dette grensesnittet et særlig godt eksempel.

[Bro2]

Jeg anså meg stort sett som ferdig med denne diskusjonen, men siden du ikke er fornøyd ...

 

Konvensjoner er svært viktig når man programmerer. Jeg skal ikke anta mye om deg, men det virker nesten som om du enten har et personlig forhold til denne oppgaven (laget den, eller på en annen måte tilknyttet dette kullet eller UiO) eller at du bare ikke har programmert særlig mye.

Helt riktig, jeg er tilknyttet dette kullet. Hva så?

 

	/**
 * Registrerer en ny person i personregisteret.
 *
 * @param	 nyPerson   den nye personen som skal legges inn i personregisteret 
 * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
 */
public String leggTilPerson(Person nyPerson);

null skal faktisk returneres dersom ingen feil oppstår. Vel ... hva skal man si? Ingen steder i Collections returneres null ved suksess. Jeg forstår at studentene ikke kan exceptions, men å returnere null ved suksess er bare uintuitivt og misbruk av nullpekere. Det samme gjelder for mange andre metoder i grensesnittet.

Vel, enig i at man f.eks. kunne returnert en tom streng, men å klage på misbruk av null-pekere blir for dumt.

Det er klart og tydelig definert hvordan metodene skal fungere, og så fryktelig vrient er det ikke.

Og ja, det er nok for å unngå exceptions. Visse justeringer er man nødt til å gjøre.

 

	/**
 * Registrer en ny far eller ny mor for en person.
 *
 * @param	 person		 navn på person som får registrert ny far eller mor
 * @param	 nyFarEllerMor  navn på den nye faren eller moren
 * @param	 mor			angir om det er en ny far eller ny mor som skal registreres
 * @return	feilmelding som en string. Hvis ingen feil oppstår returneres null
 */
public String nyFarEllerMor(String person, String nyFarEllerMor, boolean mor);

Skal strengen person få en ny far- eller mor-streng? Tja ... ikke overbevisende, og ihvertfall ikke tilknyttet virkeligheten på noe som helst plan.

Ikke overbevisende? Hvis en person har registrert feil mor eller far skal dette kunne endres. Hva er problemet med det?

 

	/**
 * Finner helsøsken til en person. 
 *
 * @param	 navn		navn på person man skal finne helsøsken til
 * @return	helsøsken i et array. Hvis ingen helsøsken ble funnet returneres null
 */
public Person [] finnHelSosken(String navn);

Jeg ser jo her til min overraskelse at man skal returnere Person-objekter og ikke strenger, det er positivt. Hvorfor da må inputen være String navn og ikke Person person? Det samme gjelder alle tilsvarende metoder inkl. public boolean erSoskenbarn(String denEne, String denAndre);

Overaskende at Person-objekter returneres? Hvorfor? Hva er poenget ditt?

 

Når man ber om navn fra brukeren så leser man det inn fra tastaturet i form av tekst, representert i Java ved klassen String, ikke klassen Person.

Modellen (f.eks. database) har lagret dataene om hver person. Ber man om informasjon om en person fra en database lager man en query (altså en string), og returnerer så informasjonen i et passende objekt (Person). Alt som trengs er en string. Hvorfor man må sende med Person-objekter skjønner jeg ikke.

 

Jeg skjønner hvis du forsvarer oppgaven fordi den (liksom) skal være mer pedagogisk enn andre, men det er mye rart som må virke forvirrende for nye Java-ere. Du kan få komme med svar her hvis du vil, men hvis ikke du har noen direkte spørsmål, kommer jeg til å si meg ferdig med denne diskusjonen.

Forklar gjerne hva som «liksom» er problemet annet enn «uff, grensesnittet følger ikke navnkonvensjonen» og «uff, misbruker null-pekere».

Hva er det som er så forvirrende? Hva ville du gjort anderledes?

 

Beklager, men «eller at du bare ikke har programmert særlig mye» er bare stusselig.

 

Du får si deg så ferdig du bare vil. Det er du som mangler gode argumenter for dine påstander.

Hvorfor er denne oppgaven idiotisk?

[Bro2]

Jeg synes nesten synd på deg...

Nuvel, det skal du få slippe.

 

Men jeg må si, jeg tok en nærmere titt på grensesnittet man skal implementere i denne oppgaven. Det var såpass rotete og lite konvensjonelt at det ser ut til å være laget av en førsteårs-student og ikke en foreleser. Noe av poenget er jo å lære hvordan skrive god kode, ikke hvordan sause i hop alt og allverdens i Modell_grensesnitt. Og hvis man ønsker å lære bort objekt-orientering så er ikke dette grensesnittet et særlig godt eksempel.

Hva er rotete? Hva mener du med «sause i hop alt og allverdens i Modell_grensesnitt».

Enda en påstand uten substans? Begrunnelser pleier å være er fordel.

[Benbjo]

Jaja, jeg fikk godkjent oppgaven til tross for noen bugs (forventet det egentlig, bugsa altså).

 

Det er ikke jeg som har laget grensesnittet, men forelesere/gruppelærere. Vi ble bedt om å bruke dette. Klart har det en pedagogisk effekt når det er _først_ gang vi bruker MVC og grensesnitt. Ha litt forståelse når de aller fleste på kurset ikke har programmert noe annet enn INF1000, dvs et halvt års kjennskap til java.

 

Vi/jeg har også blitt bedt om å bruke norsk variabel navn. Hvorfor vet jeg nok ikke, men jeg gjør det jeg blir bedt om. Har ikke noe problem med å lage engelske variabelnavn. Tragisk å klage på dette hvertfall...

[Bro2]

Jaja, jeg fikk godkjent oppgaven til tross for noen bugs (forventet det egentlig, bugsa altså).

Gratulerer! Bra jobbet!

 

Det er ikke jeg som har laget grensesnittet, men forelesere/gruppelærere. Vi ble bedt om å bruke dette. Klart har det en pedagogisk effekt når det er _først_ gang vi bruker MVC og grensesnitt. Ha litt forståelse når de aller fleste på kurset ikke har programmert noe annet enn INF1000, dvs et halvt års kjennskap til java.

Erfaringen viser at denne oppgaven er meget effektiv til å lære hvordan MVC kan brukes (i alle fall hva som er tanken bak MVC) i forhold til tidligere år.

 

Vi/jeg har også blitt bedt om å bruke norsk variabel navn. Hvorfor vet jeg nok ikke, men jeg gjør det jeg blir bedt om. Har ikke noe problem med å lage engelske variabelnavn. Tragisk å klage på dette hvertfall...

Jeg tror dette kommer an på hver gruppelærer.

En grunn kan være at det er enklest hvis alle gjøre det samme.

 

Jeg kan godt si meg enig i at man kan bruke engelske variabelnavn, men at dette skal være et stort problem slik flere her påstår kan jeg ikke skjønne.

Det er tross alt stor forskjell på en obligatorisk oppgave og en oppgave der internasjonale programmerere skal samarbeide.

 

Håper du er i gang med Oblig 2.

Det er litt å jobbe med der også!

Endret 10. mars 2008 av Bro2

[Bro2]

Der var det slutt på svarene ja.

Interessant...

[Benbjo]

Hva mener du?

 

Klarte forresten oblig2 greit. Den var mye lettere enn Oblig 1

[Bro2]

Det er litt artig at med en gang jeg ber om et seriøst svar av de høyrøstede kritikerne, der de skal begrunne påstandene sine, så slutter de å svare...

 

Med en gang man skjønner hva oblig 2 går ut på så er den ikke så vanskelig.

Dessuten fikk dere det veldig enkelt med tanke på feiltesting

[steingrim]

Det må være fordi vi har snudd på flisa og funnet ut at denne oppgaven representerer det ypperste av objektorientering og Java-programmering.

 

Eller var det fordi man ikke gadd?

[Benbjo]

Det er litt artig at med en gang jeg ber om et seriøst svar av de høyrøstede kritikerne, der de skal begrunne påstandene sine, så slutter de å svare...

 

Med en gang man skjønner hva oblig 2 går ut på så er den ikke så vanskelig.

Dessuten fikk dere det veldig enkelt med tanke på feiltesting

 

Det kan godt være Lagde stort sett mine egne tester til jeg fikk de "offisielle" testene til å virke torsdag kveld før levering

[Bro2]

Det må være fordi vi har snudd på flisa og funnet ut at denne oppgaven representerer det ypperste av objektorientering og Java-programmering.

 

Eller var det fordi man ikke gadd?

Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

Det er kanskje ikke noe du er vant med...?

 

Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

Hvorfor har det da ennå ikke kommet seriøse argumenter?

 

Fra tidligere poster ser det i alle fall ikke ut til at det mangler engasjement....men men...hjem deg bak «nei, nå gidder jeg visst ikke» du.

Endret 21. mars 2008 av Bro2

[pgdx]

Det må være fordi vi har snudd på flisa og funnet ut at denne oppgaven representerer det ypperste av objektorientering og Java-programmering.

 

Eller var det fordi man ikke gadd?

Definitivt det førstnevnte. Jeg har brukt hele påsken på å refactore hele systemet på jobb nå til å følge Uio_konvensjoner. Lagrer all data i et Map<Map<Key, Value>, Value> og bruker strenger til alt.

[pgdx]

Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

Nja, ikke alltid det er verdt det. Man ser an sitt publikum. Enkelte er ikke mottakelig for konstruktiv kritikk.

Det er kanskje ikke noe du er vant med...?

Nice

Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

Hvorfor har det da ennå ikke kommet seriøse argumenter?

Fantastisk dårlig, ja ... Jeg tror vi har påpekt navnekonvensjoner og å bruke strenger for å representere en form for data. Du feide bort de og vi gav oss.

Fra tidligere poster ser det i alle fall ikke ut til at det mangler engasjement....men men...hjem deg bak «nei, nå gidder jeg visst ikke» du.

Nice. Du tar visst denne kritikken veldig personlig. Det er nok ikke det lureste man kan gjøre på et forum.

[Bro2]

Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

Nja, ikke alltid det er verdt det. Man ser an sitt publikum. Enkelte er ikke mottakelig for konstruktiv kritikk.

Nei det er riktig, spesielt ikke kritikk som er håpløs flisespikkeri. Jeg forventet faktisk noe seriøst fra dere.

 

Det er kanskje ikke noe du er vant med...?

Nice

 

Synes du virkelig det er rart at jeg setter spørsmålstegn ved dette?

Er det så fremmed å skulle begrunne sine påstander?

 

Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

Hvorfor har det da ennå ikke kommet seriøse argumenter?

Fantastisk dårlig, ja ... Jeg tror vi har påpekt navnekonvensjoner og å bruke strenger for å representere en form for data. Du feide bort de og vi gav oss.

Ja, og jeg finner det fullstendig tåpelig å konkludere med at oppgaven er idiotisk på grunn av dette.

Navnkonvensjoner har lite med oppgavens evne til å lære studentene programmering og objektorientering, noe som faktisk er målet med dette kurset.

Å lagre data som stringer er faktisk helt legitimt. Det kan ses på som å representere en database.

 

Fra tidligere poster ser det i alle fall ikke ut til at det mangler engasjement....men men...hjem deg bak «nei, nå gidder jeg visst ikke» du.

Nice. Du tar visst denne kritikken veldig personlig. Det er nok ikke det lureste man kan gjøre på et forum.

Det har nok mer med at jeg blir utrolig irritert over deres oppførsel.

Først slenge ut ubegrunnede påstander, og deretter unngå å begrunne dem på en seriøs måte.

Navnkonvensjoner og lagring av data som stringer er på ingen måte grunn nok til å konkludere med at oppgaven er idiotisk.

En ting som er verre enn å ta ting personlig er å ikke klare å begrunne sine påstander.

På et forum er det faktisk noe man pleier å gjøre.

 

Jeg skjønner at det er håpløst å forvente noe mer fra din kant i alle fall.

Det virker for meg som du tok deg vann over hode da du slang ut en bemerkning du ikke klarer å begrunne.

Ingenting er så lett som å kritisere, men å faktisk gi en god begrunnelse og forslag til hvordang gjøre forbedringer har du vel merket ikke er så enkelt.

[steingrim]

Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

Det er kanskje ikke noe du er vant med...?

Au da, min flåsete kommentar var helt unødvendig. Beklager

 

Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

Hvorfor har det da ennå ikke kommet seriøse argumenter?

Ok, så er navnekonvensjoner et teit argument. Å lære seg å skrive kode som andre kan lese kan man tidsnok gjøre senere. Det at koden blir MER forvirrende for en som kan Java driter vi selvsagt i. ("giPerson()", "Modell_grensesnitt" -- hallo?)

 

Men: hvis man først skal programmere objekt-orientert, hvorfor bruker man ikke da OBJEKTER?

public String registrerEkteskap(String mann, String kvinne);

Man har jo allerede Person-klassen, hvorfor ikke bruke den? Dette er gjennomgående i ca HALVPARTEN av oppgaven, man er ikke konsekvent.

 

Modell_grensesnitt ser ut som et grensesnitt for en slags collection av Person-objekter, et folkeregister. Men hvorfor har folkeregisteret metoder som fint kan og bør tilhøre Person-objekter, slik som finnSteSosken og finnHalvSosken? I tillegg synes jeg inn/ut bør skilles fra domene-spesifikk kode. "Bør" er for svakt. Skal vi leke MVC så SKAL det.

 

Jeg har forstått at man ikke skal lære bort exceptions så tidlig, så derfor skal jeg unngå å kommentere at feilhåndteringen ser ut å være skrevet av en gammel C-programmerer.

 

Som andre har påpekt, du ser ut til å ta det veldig personlig at oppgaven ikke nødvendigvis er den beste. Jeg har selv gått på UiO og tro meg; oppgavene var langt dårligere da (det var andre året man underviste i Java, ting var ikke helt på plass...). Men jeg ble ikke lei meg om noen bemerket det. Det bør ikke du bli heller.

Endret 22. mars 2008 av steingrim

[Zeph]

Emnetittelen i denne tråden er lite beskrivende for trådens innhold og det er derfor ingen god emnetittel. Jo bedre og mer beskrivende emnetittelen er, jo lettere er det for andre å skjønne trådens innhold og det vil være lettere å treffe den riktige forumbrukeren med det rette svaret. Ber deg derfor om å endre emnetittel slik at du unngår at en moderator stenger tråden. Vennligst forsøk å ha dette i tankene neste gang du starter en tråd, og orienter deg om hva vår nettikette sier om dårlig bruk av emnetitler.

 

Bruk -knappen i første post for å endre emnetittelen.

 

(Dette innlegget vil bli fjernet ved endring av emnetittel. Ikke kommenter dette innlegget, men gjerne dette innlegget når tittelen er endret, så vil det bli fjernet..)

[Bro2]

Ja, hvis man først gidder å komme med påstander, så gidder man kanskje å begrunne dem også?

Det er kanskje ikke noe du er vant med...?

Au da, min flåsete kommentar var helt unødvendig. Beklager

 

Hvis den er så fantastisk dårlig må det da være utrolig enkelt å kunne poengtere de største svakhetene burde det ikke?

Hvorfor har det da ennå ikke kommet seriøse argumenter?

Ok, så er navnekonvensjoner et teit argument. Å lære seg å skrive kode som andre kan lese kan man tidsnok gjøre senere. Det at koden blir MER forvirrende for en som kan Java driter vi selvsagt i. ("giPerson()", "Modell_grensesnitt" -- hallo?)

Hva er problemet med metodenavnet "giPerson"?

 

Men: hvis man først skal programmere objekt-orientert, hvorfor bruker man ikke da OBJEKTER?

public String registrerEkteskap(String mann, String kvinne);

Man har jo allerede Person-klassen, hvorfor ikke bruke den? Dette er gjennomgående i ca HALVPARTEN av oppgaven, man er ikke konsekvent.

Her er jeg tildels enig.

leggTilPerson(Person nyPerson); burde tatt imot tre strenger.

Navn, mor og far.

 

Grunnen til at strenger faktisk er legitimt her er at modellklassen kan representere en database der dataene lagres som strenger og ikke objekter.

Dette er en vurderingssak, som ikke har noe fasitsvar synes jeg.

 

Modell_grensesnitt ser ut som et grensesnitt for en slags collection av Person-objekter, et folkeregister. Men hvorfor har folkeregisteret metoder som fint kan og bør tilhøre Person-objekter, slik som finnSteSosken og finnHalvSosken? I tillegg synes jeg inn/ut bør skilles fra domene-spesifikk kode. "Bør" er for svakt. Skal vi leke MVC så SKAL det.

Person-objektenes ansvar er å representere en person og dens forhold til andre personobjekter.

Databasen vil ha ansvaret for å skaffe dataene som kontrollen har behov for.

 

MVC er et "architectural pattern" og går kort og godt ut på å gi en pekepinn på hvordan kontrolldelen og datadelen og "view"-delen av et program skal gøres adskilt.

 

Person-klassen brukes kun som en praktisk lagring av dataene som programmet kan bruke.

Den er ikke en direkte del av MVC i denne oppgaven.

 

Jeg har forstått at man ikke skal lære bort exceptions så tidlig, så derfor skal jeg unngå å kommentere at feilhåndteringen ser ut å være skrevet av en gammel C-programmerer.

Ja, jeg er enig i dette, men som du poengterer ganske riktig så skal ikke Exceptions være en del av denne oppgaven.

 

Som andre har påpekt, du ser ut til å ta det veldig personlig at oppgaven ikke nødvendigvis er den beste. Jeg har selv gått på UiO og tro meg; oppgavene var langt dårligere da (det var andre året man underviste i Java, ting var ikke helt på plass...). Men jeg ble ikke lei meg om noen bemerket det. Det bør ikke du bli heller.

Ja, da jeg gjorde oppgaven var den sikkert omtrent som da du gjorde den, og ikke spesielt ryddig selv om målet med oppgaven fortsatt er det samme.

 

Jeg siterer det jeg skrev tidligere:

 

Det har nok mer med at jeg blir utrolig irritert over deres oppførsel.

Først slenge ut ubegrunnede påstander, og deretter unngå å begrunne dem på en seriøs måte.

Navnkonvensjoner og lagring av data som stringer er på ingen måte grunn nok til å konkludere med at oppgaven er idiotisk.

En ting som er verre enn å ta ting personlig er å ikke klare å begrunne sine påstander.

På et forum er det faktisk noe man pleier å gjøre.

Jeg kan godt være enig i at oppgaven er et forbedringspotensiale, men jeg skjønner fortsatt ikke at det er mulig å konkludere med at denne oppgaven er idiotisk på bakgrunn av punktene som poengteres.

 

Takk for et seriøst svar, noe jeg observerer at pgdx fortsatt unngår å komme med.

[Bro2]

Emnetittelen i denne tråden er lite beskrivende for trådens innhold og det er derfor ingen god emnetittel. Jo bedre og mer beskrivende emnetittelen er, jo lettere er det for andre å skjønne trådens innhold og det vil være lettere å treffe den riktige forumbrukeren med det rette svaret. Ber deg derfor om å endre emnetittel slik at du unngår at en moderator stenger tråden. Vennligst forsøk å ha dette i tankene neste gang du starter en tråd, og orienter deg om hva vår nettikette sier om dårlig bruk av emnetitler.

 

Bruk -knappen i første post for å endre emnetittelen.

 

(Dette innlegget vil bli fjernet ved endring av emnetittel. Ikke kommenter dette innlegget, men gjerne dette innlegget når tittelen er endret, så vil det bli fjernet..)

 

Jeg er enig i at tittelen ikke er spesielt utfyllende eller gir godt innblikk i hva dette handler om, men det er lite jeg kan gjøre med dette.

Kan ikke du endre den til noe sånt som "Problem med stebarn i en oppgave. Kvaliteten på oppgaven?"