Gr0v Skrevet 27. september 2007 Del Skrevet 27. september 2007 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
Gr0v Skrevet 27. september 2007 Forfatter Del Skrevet 27. september 2007 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
Haraldson Skrevet 27. september 2007 Del Skrevet 27. september 2007 (endret) 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 27. september 2007 av Haraldson Lenke til kommentar
Gr0v Skrevet 27. september 2007 Forfatter Del Skrevet 27. september 2007 Takk skal du ha=) Betyr .* etter JOptionPane øverst at jeg ikke trenger skrive JOptionPane foran f.eks showMessageDialog? Lenke til kommentar
Haraldson Skrevet 27. september 2007 Del Skrevet 27. september 2007 Stjernen betyr at du importerer alt som ligger innenfor JOP-biblioteket. Hadde du skrevet import javax.swing.*; hadde JOP fortsatt fungert, men du hadde hatt enda større muligheter. Vær dog litt tilbakeholden med å bruke * - å importerte masse unødvendig betyr også mer belastning på PC og dårligere ytelse. Lenke til kommentar
pgdx Skrevet 27. september 2007 Del Skrevet 27. september 2007 Vær dog litt tilbakeholden med å bruke * - å importerte masse unødvendig betyr også mer belastning på PC og dårligere ytelse.På tross av at jeg aldri har foretatt noen dypere studier av emnet så tror jeg nok at Java-kompilatoren er smartere enn det. Lenke til kommentar
Haraldson Skrevet 27. september 2007 Del Skrevet 27. september 2007 Ikke ifølge det jeg har lært, dog skal det ikke ha mye innvirkning. Lenke til kommentar
pgdx Skrevet 27. september 2007 Del Skrevet 27. september 2007 Ikke ifølge det jeg har lært, dog skal det ikke ha mye innvirkning.Okey ... Bummer! Lenke til kommentar
steingrim Skrevet 28. september 2007 Del Skrevet 28. september 2007 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
LostOblivion Skrevet 28. september 2007 Del Skrevet 28. september 2007 Dog; det er ikke en bra praksis å importere hele pakker, men det er jo en annen sak smile.gif Jepps, enig, da er man faktisk klar over hva man bruker og da hvor de ligger. Lenke til kommentar
blackbrrd Skrevet 30. september 2007 Del Skrevet 30. september 2007 (endret) 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 classCurrency. 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 30. september 2007 av blackbrrd Lenke til kommentar
FourEyes Skrevet 4. oktober 2007 Del Skrevet 4. oktober 2007 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
DarkSlayer Skrevet 4. oktober 2007 Del Skrevet 4. oktober 2007 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
blackbrrd Skrevet 4. oktober 2007 Del Skrevet 4. oktober 2007 (endret) 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 4. oktober 2007 av blackbrrd Lenke til kommentar
emva Skrevet 4. oktober 2007 Del Skrevet 4. oktober 2007 på skolen min der gikk vi ifra notepad til blueJ till Eclipse. Lenke til kommentar
pgdx Skrevet 5. oktober 2007 Del Skrevet 5. oktober 2007 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
Anbefalte innlegg
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 kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå