Vad brukar ni ha för namnstandard på era objektkollektioner? Om man tex har en klass som heter customer skulle ni kalla objektkollektionen för customers, customerList, customerCollection eller något för annat namn?

Jag är starkt emot att beskriva för mycket saker med namn explicit, av flera anledningar.
1. Om man byter representation så måste man byta namn. Har man vettiga bibilotek etc. så kommer metodanrop till klasserna att se likadana ut ändå.
2. Det klottrar ner koden, gör den svårare att läsa.
3. Om man ser till att göra saker så små som möjligt är det ändå skitenkelt att hitta definitionen.
4. I en modern editor får man fram information om det under tiden man skriver ändå.

Jag skulle definitivt kalla det för customers.

Så länge namnet beskriver vad den innehåller är det bra. Men när det förkortas så att läsbarheten blir ett problem, då kommer det bli ett större problem i längden för underhållet av koden.

En generell "regel" som används är att använda en trebokstavsförkortning före namnet på det man döper. Till exempel "objMittObjekt" Där "obj" står för objekt. Strängvariabler förkortar man "str" och ett namn som beskriver variabeln.

Det kallas ungersk notation och är enligt många en något föråldrad teknik. Enligt mig är det asfult, hjälper absolut ingenting och gör koden stor och klumpig i onödan.

Enligt mig:
1. En normal funktion ska vara så kort att var du än är i koden så ser du hela funktionen, och därmed också alla deklarationer i de fall du verkligen skulle behöva veta typen.
2. Det är i de allra flesta fall antingen ointressant eller uppenbart vilken typ ett objekt har.
3. Om man skippar tre tecken som beskriver typen kan man istället lägga till tre tecken som tydligare beskriver variabelns innehåll.

Det finns inget egenvärde i att ha en namnkonvention som styr hur man skriver grejer. Syftet med namnkonventioner är att nästa programmerare (som naturligtvis kan vara en själv) så fort som möjligt ska förstå vad en funktion/variabel gör, hur den gör det och hur den ska anropas. Jag har aldrig blivit hjälpt av ett typprefix.

Jag brukar inte använda ungersk notation, men nyligen gjorde jag det. Jag hade en variabel year som innehöll året som en heltal. Sedan skapade jag ett "årobjekt" från vilket jag skulle hämta månaderna. Men vad skulle jag kalla detta årobjekt? Det blev oYear för att markera att det var ett objekt. Ett undantag som sagt, men någon gång kan man alltså tillåta sig att använda ungersk notation.

Jag skulle faktiskt föredra att kalla det yearObject eller year_object. Min poäng är att det inte är något direkt fel med att ange implementationsdetaljer såsom variabeltyp, men att det inte har något egenvärde. Syftet med all namngivning är att göra koden lättare att förstå.

Sen gillar jag inte just ungersk notation för att jag tycker att det är så förbannat fult, men det är en annan sak. Jag föredrar att skriva ut hela namnet om det är så att det är nödvändigt (som fallet ovan). Jag skulle nog till och med föredra något i stil med year_as_integer över intYear. I det fallet är det en viktig konceptuell information att man har olika grejer.

Mitt motto är liksom: Slösa inte med tecken i onödan (ungersk notation på alla variabler, även när typen är uppenbar), men snåla inte med tecken i onödan heller (man tjänar 5 tecken på "int" istället för "integer", men med "integer" säger man exakt allt det finns att säga, det finns ingen risk för misstolkningar).

Jag rekomenderar oxå att använda Sufix istället för prefix. Det göra det snabbare att lista i intelisense.
Sedan kan man ge den mer naturliga namn:

CustomerList vs. lstCustomer

Jag föredrar det första alternativet.

Frågan är sedan skall man skriva singular:
CustomerList
Eller i plural:
CustomersList

Jag tycker list ger en intuetion om att det handlar om flera element av just typen Customer.
List ger intuetionen att det CustomerList stödjer gränssnitte IList eller ärver av ett List objekt.

Om man hade haft en array, som kan man ju antingen kalla den CustomerArray eller Customers.



Ett fullständingt namn komunicerar tydligt. Detta underlättar läsbarheten av din kod.

Jag har för mig att det finns ett citat som lyder:
"Vem som helst kan programmera så en dator förstår,
men det är en konst/svårt att programera så att människor förstår."

<b>>CustomerList [...] Om man hade haft en array, som kan man ju antingen kalla den CustomerArray eller Customers.</b>

Jag hänvisar till vad jag har skrivit tidigare. Oavsett om det är suffix eller inte tycker jag att man alltid ska undvika att skriva ut det om det går att förstå ändå. Är funktionen så lång att man inte ser deklarationen var man än är i funktionen?
Ja, då är den förmodligen _för_ lång ändå. Har det avgörande betydelse för någon som läser koden huruvida det är en list eller vektor?
Det är beroende på situation, men i allmänhet skulle jag säga nej.

Det är lite som att skriva
Gatunamn: Storgatan
Gatunummer: 14

istället för

Adress: Storgatan 14

eller bara

Storgatan 14

Folk som förstår vad det står störs bara av informationen som hänger runt omkring.

Jag brukar använda prefix som beskriver vad det är för slags objekt.

globala objekt börjar med g
argument till funktioner börjar med a
klassmedlemmar börjar med m
statiska medlemmar börjar med s

lokala objekt och strukturmedlemmar har inget prefix.

Tycker det gör det enkelt att se vilka beroenden kod har och hur den påverkar omgivningen.

Har dock lite svårt med Niklas modell att funktionerna skall vara små. Har alltför ofta sett funktioner som konverteras till en klass med en massa medlemsvariabler.

dvs istället för
int func() {
int x;
// hämta data
x = ...
// behandla data
int y = x * x;
// spara data
...
}

så ser man
class minfunktion {
int x,y;
int läsdata() {
x = ..
}
int behandladata() {
y = x *x;
}
int sparadata() {
...
}
int func() {
läsdata();
behandladata();
sparadata();
}
}

Jag tycker sån kod är mycket svårare att följa eftersom olika funktioner uppdaterar & läser olika "globala" variabler.

Talar vi om namnkonvention för klasser eller variabler?

Jag tycker klassnamnet bör ge en intuition om vilke gränssnitt/arv den har. Dett atycker jag underlättar läsförståelsen.
Sedan kan variablen namnet var kort:

t.ex.
<code c#>
CustomerList customers = CustomerRepository.all();
Customer customer;
foreach (customer in customers)
{
'...
}
<>

<b>>Har dock lite svårt med Niklas modell att funktionerna skall vara små. Har alltför ofta sett funktioner som konverteras till en klass med en massa medlemsvariabler.</b>
Ja, något sådant förespråkar jag inte. En klass beskriver en slags entitet, inte en uppsamling av funktioner.

Eftersom din kod är lite av ett leksaksexempel är det svårt att säga hur jag skulle skriva om den. Min princip är att om någon del av koden behöver en kommentar för att gå att förstå, så gör jag om den till en mer generell funktion. "int y = x*x;" är något som alla programmerare ska förstå, och jag ser därför ingen poäng med att bryta ut det.

Som det ser ut skulle jag ha lagt det i ett eget namespace; typ:

namespace minrymd {
  int läs() { 
    return ..;
  }
  int behandla(int x) { 
    return x *x;
  }
  void spara(int x, int y) { 
    ...
  }
  void func() {
    int x = läs();
    int y = behandla(x);
    spara(x, y);
  }
}

Inga globala variabler, func är helt och hållet uppenbar, liksom varje ensklid funktion. Jag tycker naturligtvis inte att man ska ha globala variabler. Däremot har jag gärna saker som argument till funktioner. (Effektiviteten är i allmänhet inte ett argument mot i det här fallet; dels är det inget man tänker på i det här läget, dels är prestandaförlusten minimal, dels kan en kompilator utan större problem optimera bort den ändå.)

<b>>globala objekt börjar med g
argument till funktioner börjar med a
klassmedlemmar börjar med m
statiska medlemmar börjar med s</b>

Och konstanter med c? Och pekare och referenser med p och r?
Lägger du in dina initialer först också? =)

int * gcpintmaSize;

Jag köper inte resonemanget. Jag har själv gått från att inte använda prefix till att börja använda prefix, och sen tillbaks igen. Med mitt sätt att lägga upp kod i övrigt ser jag helt enkelt inte nyttan. Men det är bara min åsikt. (På min arbetsplats har vi ungersk notation med g, a, m, s etc. + lite andra regler jag inte gillar. Det är klart att man kan skriva kod ändå. Men det tar mycket längre tid för folk att veta vad funktionerna är till för.)

<b>>Talar vi om namnkonvention för klasser eller variabler?</b>

Eftersom jag nästan alltid utgår ifrån C++ när det gäller såna här grejer, så skriver jag snarare:

Repository<Customer> CustomerRepository;
//...
list<Customer> customers = CustomerRepository.all();
for_each (customers.begin(), customers.end(), do_something);

eller

Repository<Customer> customers;
//...
list<Customer> customerList = customers.all();
for_each (customerList.begin(), customerList.end(), do_something);

Lite beroende på situationen. Alltså: Om typen är en "lista" så skriver jag bara att det är just en lista. Vilken sorts lista ger jag som template-parameter. Det är liksom aldrig aktuellt att kalla något för "CustomerList".

> Och konstanter med c? Och pekare och referenser med p och r?
> Lägger du in dina initialer först också? =)

Jag använder bara en bokstav som prefix. Pekare och referenser är typer så de får inte vara med. Håller helt med dig i övrigt om prefix.

Aha, du har bara för att indikera beteende, det kändes mer rimligt. =)
Fast, som sagt, jag håller inte med. Att indikera att något är argument är i mitt tycke helt onödigt; man ska enligt mitt resonemang alltid kunna se huvudet ändå. Eftersom alla globala variabler egentligen kan undvikas, så skulle jag inte använda "g" heller (jag har inte använt en global variabel på flera år, förutom på jobbet där vi har ett lite speciellt sätt att skriva kod som gör att det är nödvändigt).

Medlemsvariabler och statiska är väl de jag kan känna mest mening med. Dock: om man inte har globala variabler, och har korta funktioner så kommer det vara uppenbart vilka variabler som tillhör klassen och vilka som tillhör funktionen.
Med statiska variabler antar jag att du menar klass-statiska?
De är problematiska, det ska erkännas, dock förhållandevis ovanliga. (Det går snabbt från att vara så att man har en klasspecifik variabel som man sen egentligen vill ha specifik för stora grupper av instanser, och då är det någon slags samling man vill ha, och då övergår de i medlemsvariabler trots allt).

Jag försöker egentligen inte övertyga så mycket, det är snarare så att jag vill försvara mitt synsätt.. =)

Templates/generics är snyggt. Tänkte inte på dem. ;)

namespejsande gillar jag

Namespace Customer
public class List
inherist arraylist
end class
public class Item
end class
end namespace

blir lite tjafs i intellisense man kan jobba flera i samma namespace om man måste och gör ingen skillnad i den kompilerade koden, behöver man fler objekt typ compare etc så har de en given plats etc

eftersom tråden ligger under arkitektur ".NET" så föreslår jag att du läser microsofts guideline på namnstandards för .net

http://msdn2.microsoft.com/en-us/library/ms229002.aspx

så i ditt fall om variabeln vore lokal och innehåller customers så skulle den tex heta:

"List<Customer> customers = ..."



//Roger