Tanker rundt kodestandard / programming guidelines

[South_Bridge]

Dessuten: kort er godt når det gjelder lokale variabler og private variabler.

Jeg skriver ikke for eksempel

bool increment_on_next_iteration;

men heller

bool incr; // Increment on next iteration

 

Hmm... "tja". når man har svært lange variabelnavn burde man ta 2 sec og tenke seg om det kan være noe annet å kalle den. Jeg er også fan av autocomplete/intellisens, så for meg er "bool incr" (jeg leser konsekvent "bool increase") veldig ulogisk og vanskelig å lese om man ser den i forbindelse med noen annen kode.

 

Dette var jo ditt eksempel, men som vi ser... en problemstilling

[MailMan13]

Er vel en vanesak vil jeg tro og avhengig av hva slags koding man gjør.

 

Jeg brukte det ikke selv lenge heller. Begynte å notere med _ etter jeg begynte å kode i jobbsammenheng. Heller litt for eksplisitt enn motsatt når kodebasene vokser og det er 4-5 andre teamet som koder på systemet også, så risikerer man ikke at noen modifiserer noen members i vanvare. Blir også raskere å se hvorvidt en metode endrer status til objektet ditt bare ved å skumme koden kjappt en gang.

 

En annen nice bi-effekt er at IDE'et automatisk grupperer dem sammen når det sorterer intellisense-listen, så man får umiddelbar oversikt over alle members direkte i editoren. Samme effekt i debuggere og refactoring/review verktøy.

 

Det er ikke dermed sagt at det er "det eneste riktige", bare at jeg har funnet flere +'er enn -'er for min del.

Endret 24. februar 2010 av MailMan13

[Dead_Rabbit]

Klasse-definisjon:

class Person {
public:
	void name(const string&);
	const string& name();

	void something_funny();
	// etc
private:
	string name_;
};

 

Klasse-implementasjon:

void Person::name(const string&)
{
	// ...
}

const string& Person::name()
{
	// ...
}

void Person::something_funny()
{
	if(true) {
	// ...
	} else {
	// ...
	}

try {
	while(true) { // denne dritten her skal selvfølgelig indenteres, men denne editoren her er fucka.
	// ...
	}
	} catch(const exception& e) {
	// panic
	}
}

 

Men, jeg bruker bare underscore hvis det på død og liv er nødvendig i en klasse. Hvis det er naturlig å ikke ha gettere og settere evt. hvis det er naturlig at de ikke korresponderer til et medlem, så styrer jeg til helvete unna det, for det er nasty synes jeg. Men jeg er selvfølgelig konsistent innad i en klasse.

 

Sånn forøvrig så prøver jeg å unngå overdreven bruk av parenteser og jeg prøver å bruke standardbiblioteket hvor enn det er mulig, heh. Det er utrolig hva som ligger og lurer i namespace std.

Endret 24. februar 2010 av Dead_Rabbit

[South_Bridge]

Jeg prøver å være flink med bruk av paranteser... fler jo bedre så lenge det ikke er "(( x - y ))"

 

men

 

 
varname_

 

Var en merkelig vri

[GeirGrusom]

Greit nok det, men om det "fulle" navnet også er kort kan det være greit å være eksplisitt.

 

Heter det "_id" kontra "id" så vet man umiddelbart hva det dreier seg om.

Ja, dette er nok en fin måte å skrive private variabler på.

[Dead_Rabbit]

Jeg prøver å være flink med bruk av paranteser... fler jo bedre så lenge det ikke er "(( x - y ))"

 

men

 

 
varname_

 

Var en merkelig vri

Hehe, jeg husker ikke hvor det var, men jeg leste et argument for å bruke post-underscore istedenfor pre-underscore. Mange implementasjoner har sære greier som begynner med underscore, og ved å ha underscore på slutten vil man kunne unngå potensielle navnekollisjoner. Dessuten så synes jeg det ser bedre ut å ha det i slutten av navnet, selv om dette også ser jævlig ut.

[GeirGrusom]

I C++ bruker dobbel-understrek for å merke implementasjonsspesifikke funksjoner, og én understrek har noe med standardettellerannet å gjøre... ihvertfall har jeg sett at funksjoner som heter for eksempel "enfunksjon" i cdecl blir oversatt som _enfunksjon når programmet blir kompilert.

Jeg har ikke brydd meg nok til å kikke nærmere på dette, men noen har kanskje det...

[Hårek]

Godt å se at man bryr seg om hvordan koden ser ut. 

Jeg opplever at de fleste ikke gjør det, og det finner jeg svært irriterende. Jeg jobber i et stort firma med mange briljante programvareutviklere og dyre konsulenter, på prosjekter med C, C++, Java og C#. De fleste har en utrolig rotete stil, f.eks bruker de minst mulig mellomrom i statements, men strør om seg med tomme linjer alle tenkelige plasser. 

 

 

Jeg er derimot sterkt påpasselig på at kode må være pent formatert, konsistent og lett å lese. Og det hender jeg reflekterer over hvorfor det er slik forskjell. De andre har univeritetsutdannelse, jeg har ingen formell programvareutdannelse (har høyskole i elektronikk). Kan det være en sammenheng? 

 

 

[South_Bridge]

Uten å se koden du skriver Hårek, jeg er enig med deg!

 

Kunne vi ikke ha smelt sammen en ganske standard "kodestandard"... "HWs kodestandard" eller noe Starte en bevegelse hvor målet er bedre kode!

[tomsi42]

Jeg er derimot sterkt påpasselig på at kode må være pent formatert, konsistent og lett å lese. Og det hender jeg reflekterer over hvorfor det er slik forskjell. De andre har univeritetsutdannelse, jeg har ingen formell programvareutdannelse (har høyskole i elektronikk). Kan det være en sammenheng? 

Om det er en sammenheng, skal jeg ikke si. Men jeg opplever mye det samme - har kun teknisk fagskole i elektronikk som offisiell utdannelse. Og ser at høyt utdannede kan ha en særdeles merkelig kodestil. Det er som om de forventer at alle som skal lese koden sin er sensor eller professoren deres ... Det er to ting som stadig slår meg. 1) En forelskelse i en metodikk (hungarian notation, anyone?) og 2) En overdrevent overdesignet/overimplementert løsning på en enkel problemstilling (f.eks jeg skulleha en rutine som parset en enkel config fil, og fikk en full kompilator som løsning!)

 

Men jeg har heldigvis også opplevd meget godt utdannede og intelligente mennesker som leverer avansert og innsiktsfull kode som er greit å forstå og løser den riktige oppgaven.

[duckers]

Hehe..

"Dersom man plasserer 10 personer med doktorgrad bak hver sin maskin, vil det høres ut som en som skriver"

[GeirGrusom]

Haha^^

 

Etter nå snart to år med datateknikk, må jeg si at jeg har liten tro på at de sm har en bachelor ihvertfall fra denne skolen er spesielt kompetente når de er ferdig.

 

Det er snodig hvor mye lavere kravene er i datafagene i forhold til matematikk, fysikk, kjemi, statistikk og elektronikk.

 

Anyways, når det gjelder kodestandard så er det helt klart at mange er litt på jordet. Spesielt synes jeg dette gjelder mer bruk av gode constructorer og dokumentasjon mer enn selve formateringen. Formatering er fote bagateller når det kommer til de mer grove feilene mange gjør, som gjør koden vanskelig å bruke, og ikke bare lese.

 

I C og C++ er det enda viktigere å være konsis, ettersom språket har mange funksjoner som kan gjøre programmet fullstendig kryptisk.

Derfor har vel også Internation Obfuscated C Code

[asicman]

Man sløser en linje? Vil ikke compileren drite i mellomrom og spaces når den kompilerer da...

 

Det er jo ikke for kompilatoren man varierer bruken av whitespace i koden. Det er for lesbarhet og for å få oversikt. Personlig så liker jeg ikke bruk av masse unødvendige blanke linjer, store ASCII rammer osv. Jeg foretrekker da heller mindre scrolling.

[GeirGrusom]

Man sløser en linje? Vil ikke compileren drite i mellomrom og spaces når den kompilerer da...

 

Det er jo ikke for kompilatoren man varierer bruken av whitespace i koden. Det er for lesbarhet og for å få oversikt. Personlig så liker jeg ikke bruk av masse unødvendige blanke linjer, store ASCII rammer osv. Jeg foretrekker da heller mindre scrolling.

Jeg er enig. Tomme linjer er for å gruppere ting, ikke for syns skyld.

 

For eksempel

int myvar = 100;
int secondvar = 1000;

foreach(var error in code)
{
 Console.WriteLine(error);
}

Så er det naturlig å skille variabeldeklerasjonene fra for løkken for leselighetens skyld. Det er derimot unødvendig med noe mer enn én tom linje. Det er også unødvendig å ha tom linje mellom hver statement, osv.

Og jeg HATER all form for dekorering. Det er fullstendig unødvendig.

/****************************
*       HELLO WORLD!       *
****************************/

Hva svarte er poenget??

[South_Bridge]

Jeg er enig i GeirGrusom i bruk av luft i kode... er for å separere og øke lesbarhet. However har jeg noen små tildenser til dekorering (ikke alt for meget da men)

[steingrim]

 

/****************************

*       HELLO WORLD!       *

****************************/

 

Hva svarte er poenget??

 

 

Slikt er utrolig unødvendig og tar bare plass på skjermen, slik at det blir plass til mindre kode.

 

 

En annen ting jeg har irritert meg grenseløst over til tider er unødvendige kommentarer på metoder. Jeg fjernet nylig ca 8000 linjer med slike kommentarer fra et java-prosjekt på jobb:

/**
*
* Sets the foo
*
* @param Sets the foo
*
*/
public void setFoo(String foo) {
   this.foo = foo;
}

 

Her tar jo den totalt unødvendige javadoc-kommentaren dobbelt så mye plass som metoden. Og grunnen til at jeg irritererer meg er selvsagt at jeg skjønner jævlig godt hva setFoo() gjør. Det er nettopp når den gjør noe ekstraordinært det er verdt å kommentere. Som sagt, jeg nappa ut 8000 slike linjer i et prosjekt på jobben. Det var deilig

Endret 3. mars 2010 av steingrim

[tomsi42]

Det er noe rart med denne tråden. Kan se ut som om de siste postene har blitt blandet sammen ...

Endret 3. mars 2010 av tomsi42

[steingrim]

Det er noe rart med denne tråden. Kan se ut som om de siste postene har blitt blandet sammen ...

Her er det noe galt ja, innlegget mitt ble ikke riktig heller, det mangler jo selve poenget mitt!

 

Edit: jeg tror jeg har funnet en svakhet i parseren på diskusjon.no ;-)

Endret 3. mars 2010 av steingrim

[GeirGrusom]

Det var lenge jeg ikke fikk tilgang til denne tråden... tror kanskje dette er rapporteringsverdig..

[Skagen]

Manglet en "]" i [ quote ]-taggen til steingrim. Skal ta å lage noen tester og se om jeg klarer å "kopiere" buggen i Testposter. Normalt skal jo forumet rydde og og validere BBkode før den parses.