Permalänk
Medlem

Namnge scannerobjektet i java?

Efter att jag fått bakläxa då jag använde input som namn på mitt objekt så blev jag lite nyfiken på hur andra väljer att namnge objektet? Jag funderade på att använda Kenneth som namn i fortsättningen? Ni som jobbar med programmering föredrar ni Kenneth framför input som namn?

Permalänk
Medlem

sc har jag sett och använt ...

Permalänk
Medlem

Om det bara finns en instans av Scanner i sammanhanget: scanner (jag kan sträcka mig till sc om objektet aldrig används mer än ett par rader efter deklaration, men tecken är ändå gratis så varför vara otydlig i onödan?)
Varför döpa den till något den inte är?

Visa signatur

Spela Swemantle! Du vet att du vill.

Ibland har jag fel, men då är det någon annans fel.

Permalänk
Medlem
Skrivet av LemonIllusion:

Om det bara finns en instans av Scanner i sammanhanget: scanner (jag kan sträcka mig till sc om objektet aldrig används mer än ett par rader efter deklaration, men tecken är ändå gratis så varför vara otydlig i onödan?)
Varför döpa den till något den inte är?

Både i läroboken och materialet som skolan tillhandahåller kallas den input. Därför kallade jag också den för input.

I rättningen stod följande

"Språket har reserverat ord, nyckelord namna inte variabler med samma namn då sker förväxlingar för den som läser koden och inte skrivit den. Undvik variabelnamn som scanner, date, in, input osv."

Permalänk
Medlem

@SexMachine:
Tyvärr verkar du ha en lärare som själv inte ens kan grunderna i Java. Inget av orden som räknas upp är reserverade nyckelord. Behövr du en referens så kan du hänvisa till JLS (Java Language Specifitication) 3.9

Skriver läraren "namna inte variabler"?

Vad är det för utbildning du går? Finns det möjlighet att byta klass?

scanner är ett bra namn.

Permalänk
Medlem

Stor humor på den läraren 😅 "scan" eller "sc" brukar jag använda men scanner eller input funkar också

Skickades från m.sweclockers.com

Permalänk
Medlem
Skrivet av jclr:

@SexMachine:
Tyvärr verkar du ha en lärare som själv inte ens kan grunderna i Java. Inget av orden som räknas upp är reserverade nyckelord. Behövr du en referens så kan du hänvisa till JLS (Java Language Specifitication) 3.9

Skriver läraren "namna inte variabler"?

Vad är det för utbildning du går? Finns det möjlighet att byta klass?

scanner är ett bra namn.

Japp det är ett citat av min feedback. Fick även följande

"inga värden/beräkningar i utskrifterna ska gå via konstanter/variabler"

Jag hade multiplicerat lön och antalet jobbade minuter i utskriften. Dessa 2 sakerna ger dom mig en komplettering på!?! Inte ett tänk på detta till nästa gång. 3 sura minuter av mitt liv måste jag slösa på att komplettera detta.

Fast redan när dom krävde att man skulle använda 3 space istället för tab som indentering borde jag förstått att det kommer bli en sträng kurs.

Jag läser en introduktionskurs på distans i java på LTU. Har inte möjlighet att byta och läser mest för att jag behöver poängen för att få tillbaka mitt CSN.

Permalänk
Medlem

Nu kom nästa feedback in.

*använd konstanter(inte variabler/värden) för i förväg fasta kända värden som inte beräknas/ ändras, namnsätts med versaler.

Kodraden som refererades till är följande

while (length < 1 || length > 26);

med en pil över siffran 26. användaren ska mata in ett tal mellan 1 & 26.

Permalänk
Medlem
Skrivet av SexMachine:

Nu kom nästa feedback in.

*använd konstanter(inte variabler/värden) för i förväg fasta kända värden som inte beräknas/ ändras, namnsätts med versaler.

Kodraden som refererades till är följande

while (length < 1 || length > 26);

med en pil över siffran 26. användaren ska mata in ett tal mellan 1 & 26.

Det är väl rimligt. Varför har du invändning mot det?

Permalänk
Medlem
Skrivet av SexMachine:

Nu kom nästa feedback in.

*använd konstanter(inte variabler/värden) för i förväg fasta kända värden som inte beräknas/ ändras, namnsätts med versaler.

Kodraden som refererades till är följande

while (length < 1 || length > 26);

med en pil över siffran 26. användaren ska mata in ett tal mellan 1 & 26.

Detta var ju mer vettig feedback! Att använda namngivna konstanter istället för magiska nummer är väldigt bra för att öka läsbarhet och göra koden mer refaktoreringsvänlig.

Tänk dig till exempel att vi skriver en lösenordsvaliderare. Om vi använder magiska nummer skulle det kunna se ut såhär:

if (length(pw) > 3 && length(pw) < 16) { return; // Ok! } else if (length(pw) < 16) { throw new Exception("Password too short!"); } else { throw new Exception("Password too long!"); }

Ovan kod validerar alltså att lösenordet är 3 till 16 tecken långt. Tänk nu att våra krav uppdateras, och lösenord får nu vara upptill 20 tecken långa. Vi uppdaterar koden:

if (length(pw) > 3 && length(pw) < 20) { // <------ uppdaterat till 20 return; // Ok! } else if (length(pw) < 16) { // <--------- missade att uppdatera från 16 throw new Exception("Password too short!"); } else { throw new Exception("Password too long!"); }

Men oj, nu uppdaterade vi bara maxgränsen i det första villkoret, men råkade missa det andra, så vi har en bugg! Här hade en namngiven konstant hjälpt, eftersom vi då bara behövt ändra maxgränsen på ett enda ställe, men det skulle reflekteras i hela kodbasen, i.e. i båda villkoren.

Ett annat problem med magiska nummer är att det kan vara oklart vad de betyder. I just detta fallet kanske det är uppenbart att det handlar om undre och övre gräns för lösenordslängd, men det finns absolut scenarier där det inte alls är lika klart, och ett namn hade hjälpt betydligt.

Slutligen, ett exempel på hur lösenordsvalideringen hade förbättrats med konstanter:

final unsigned PASSWORD_MIN_LENGTH = 3; final unsigned PASSWORD_MAX_LENGTH = 16; void validatePassword(String pw) { if (length(pw) > PASSWORD_MIN_LENGTH && length(pw) < PASSWORD_MAX_LENGTH) { return; } else if (length(pw) < PASSWORD_MAX_LENGTH) { throw new Exception("Password too short!"); } else { throw new Exception("Password too long!"); } }

Edit: Obs: Jag uppmuntrar inte maxlängdskrav på lösenord -- det var bara ett exempel

Visa signatur

Arbets- / Spelstation: Arch Linux - Ryzen 5 3600 - RX 7900 XT - 32G DDR4
Server: Arch Linux - Core i5-10400F - 16G DDR4

Permalänk
99:e percentilen
Skrivet av SexMachine:

"Språket har reserverat ord, nyckelord namna inte variabler med samma namn då sker förväxlingar för den som läser koden och inte skrivit den. Undvik variabelnamn som scanner, date, in, input osv."

Detta är ju helt felaktigt från lärarens sida. Om det är något som kännetecknar reserverade ord (och de flesta nyckelord, i typ alla moderna språk) så är det att det inte går att använda dem som namn. Att ens försöka är ett parse error.

Förtydligande.
Visa signatur

Skrivet med hjälp av Better SweClockers

Permalänk
Hedersmedlem
Skrivet av Alling:

Detta är ju helt felaktigt från lärarens sida. Om det är något som kännetecknar reserverade ord (och nyckelord, i typ alla moderna språk) så är det att det inte går att använda dem som namn. Att ens försöka är ett parse error.

Läraren är ju inte fel att uppmana att undvika namnen, sen kanske motivering är lite felriktad. Det är ju inte så att man alltid kompilerar koden som man läser heller så helt fel är det inte att det kan ske missförstånd.

Permalänk
99:e percentilen
Skrivet av Shimonu:

Läraren är ju inte fel att uppmana att undvika namnen, sen kanske motivering är lite felriktad. Det är ju inte så att man alltid kompilerar koden som man läser heller så helt fel är det inte att det kan ske missförstånd.

Tja, jag vet inte … det får nog ändå ligga på varje programmerares ansvar att se till att kod han eller hon delar med sig av (så att någon kan läsa den) åtminstone är fri från parse errors. Att uppmana till att "undvika" reserverade ord som identifierare känns ungefär som att uppmana till att "undvika" omatchande parenteser.

Att som lärare betona rollen som reserverade ord har är ju däremot viktigt. Men då duger det ju inte att som exempel ta fyra namn som inte är reserverade ord i Java (scanner, date, in, input) och dessutom är utmärkta namn att använda.

Men vi kanske menar samma sak egentligen.

Visa signatur

Skrivet med hjälp av Better SweClockers