Gå til innhold

Hva er galt med denne koden?


Anbefalte innlegg

Hva er galt med denne koden? Får følgende feilmelding:

C:\Skolearbeid\Javaprogrammer\Kvotientberegning1.java:10: invalid method declaration; return type required

showMessageDialog(null, "Kvotienten til tallene er " + kvotient);

^

C:\Skolearbeid\Javaprogrammer\Kvotientberegning1.java:10: illegal start of type

showMessageDialog(null, "Kvotienten til tallene er " + kvotient);

^

C:\Skolearbeid\Javaprogrammer\Kvotientberegning1.java:13: class, interface, or enum expected

}

^

3 errors

 

 

import static javax.swing.JOptionPane;

class Kvotientberegning1 {

public static void main(String[]args);

String førsteheltallLest = JOptionPane.showInputDialog("skriv inn første tall");

public static void main(String[]args);

String andreheltallLest = JOptionPane.showInputDialog("skriv inn andre tall");

int førstetall = Integer.parseInt(førsteheltallLest);

int andretall = Integer.parseInt(andreheltallLest);

int kvotient = førstetall/andretall;

JOptionPane.showMessageDialog(null, "Kvotienten til tallene er " + kvotient);

 

}

}

 

 

Satan, java er et frustrerende fag

Lenke til kommentar
Videoannonse
Annonse

Sånn ser forresten koden ut nå:

 

import static javax.swing.JOptionPane.*;

class Kvotientberegning1 {

public static void main(String[]args);

String førsteheltallLest = showInputDialog("skriv inn første tall");

public static void main(String[]args);

String andreheltallLest = showInputDialog("skriv inn andre tall");

int førstetall = Integer.parseInt(førsteheltallLest);

int andretall = Integer.parseInt(andreheltallLest);

int kvotient = førstetall/andretall;

showMessageDialog(null, "Kvotienten til tallene er " + kvotient);

 

}

}

Lenke til kommentar
import static javax.swing.JOptionPane.*;

class Kvotientberegning1 {
public static void main(String[] args) {
 
 String førsteheltallLest = showInputDialog("skriv inn første tall");
 String andreheltallLest = showInputDialog("skriv inn andre tall");

 int førstetall = Integer.parseInt(førsteheltallLest);
 int andretall = Integer.parseInt(andreheltallLest);
 int kvotient = førstetall/andretall;
 
 showMessageDialog(null, "Kvotienten til tallene er " + kvotient);
}
}

Endret av Haraldson
Lenke til kommentar
Vær dog litt tilbakeholden med å bruke * - å importerte masse unødvendig betyr også mer belastning på PC og dårligere ytelse.

Tullball.

 

Java benytter seg av runtime linking. Et import-statement sier bare hvor kompilatoren skal finne en type og påvirker derfor bare kompileringen. Eventuell overhead er neglisjerbart og noe man helt sikkert ikke merker under kompilering.

 

Runtime har det null og niks å si.

 

Dog; det er ikke en bra praksis å importere hele pakker, men det er jo en annen sak :)

Lenke til kommentar

Personlig bruker jeg gjerne import statements som denne:

 

import java.util.*;

 

istedetfor å skrive:

 

import java.util.Arrays;

import java.util.Vector;

import java.util.HashMap;

import java.util.LinkedList;

import java.util.Collection;

 

Jeg ser ikke helt poenget med å importere en og en klasse når du skal bruke flere av klassene i pakken. Jeg skriver max en import statement pr pakke, så hvis jeg har flere klasser jeg skal bruke pr pakke bruker jeg wildcard.

 

PS: hvis du støter borti at du har to klasser med samme navn fra to pakker så kan du eksplisitt importere den ene klassen du skal bruke, mao:

 

import java.util.*;

import java.sql.*;

import java.util.Date;

 

(Date klassen finnes i begge, nå vil java.util.Date bli brukt)

 

Det er en grunn til at at du kan bruke wildcard...

 

Det som derimot kan finne på å bli problematisk er hvis du overtar kode som har importert en mer eller mindre obskur klasse fra et bibliotek du ikke har i class-pathen. Da kan det bli litt klønete å finne hvilken jar-fil du mangler...

 

Som nevnt tidligere i tråden så er det nok ingen best practice å bruke wildcard, grunnen er at det kan bli vanskeligere å lese koden. - ikke om jeg er helt enig der men. Det som er mer problematisk er det jeg kom over på ett annet forum:

 

Some long time ago I worked in a project that had it's own class

Currency. Then came JDK 1.4 and it's new class java.util.Currency. And

of course there were "import java.util.*" everywhere. We had to fix a

few hundert source files.

 

We used a script for that task (thanks sed), but it wasn't nice.

 

I think, with modern Java IDEs managing imports almost automatically,

there is no sound reason for using wildcard imports anymore.

 

Må medgi [email protected] fra http://www.velocityreviews.com/forums/t369...-statement.html hadde ett poeng der ;)

 

Som igjen får meg til igjen å si man burde begynne med ett moderne Java IDE med en gang man lærer å programmere. Noen vil kanskje si at man burde begynne i notepad, men jeg vil påstå at det er som å begynne å lære opp en bilmekaniker uten de riktige verktøyene.

Endret av blackbrrd
Lenke til kommentar
Som igjen får meg til igjen å si man burde begynne med ett moderne Java IDE med en gang man lærer å programmere. Noen vil kanskje si at man burde begynne i notepad, men jeg vil påstå at det er som å begynne å lære opp en bilmekaniker uten de riktige verktøyene.

9605642[/snapback]

 

Må si meg uenig i det. mener det er bedre å starte med notepad (helst notepad ++) for å lære seg det helt basice for så å gå over til et IDE etter en liten stund.

 

Vil sammenligne det å starte rett på et IDE som å lære opp en mekaniker ved å gi han en ekstremt detaljert oversikt over en motor og ønske han lykke til. Avhenger sikkert litt av IDE men ivertfall Eclipse slenger veldig mye informasjon rett i fjeset på deg som kan være veldig skremmende

Lenke til kommentar
Som igjen får meg til igjen å si man burde begynne med ett moderne Java IDE med en gang man lærer å programmere. Noen vil kanskje si at man burde begynne i notepad, men jeg vil påstå at det er som å begynne å lære opp en bilmekaniker uten de riktige verktøyene.

9605642[/snapback]

 

Veldig veldig veldig uenig.

 

Greit notepad skal jeg være enig i at suger. Notepad++ er greit nok.

 

IDE skjuler mange detaljer, og det er ikke bra i læringsøyemed. Dessuten for total noobs som skal progge if/else, for while switch, funksjoner etc så gjelder det å holde alt nytt på et minimum.

 

Begynner man med verktøy som intellisense, verktøy for å lage objekter, verktøy for debugging etc etc så får du bare for mye "drit i dette, du lærer det senere".

 

Nybegynnere har enorme problemer med å forstå en enkel consol input med if/else. Forskjell på int og char, og dynamiske variabler som i python/php. Eller pekere i java.

 

IDE kan du begynne med når du forstår gangen i ting, forstår basic kode og tiden er moden for å gå videre. Det trenger ikke være mer enn etter f.eks 4-6mnd fra du var totalt noob.

Lenke til kommentar

Tror dere ser på andre ting enn jeg gjør i en IDE i læringsøyemed.

 

Poenget med en god IDE er at den:

- Sier ifra med en gang du har skrevet ulovlig kode (rød understreking med forklaring ved mouse-over)

- Kan indente koden din automatisk så den er lettere å lese (nybegynnere sliter med dette)

- Du kan enkelt teste koden din mens du utvikler

- Det er lett å lese context-relativ dokumentasjon, f.eks javadoc

- Fargekoding

 

Jeg mente ikke at du skulle bruke wizard tingene til å begynne med, men å kunne konsentrere seg om selve kodingen istedetfor å slite med verktøy som ikke henger sammen (kompilering i et program, kjøring i et annet program og et program for redigering).

 

Notepad++ er den dårligste programmet jeg kunne finne på å få noen til å jobbe i.

Notepad med sin manglende fargekoding er rett og slett forferdelig å kode i.

 

Personlig liker jeg JBuilderene som kom før den var basert på Eclipse

Utenom det så bruker jeg Eclipse (det har støtte for flere "språk" som JSF)... Triste greier egentlig, JBuilder er mye mer strømlinjeformet, spesiellt når det gjelder å klare å bruke /¤"/( programmet.

Endret av blackbrrd
Lenke til kommentar

Er enig med DarkSlayer. Man bør begynne med en ren teksteditor, selvsagt med syntax highlighting. Man bør lære seg å tolke feilmeldinger fra kompilatoren og å skrive ting uten auto-completion! Man bør stresse litt med pakkenavn og hvordan man skriver en klasse helt fra en tom fil, inkludert import-setninger og interface/klasser den implementerer/arver fra.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...