Namngjeving av variablar i c++.

[Metalicat]

Korleis er det vanleg å namngje variablar "etter rett" i c++?

 

Eg er vandt med Java, og har kalt variablar t.d. antalBilar, fornamn, etternamn.

 

Eg har lånt ei bok som heiter "c++ og objektorientert programmering", og der står det at ein skal kalle variablane med stor forbokstav: Etternamn, Fornamn.

 

Eg har òg høyrt at ein skal kalle variablar nAntalBilar om det er integer, osv: altså angje datatype i variabelnamnet.

 

Kva er vanleg å gjere, og kva er "rett" etter ANSI-standard?

[roac]

Korleis er det vanleg å namngje variablar "etter rett" i c++?

En brukt standard er Hungarian Notation.

[hishadow]

// Pekere (bruker _ptr for å minne om variabler som må slettes.)

//

unsigned char* et_stort_buffer_ptr = NULL;

 

// For andre typer variabler bruker jeg lignende skrivemåte.

//

unsigned int en_tallverdi = 0;

static const int EN_KONSTANT = 62;

 

// Noen ganger bruker jeg også Java notasjonen.

//

unsigned int enLitenVariabel = 0;

 

(utenom det synes jeg det ikke lenger en noe poeng å bruke hungarian notation for å angi typen i navnet. Er jo bare å bevege musa over variablen. Brukte også før å navngi med m_noe, pNoe, nNoe.. men synes det blir uryddig i lengden. Så.. bare ignorer boka og finn/bruk det du synes er lettest å lese )

[A_N_K]

Uff, hungarian notation.

[GeirGrusom]

Uff i det hele tatt, det spiller vel ingen rolle om du har stor eller liten forbokstav? eneste som er viktig er at du er konsekvent på hvordan du skriver.

 

De som evt. skal bruke koden din etterpå, vil ikke ha noen problemer med å bruke din kode så lenge det ikke varierer hvordan du skriver ting.

 

Når det kommer til datatyper, så kan det være en fordel å skrive f.eks. bool bMyBoolean, og int iCounter, for da kan du lett se hva det er for slags variabel, men dette er stort sett ting du må finne ut av selv, om du behøver.

 

Alt skal ha en hensikt, det å droppe tab, og heller bruke mellomrom f.eks. er bare tøys, nettopp fordi det ikke har noen hensikt, annet en at et rasshøl et eller annet sted synes de har svaret på alt i hele verden.

 

Det viktigste er at du kommenterer koden, for gjør du det riktig, skal alle klare å finne ut hva den gjør for noe.

[☀ ❄]

Uff, hungarian notation.

Jeg synes ikke du understreker nok, A_N_K. La meg prøve:

 

Hungarian notation?! Vræl!

 

 

Jeg gir variabler navn slik (konkrete eksempler fra det jeg holder på å kode akkurat nå):

bool successful_move = false;
char row;
int row_number;

 

Preprosessor-direktiver (som for øvrig bare brukes til inkluderingsvern og evt. betinget kompilering):

#ifndef TOWERGAMMON_BOARD_HPP
#define TOWERGAMMON_BOARD_HPP
// ...
#endif // TOWERGAMMON_BOARD_HPP

 

Konstanter gir jeg navn på samme måte (med små bokstaver).

 

Klasse og funksjon:

bool Board::move(int row_number, int num_moves);

 

Pekere skal jeg i utgangspunktet kalle pnavn, men det glemmer jeg ofte -- uten at dét er noe stort tap.

[A_N_K]

Det er direkte uskjønt ja

[kattemat]

Nja... synes hungarian funker greit jeg så lenge det er konsistent. Vil dog ikke brukt det om jeg fikk bestemme

 

Personlig er jeg fæn av denne_typen_navning, men i jobbsammenheng og forsåvidt i hobby prosjekter hvor en ikke selv er diktator så må en leve med BådeDenne ogDenne, Av_Og_Til_Denne og szTilsluttDenne.

[kjetil7]

Og mange bruker m_medlemsvariabel (inkl. der jeg har jobbet). Privat bruker jeg som regel underscore som prefiks i medlemsvariabler. Ellers bruker jeg ikke noe prefiks i det hele tatt, men bruker underscore som ordskiller (auto_update, row_number osv..)

 

Det viktigste er som sagt tidlgere, å være konsistent gjennom hele prosjektet.

Endret 26. mai 2005 av kjetil7

[Kjeksen]

Jeg personlig liker best enLitenVariabel versjonen Synst det ser ryddig og pent ut

[roac]

Jeg personlig liker best enLitenVariabel versjonen Synst det ser ryddig og pent ut

Jeg er stort sett enig, men det har noen ulemper: Forkortelser. Denne navnestandarden gir variabelnavn som sAMAccountName. Av den grunn liker jeg variabelnavn på formen EnLitenVariabel bedre.

[☀ ❄]

... kva er "rett" etter ANSI-standard?

Bare for å understreke det: Det er ikke noe som er "rett".

 

Utenom K&R.

 

[roac]

Bare for å understreke det: Det er ikke noe som er "rett".

 

Utenom K&R.

Musikk i mine ører. Bare så synd at jeg har lite behov for K&R om dagen

[kattemat]

Her er et utsnitt fra Documentation/CodingStyle i linux kjernen. Jeg vet at dette slett ikke har noen generell betydning, men kodebasen det er snakk om er noe som særs mange flinke folk har hacket på

Legg merke til kommentaren om hungarian Teksten gjenspeiler også tradisjonen med denne_type_variabelnavn i Unix C koding.

 

  Chapter 4: Naming

 

C is a Spartan language, and so should your naming be.  Unlike Modula-2

and Pascal programmers, C programmers do not use cute names like

ThisVariableIsATemporaryCounter.  A C programmer would call that

variable "tmp", which is much easier to write, and not the least more

difficult to understand.

 

HOWEVER, while mixed-case names are frowned upon, descriptive names for

global variables are a must.  To call a global function "foo" is a

shooting offense.

 

GLOBAL variables (to be used only if you _really_ need them) need to

have descriptive names, as do global functions.  If you have a function

that counts the number of active users, you should call that

"count_active_users()" or similar, you should _not_ call it "cntusr()".

 

Encoding the type of a function into the name (so-called Hungarian

notation) is brain damaged - the compiler knows the types anyway and can

check those, and it only confuses the programmer.  No wonder MicroSoft

makes buggy programs.

 

LOCAL variable names should be short, and to the point.  If you have

some random integer loop counter, it should probably be called "i".

Calling it "loop_counter" is non-productive, if there is no chance of it

being mis-understood.  Similarly, "tmp" can be just about any type of

variable that is used to hold a temporary value.

 

If you are afraid to mix up your local variable names, you have another

problem, which is called the function-growth-hormone-imbalance syndrome.

See next chapter.