---

Hejsa,

Vi er i øjeblikke ved at lave en code convension til brug ved java udvikling
og vi baserer det på suns udgave.

Nu er der kommet forslag om at navngive variabler med type først. ex.
intKundeNummer - strNavn osv.

Jeg er ikke tilhænger af dette, men savner nogle gode argumenter?

Jeg mener det ødelægger overblikket, og det giver ikke nogen gavnlig effekt
alligevel. ex. :
Hvis du har erklæret en variable i din metode:

int internalRequisitionNumber = 0;

..... kode ....

og her skal du bruge den.

Nu kan du huske navnet på variablen men ikke typen?

Men som sagt, jeg savner nogle argumenter - nogen der har nogen?

På forhånd tak.

Karsten Mandrup Nielsen

---

Karsten Mandrup Nielsen skrev:

>Nu kan du huske navnet på variablen men ikke typen?

Øh ... er det så ikke lidt farligt/vanskeligt at skrive kode der
håndterer den?

>Men som sagt, jeg savner nogle argumenter - nogen der har nogen?

Jeg har ikke nogen mening om den sag ud over at det ikke er så
fikst at indføre en særlig firmastandard hvis folk alligevel skal
kunne læse fremmed kode - og hvem skal ikke det?

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Jeg har ikke nogen mening om den sag ud over at det ikke er så
> fikst at indføre en særlig firmastandard hvis folk alligevel skal
> kunne læse fremmed kode - og hvem skal ikke det?

Jeg mener at man sparer en stor mængde kræfter hvis alle udviklere -
måske ikke i et helt firma, men så på et projekt - laver ens kode. Man
læser bedst sin egen måde at skrive på.

Men det er selvfølgelig korrekt, at man skal kunne læse andres kode
også. Det må jo så være Sun's grund til at udarbejde deres 'code
conventions'.

-dennis

---

Dennis Thrysøe skrev:

>Jeg mener at man sparer en stor mængde kræfter hvis alle udviklere -
>måske ikke i et helt firma, men så på et projekt - laver ens kode.

Helt enig. Jeg argumenterer blot for at det er smartest hvis den
ligner den 'officielle' standard.

--
Bertel
http://lundhansen.dk/bertel/   FIDUSO: http://fiduso.dk/

---

Karsten Mandrup Nielsen wrote:
> Men som sagt, jeg savner nogle argumenter - nogen der har nogen?

Redundans.

Typen og identiten af en variabel bør efter min mening ikke have noget
med hinanden at gøre. F.eks. er det lidt ufikst at skulle ændre både
typerne og navnene rundt omkring ved en refactoring der kræver en
ændring af typen for en variabel.

Dit eget eksempel med kundenummer kunne i forskellige sammenhænge
udtrykkes som Integer, int, long, String, CustomerNumber, etc. Denne
udvikling bør man næsten forvente i alle større systemer.


-dennis

---

Jeg er enig. Det giver ingen mening at lade typen indgå i identifieren,
da typen kan castes og derved være forskellig i forskellige
sammenhænge - det er jo netop een af fordelene ved polymorfi.

Undtagelsen er selvfølgeligt de primitive typer, men selv de kan jo ved
hjælp af wrapper klasser antage forskellige former.

/Lars

"Dennis Thrysøe" <dt@netnord.dk> skrev i en meddelelse
news:3C7F6316.7030402@netnord.dk...
> Karsten Mandrup Nielsen wrote:
> > Men som sagt, jeg savner nogle argumenter - nogen der har nogen?
>
> Redundans.
>
> Typen og identiten af en variabel bør efter min mening ikke have noget
> med hinanden at gøre. F.eks. er det lidt ufikst at skulle ændre både
> typerne og navnene rundt omkring ved en refactoring der kræver en
> ændring af typen for en variabel.
>
> Dit eget eksempel med kundenummer kunne i forskellige sammenhænge
> udtrykkes som Integer, int, long, String, CustomerNumber, etc. Denne
> udvikling bør man næsten forvente i alle større systemer.
>
>
> -dennis
>

---

On Fri, 1 Mar 2002 11:28:41 +0100, "Karsten Mandrup Nielsen"
<kmn@logimatic.dk> wrote:

>Hejsa,
>
>
>Jeg mener det ødelægger overblikket, og det giver ikke nogen gavnlig effekt
>alligevel. ex. :
>Hvis du har erklæret en variable i din metode:
>
>int internalRequisitionNumber = 0;
>
>.... kode ....
>
>og her skal du bruge den.
>
>Nu kan du huske navnet på variablen men ikke typen?
>
>Men som sagt, jeg savner nogle argumenter - nogen der har nogen?

At det klart er en dårlig ide; det giver tendens til at bruge typen
som undskyldning for at finde på et godt og sigende variabel navn. Det
burde altid være muligt at finde et fornuftigt variabel navn, som
fortæller mere om indholdet, end typen af indholdet.

Der hvor jeg arbejder har vi lige startet et kr. 20 mill projekt, med
java som udgangspunkt - vores standard forbyder brug af hungarian,
eller lignende notationer, med bl.a. ovenstående som argument.

>På forhånd tak.
>
>Karsten Mandrup Nielsen

vh. ld

---

> >Men som sagt, jeg savner nogle argumenter - nogen der har nogen?
>
> At det klart er en dårlig ide; det giver tendens til at bruge typen
> som undskyldning for at finde på et godt og sigende variabel navn. Det
> burde altid være muligt at finde et fornuftigt variabel navn, som
> fortæller mere om indholdet, end typen af indholdet.
>
> Der hvor jeg arbejder har vi lige startet et kr. 20 mill projekt, med
> java som udgangspunkt - vores standard forbyder brug af hungarian,
> eller lignende notationer, med bl.a. ovenstående som argument.

Brug engelsk og sigende variable navne, og drop typen foran, det giver ingen
fornuftig information.

Og tænk på et langt navn: simpleDateFormatterDato, lidt vildt ikke ?


--
With many Thanks
Soren ' Disky ' Reinke ICQ #1413069 remove 'ihsyd' when email replying
Please visit my Freshwater Aquaria Webpage
http://www.disky-design.dk/fish

---

"Karsten Mandrup Nielsen" <kmn@logimatic.dk> wrote
> Hejsa,
>
> Vi er i øjeblikke ved at lave en code convension til brug ved java
udvikling
> og vi baserer det på suns udgave.
>
> Nu er der kommet forslag om at navngive variabler med type først. ex.
> intKundeNummer - strNavn osv.
>
> Jeg er ikke tilhænger af dette, men savner nogle gode argumenter?

Hejsa der...
Det var dog en tåbelig navngivnings ide om jeg må være så fri.

Og argumenter imod:
1) Man bør altid så vidt muligt i navngivning af variable, klasser, metoder
osv, holde sig til problem-området. Det skaber kun forvirring og fjerner
fokus når man bruger datalogiske betegnelser som linkedObjectList istedet
for kundeListe og printerStatusFlag istedet for printerReady.

2) Alle moderne udviklingsværktøjer (og der findes sikkert også nogle
scripts til Emacs) kan lynhurtigt fortælle hvilken type en variabel er, og
man kan som regel også se det i Structure-træet i venstre side af ens IDE


3) Sålænge systemet kører i Danmark er det sikkert meget sjovt med
intPostNummer, men når det så også skal benyttes i England, hvor postnumre
jo er tekst-strenge, så er det irriterende at skulle ændre alle
intPostNummer til stringPostNummer (det kan nemt klares med refactoring, men
husker man at gøre det ? Og hvorfor spilde sit liv på at lede efter
compilerfejl når man ikke kan (int)intPostNummer ?)

4) int, long og så videre er selvfølgelig nemt nok, men hvad nu når det er
f.eks en JCheckBoxMenuItem der kan vælge mellem HTML og PlainText, men den
bliver leveret af en factory, der leverer generelle JMenuItems, som man så
typecaster ? Hvad skal sådan en fætter hedde ? Skal det være en
(JCheckBoxMenuItem)jcheckboxmenuitemHTMLorPlainText eller en
(JCheckBoxMenuItem)jmenuitemHTMLorPlainText ?
Eller hvis man ønsker at behandle alle JComponents ens ? Hvad skal de så
hedde ? Bare det at man overhovedet skal bruge tid på at tænke over det,
viser at man har valgt en forkert navne-konvention.

5) Hvis man endelig vil angive typen af en variabel, f.eks om det er en
liste, en connector, en tabel, et indtastningsfelt eller sådan noget, så er
kotymen at man angiver det i slutningen af navnet. Feks JFormattedTextField,
customerList, databaseConnector og videre i den stil.

Sig endelig til hvis du skal bruge flere argumenter, jeg skal også gerne
komme og holde et foredrag

Hvis du vil have mere vægtige ord bag dig, så vil jeg henvise til Steve
McConnell: "Code Complete", ISBN 1-55615-484-4. Kapitel 9 handler
udelukkende om navngivning. Det har også et afsnit om Hungarian Naming
Convention, som jeg allerhelst så fjernet fra jordens overflade.

mvh
Peter Lind

PS: En anden skribent foreslog at man holdt sig til engelske variabelnavne.
Jeg er ikke helt enig. Der er ikke noget som helst galt i danske
variabelnavne, så længe ALLE variabelnavne er i det samme sprog, og
STØRSTEDELEN af metodenavnene ligeså. Og da java understøtter æ,ø og å, så
lad være med at finde på ting som saetSideHoejde, men brug sætSideHøjde.
Problemet ved danske metodenavne er at get og set ikke rigtigt lader sig
oversætte...

---

>
> PS: En anden skribent foreslog at man holdt sig til engelske
variabelnavne.
> Jeg er ikke helt enig. Der er ikke noget som helst galt i danske
> variabelnavne, så længe ALLE variabelnavne er i det samme sprog, og
> STØRSTEDELEN af metodenavnene ligeså. Og da java understøtter æ,ø og å, så
> lad være med at finde på ting som saetSideHoejde, men brug sætSideHøjde.
> Problemet ved danske metodenavne er at get og set ikke rigtigt lader sig
> oversætte...

Jeg tænkte big case, altså projekter hvor der ikke kun er danske udviklere.

Derfor engelske navne.

Ellers har du helt ret.
--
With many Thanks
Soren ' Disky ' Reinke ICQ #1413069 remove 'ihsyd' when email replying
Please visit my Freshwater Aquaria Webpage
http://www.disky-design.dk/fish

---

Peter Lind <peterlind@hotmail.com> wrote:

> Hvis du vil have mere vægtige ord bag dig, så vil jeg henvise til Steve
> McConnell: "Code Complete", ISBN 1-55615-484-4. Kapitel 9 handler
> udelukkende om navngivning. Det har også et afsnit om Hungarian Naming
> Convention, som jeg allerhelst så fjernet fra jordens overflade.

Nu er det anden gang det bliver nævnt på kort tid... hvad er
'Hungarian Naming Convention' egentlig?

Venlig hilsen
--
Max

---

On Sun, 3 Mar 2002 01:16:07 +0100, Max Rotvel <rotvel@mail.dk> wrote:

>Peter Lind <peterlind@hotmail.com> wrote:
>
>> Hvis du vil have mere vægtige ord bag dig, så vil jeg henvise til Steve
>> McConnell: "Code Complete", ISBN 1-55615-484-4. Kapitel 9 handler
>> udelukkende om navngivning. Det har også et afsnit om Hungarian Naming
>> Convention, som jeg allerhelst så fjernet fra jordens overflade.
>
>Nu er det anden gang det bliver nævnt på kort tid... hvad er
>'Hungarian Naming Convention' egentlig?

En navne standard brugt meget i c++ programmering til windows;
angiveligt opfundet af en ungarer.

Den går i korthed ud på at man prefixer sine variable navne med en
indikation af typen; eks.:

char *pszName; // psz = Pointer to String, Zero termintated
TWindow *pwMainWindow; // p=Pointer, w=Window
char achName[123]; // Array of CHars
int iCount; // i=int

osv. Der er desværre nogen der har trukket denne opførsel med over
java, og bruger f.eks. Point pointCenter; etc.

Personligt mener jeg sammen med mange andre at dette er en dårlig
notation; af årsager tidligere angivet.

>Venlig hilsen

vh. ld

---

Peter Lind wrote:
> PS: En anden skribent foreslog at man holdt sig til engelske variabelnavne.
> Jeg er ikke helt enig. Der er ikke noget som helst galt i danske
> variabelnavne, så længe ALLE variabelnavne er i det samme sprog, og
> STØRSTEDELEN af metodenavnene ligeså. Og da java understøtter æ,ø og å, så
> lad være med at finde på ting som saetSideHoejde, men brug sætSideHøjde.
> Problemet ved danske metodenavne er at get og set ikke rigtigt lader sig
> oversætte...

Eneste ulempe er så, at mange amerikansk producerede værktøjer desværre
ikke kan håndtere andet en 7-bit sourcekode. Typisk.


-dennis

---

"Dennis Thrysøe" <dt@netnord.dk> wrote in message
news:3C8322B1.7020805@netnord.dk...
> Peter Lind wrote:
> > PS: En anden skribent foreslog at man holdt sig til engelske
variabelnavne.
> > Jeg er ikke helt enig. Der er ikke noget som helst galt i danske
> > variabelnavne, så længe ALLE variabelnavne er i det samme sprog, og
> > STØRSTEDELEN af metodenavnene ligeså. Og da java understøtter æ,ø og å,
så
> > lad være med at finde på ting som saetSideHoejde, men brug sætSideHøjde.
> > Problemet ved danske metodenavne er at get og set ikke rigtigt lader sig
> > oversætte...
>
> Eneste ulempe er så, at mange amerikansk producerede værktøjer desværre
> ikke kan håndtere andet en 7-bit sourcekode. Typisk.
>
>
> -dennis
>

Hvilke værktøjer drejer det sig om ? Bare af ren og skær interesse....

venlig hilsen
Morten Olsson

---

Et jeg lige stødte på den anden dag er RefactorIt (ww.refactorit.com).

Jeg har også mødt et anden i samme skuffe, men jeg kan ikke huske hvad
det var for et.

-dennis

Morten Olsson wrote:
> "Dennis Thrysøe" <dt@netnord.dk> wrote in message
> news:3C8322B1.7020805@netnord.dk...
>
>>Peter Lind wrote:
>>
>>>PS: En anden skribent foreslog at man holdt sig til engelske
>>>
> variabelnavne.
>
>>>Jeg er ikke helt enig. Der er ikke noget som helst galt i danske
>>>variabelnavne, så længe ALLE variabelnavne er i det samme sprog, og
>>>STØRSTEDELEN af metodenavnene ligeså. Og da java understøtter æ,ø og å,
>>>
> så
>
>>>lad være med at finde på ting som saetSideHoejde, men brug sætSideHøjde.
>>>Problemet ved danske metodenavne er at get og set ikke rigtigt lader sig
>>>oversætte...
>>>
>>Eneste ulempe er så, at mange amerikansk producerede værktøjer desværre
>>ikke kan håndtere andet en 7-bit sourcekode. Typisk.
>>
>>
>>-dennis
>>
>>
>
> Hvilke værktøjer drejer det sig om ? Bare af ren og skær interesse....
>
> venlig hilsen
> Morten Olsson
>
>
>

---

Morten Olsson <dsl23906@vip.cybercity.dk> wrote:

> > Eneste ulempe er så, at mange amerikansk producerede værktøjer desværre
> > ikke kan håndtere andet en 7-bit sourcekode. Typisk.
>
> Hvilke værktøjer drejer det sig om ? Bare af ren og skær interesse....

Together v5.02 ihvertfald.
--
Max

---

On Fri, 1 Mar 2002 11:28:41 +0100, "Karsten Mandrup Nielsen"
<kmn@logimatic.dk> wrote:

>Hejsa,
>
>Vi er i øjeblikke ved at lave en code convension til brug ved java udvikling
>og vi baserer det på suns udgave.
>
>Nu er der kommet forslag om at navngive variabler med type først. ex.
>intKundeNummer - strNavn osv.
>
>Jeg er ikke tilhænger af dette, men savner nogle gode argumenter?

Der er en række argumenter:

"Sammenblanding af abstraktionsniveauer og traceability"

At der er tale om en int, er et implementationsspørgsmål. At man har
valgt at kalde en attribut PostNummer stammer fra den tidlige
systemudvikling. Ved at ændre navngivningen i forbindelse med
implementationen forringer man traceability, og dermed sammen-
hængen mellem de forskelle modeller i udviklingsforløbet (Jeg ved
ikke om din virksomhed lægger vægt på traceability i forbindelse
med systemudvikling

"Redundans"

Er nok det mindste problem, men typenavnet er naturligvis redundant
og redundans er lig med mere arbejde ved refactoring (Jeg ved ikke
og din virksomhed lægger vægt på refactoring

"Kobling"

Der skabes en kobling mellem attributtens navn og dens type. Kobling
er en god ting hvis man gerne vil have større vedligeholdesesomkost-
ninger (Jeg ved ikke om din virksomhed lægger vægt på vedligeholdeses-
omkostninger

Man kan sige at det i praksis er mindre ting, og det er det måske
også, men det er min erfaring at der er en tydelig sammenhæng mellem
folk der finder på at inkludere typers navne i attributers navngivning
og deres placering i den "datalogiske fødekæde". Det er ganske enkelt
noget overflødigt pjat man højest får problemer af, samtidig øger det
fokuseringen på low level implemenationsdetaljer.


/Flemming Jensen