Tanker rundt kodestandard / programming guidelines

[South_Bridge]

Hvorfor er det noen som tviholder på å skrive

 

function(args) {
...
}

 

når det aller best skrives ()

 

function(args)
{
...
}

 

Og hva er greia med variabel navn? For meg er "_varNavn" og "__varNavn" noe av det mest sære jeg ser. Farlig er det og. Er vel mye bedre å være konsekvent med feks "m_varNavn" ?

[tomsi42]

Hvilket språk er det du tenker på?

 

Forskjellige språk har sine konvensjoner, så det du ser er et resultat av forskjellig bakgrunn.

 

Den første funksjonsdefinisjonen er vanlig i bl.a. C og java.

 

Det å bruke underscore foran variable navn, mener jeg kommer fra et eller annet språk for å angi scope.Husker ikke hvilket i farta, for det er et noe sært design. _ har også vært brukt i noen språk for å indikere private variabler, mens andre bruker m foran variablenavnet.

 

Ditt eksempel, m_varNavn er veldig feil i mine øyne, da du blander to stilarter. Enten m_var_navn, eller mVarNavn. Eller dropp m,en helt.

[ze5400]

Fordi skjermen til de som skriver slik kode er femten linjer høy. Det er det eneste jeg kan komme på

 

Er vel mest smak, behag, og guidlines på enkelte prosjekter som gjør at det blir slik.

 

 

Ang. variabelnavn foretrekker jeg VarName for public, og _varName for private.

Jeg er nok sær, men dette virker mest logisk i mitt hode.

[South_Bridge]

Hvilket språk er det du tenker på?

 

Forskjellige språk har sine konvensjoner, så det du ser er et resultat av forskjellig bakgrunn.

 

Den første funksjonsdefinisjonen er vanlig i bl.a. C og java.

 

Det å bruke underscore foran variable navn, mener jeg kommer fra et eller annet språk for å angi scope.Husker ikke hvilket i farta, for det er et noe sært design. _ har også vært brukt i noen språk for å indikere private variabler, mens andre bruker m foran variablenavnet.

 

Ditt eksempel, m_varNavn er veldig feil i mine øyne, da du blander to stilarter. Enten m_var_navn, eller mVarNavn. Eller dropp m,en helt.

 

Jeg tenker sånn generelt. Jeg koder PHP, JAVA, C# og C++ og bruker samme standard på alt sammen.

 

Og er jo litt med vilje jeg fyrer opp denne samtalen da jeg vet at det er ulikt hva man følger.

 

Jeg er veldig uenig i at med "m_varName" så blander man to stilarter. "mVarName" er etter min mening vanskligere å lese, og dermed vanskeligere å oppfatte når man bare kaster et blikk over flere variabler. "m_varName" kan ikke misforstås "mVarName" er i mer konflikt da "m" ikke har noe med variabelnavnet sånn sett å gjøre og "ødelegger" da for en standard om camelcase med variabelnavn skrevet slik som "variabelNavn".

[Ueland]

Hvorfor er det noen som tviholder på å skrive

 

function(args) {
...
}

 

når det aller best skrives ()

 

function(args)
{
...
}

 

Første er jo best, den andre sløser jo en hel linje til ingenting

 

Er akkurat som Vim vs Emacs diskusjoner, man blir aldri enig.

[South_Bridge]

Hvorfor er det noen som tviholder på å skrive

 

function(args) {
...
}

 

når det aller best skrives ()

 

function(args)
{
...
}

 

Første er jo best, den andre sløser jo en hel linje til ingenting

 

Er akkurat som Vim vs Emacs diskusjoner, man blir aldri enig.

 

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

 

Anyways: jeg har ingen problemer med å sløse en "hel linje" for å øke leservennligheten. Man bbør vel sette leservennlighet og struktur ganske høyt når man sitter og koder hele dagen

[GeirGrusom]

Det er ingen objektiv god grunn til å velge den ene foran den andre, så her kommer en subjektiv grunn: første ser utrolig stygt ut, derfor velger jeg den andre.

[tomsi42]

Anyways: jeg har ingen problemer med å sløse en "hel linje" for å øke leservennligheten. Man bbør vel sette leservennlighet og struktur ganske høyt når man sitter og koder hele dagen

Akkurat det, er jeg enig med deg i.

 

Det beste rådet angående kodestandard som jeg har hørt, er "Velg en standard, og hold deg til den".

 

Generelt sett, så er jeg tilhenger av en så slank stanard som mulig. Jeg ser mange som lager store tunge dokumenter som detaljstyrer alt mulig. Det blir fort uproduktivt da man fokuserer på feil ting ...

 

For meg er de viktigste punktene:

 

1) Forby "Hungarian notation". Det skaper kun støy og forvirring.

2) Bruk gode og beksrivende navn på klasser, metoder og variabler.

3) Følg den gjengse standarden til språket du programmer i. Dvs. plassering av {, } osv følger det som de fleste bruker.

4) Sett "indentation length" og "tab length" til det samme. Bruk en editor som lagrer indenter som tab - ikke space.

 

Regel 4 er muligens litt spesiell, men gjør at jeg kan bruke 4 spacer og Ole 3 spacer, og filene våre går om hverandre.

[steingrim]

Forskjellige konvensjoner er jo greit nok, jeg bryr meg ikke så mye om hvordan bokstavene ser ut på skjermen, det eneste jeg bryr meg om er at det er konsistent. Men skriver man Java, forventer jeg egentlig at man følger Java sin stil-guide (http://java.sun.com/docs/codeconv/), skriver man Python bør man følge PEP8 osv. At forskjellige språk har forskjellige konvensjoner er ikke så viktig, det blir bare religiøs krangling om man prøver å blande.

 

Konsistens over alt annet.

[MailMan13]

Er vel bare å formatere det slik man vil selv da. Har "jukset" meg til begge når jeg koder C#:

 

ctrl+k+d (VS reformat) => { på samme linje

ctrl+e+c (ReSharper cleanup) => { på egen linje

 

Bare passe på å kjøre samme formatet som det var i i utgangspunktet før jeg sjekker inn, så blir det ikke så store changesets når alle utviklerene formaterer på sin egen stil hver gang de gjør noe, eller ulike stiler i samme prosjekt

 

_ i variabelnavn betyr vel normalt private member, de er greit å notere spesielt, så slipper man å lete etter deklarasjonen for å finne ut av scope. Alternativt kan man jo forsåvidt la leseren finne ut av det selv, eller kvalifisere bruken med me/this overalt.

Endret 24. februar 2010 av MailMan13

[GeirGrusom]

Jeg har mer eller mindre ubevisst begynt å gi alle private variabler bare små bokstaver.

Tidligere skrev jeg m_minvariabel, nå bare minvariabel.

Men jeg er ikke sikker på om det er noe smart å kun skille med store og små bokstaver...

I noen fonter er det vanskelig eller umulig å se forskjellen mellom stor I og liten L: "Illicit" eller "illicit"

[tomsi42]

Problemet med å bruke bare små bokstaver er at lange navn fort blir uleselige. Hvis de private variablene er pakket rundt get/set, så bør det ikke være et problem, for du bruke da gettere og settere eller hur?

 

Jeg bruker alltid en monospace font i editoren min og synes ikke det er et problem å skille mellom I og l ...

[MailMan13]

Problemet med å bruke bare små bokstaver er at lange navn fort blir uleselige. Hvis de private variablene er pakket rundt get/set, så bør det ikke være et problem, for du bruke da gettere og settere eller hur?

Regner med han bruker camel-case med første i lower. I Java/C++ er det forsåvidt greit siden man sier get/set eksplisitt. I .Net hvor vi har properties som kapsler inn get/set vil ikke det fungere.

 

Det vil heller ikke skille på members og lokale variable.

Endret 24. februar 2010 av MailMan13

[JohndoeMAKT]

Jeg skriver OTB som er en blanding av de to.

 

class fisk

{

public function laks()

{

if ($grilled) {

while(true) {

awesome();

}

}

}

}

 

Om jeg ikke husker helt galt er dette Zend-standarden.

[South_Bridge]

Mye bra er blitt sagt nå

 

En ting jeg er veldig enig i er konsistens. På jobben har vi en kodestandard jeg er veldig fornøyd med, men man får seg ikke en dask på lanken om man gjør mindre avvik så lenge man her konsistent og gjør det over hele linja liksom.

[GeirGrusom]

Problemet med å bruke bare små bokstaver er at lange navn fort blir uleselige. Hvis de private variablene er pakket rundt get/set, så bør det ikke være et problem, for du bruke da gettere og settere eller hur?

 

Jeg bruker alltid en monospace font i editoren min og synes ikke det er et problem å skille mellom I og l ...

Jeg bruker Consolas, som er truetype monospace, og det er ikke noe stress der heller, men det er ikke utenkelig at andre kan ha det problemer.

 

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

[MailMan13]

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.

Endret 24. februar 2010 av MailMan13

[tomsi42]

Regner med han bruker camel-case med første i lower. I Java/C++ er det forsåvidt greit siden man sier get/set eksplisitt. I .Net hvor vi har properties som kapsler inn get/set vil ikke det fungere.

Ja, der er det en forskjell.

Det vil heller ikke skille på members og lokale variable.

Men begynner man navn på properties med lower case? Hadde det ikke vært bedre å starte property navn med stor bokstav og lokale/private variabler med liten? Metode/funksjons kall ser man jo på argument liste eller tom () på slutten. Muligens med unntak av VB.net - der er vel parantesene friillig ?

[MailMan13]

Men begynner man navn på properties med lower case? Hadde det ikke vært bedre å starte property navn med stor bokstav og lokale/private variabler med liten?

Er det som er poenget, gjør man det slik er det ingen distinksjon mellom lokale og private variable. Properties er uppercase i .Net, den er grei.

 

Metodekall er greit, det er Upper [.Net] / Lower [Java] som vanlig.

Endret 24. februar 2010 av MailMan13

[tomsi42]

Er det som er poenget, gjør man det slik er det ingen distinksjon mellom lokale og private variable.

Det har jeg aldri sett som et problem. Navn og bruksområde bør gi en god indikasjon på hva som er hva.