Verktøy og metoder for å samarbeide om utviklingsprosjekter?

[GeirGrusom]

Hadde vært fint om alle teksteditorene lærte seg å vise tab.

Indentering burde være rent kosmetisk, men med mellomrom blir den ikke det.

[quantum]

Virker som mange her står fritt til å velge de verktøyene de foretrekker selv, noe man sjelden har mulighet til i en samarbeidssituasjon.... For min del går det ofte i svn, maven, jira, scrum, confluence, scarab. ... i ingen bestemt rekkefølge. ...

[asicman]

og en i gruppen bruker utelukkende Mac. Det prøver eg å unngå

 

GIT på Mac er vel bare snakk om å kompilere hvis jeg ikke husker feil.

 

 

Har man brukt videokonferanser i full HD på flere storskjermer med dokumentkamera osv. så vil man ikke gå tilbake til noe annet. Ulempen er at en kvise ser ut som et fjell :-)

 

Hadde vært fint om alle teksteditorene lærte seg å vise tab.

 

Hva var det du mente her? Hvordan skal de vise tab?

[nomore]

Hva med idemyldring? Typisk mindmanager og freemind. Erfaringer å dele der?

[___]

Hadde vært fint om alle teksteditorene lærte seg å vise tab.

Indentering burde være rent kosmetisk, men med mellomrom blir den ikke det.

 

Tab er fy. Fra tidenes morgen har jeg alltid indentert med mellomrom.

 

Werner

[Sokkalf™]

Hva er det som er så galt med tab?

[siDDis]

Igjen, forskjellige teksteditorer viser og behandler tab heilt forskjelligt. Ting blir vanvittig rotete når eg åpner det enten i Vim, Komodo eller Netbeans.

Endret 22. januar 2010 av siDDIs

[Sokkalf™]

Man kan jo justere tabstop i de fleste teksteditorer. Slik påtvinger man ikke andre en annen kodestil, noen bruker indent på 2, andre bruker 4, etc.

 

Aldri opplevd selv at det blir rotete, verken med min egen eller andres kode. Har alltid brukt tab, og satt tabstop=4.

[GeirGrusom]

Man kan jo justere tabstop i de fleste teksteditorer. Slik påtvinger man ikke andre en annen kodestil, noen bruker indent på 2, andre bruker 4, etc.

 

Aldri opplevd selv at det blir rotete, verken med min egen eller andres kode. Har alltid brukt tab, og satt tabstop=4.

+1

[asicman]

Man kan jo justere tabstop i de fleste teksteditorer. Slik påtvinger man ikke andre en annen kodestil, noen bruker indent på 2, andre bruker 4, etc.

 

Aldri opplevd selv at det blir rotete, verken med min egen eller andres kode. Har alltid brukt tab, og satt tabstop=4.

 

Hvis du tar opp koden til Linux kjernen og viser den med tab satt til 4 vil det se slik ut:

 

 

 

Men forfatteren av koden bruker tab satt til 8 og hos han ser det ut som han tenkte seg:

 

 

 

 

Så bruker man tab og forsøker å aligne kode blir det som regel feil.

[GeirGrusom]

Det er da fullt lovlig å indentere med tab og aligne med space...

Endret 27. januar 2010 av GeirGrusom

[siDDis]

Men det er jo raskare å aligne med å "tabbe" space

[Harkonnen]

Det viste eksempelet er som nevnt helt feil. Det er ikke snakk om indentering, men kode formatering. Og til det sistnevnte bør en bruke space. Men til ren indentering er tab overlegent, da hver enkelt person kan bruke sin foretrukne størrelse på slikt.

Argumentet om at noen editorer erstatter tabs med spaces holder heller ikke vann, hvis en skal være prinsipielle,

da dette er snakk om tullete implementasjonsavhengige problemer.

 

(Forsåvidt litt artig at eksempelet er fra linux-kjernen som er en massiv blobb kode som er indentert med tabs, ikke spaces)

[asicman]

Det viste eksempelet er som nevnt helt feil. Det er ikke snakk om indentering, men kode formatering. Og til det sistnevnte bør en bruke space.

 

Det er akkurat hva jeg skriver i meldingen min:

 

"Så bruker man tab og forsøker å aligne kode blir det som regel feil."

 

Personlig mener jeg det blir litt knotete med å bruke tab til indentering og så taste space for alignment. Jeg bruker en editor hvor jeg taster tab for begge deler, men at det blir satt inn space. Jeg ser helst koden slik forfatteren har ment den å se ut. Hvis jeg vil at den skal se ut på en annen måte formaterer jeg den om med en pretty-printer.

[....]

 

Tabs har det fortrinnet at man kan få akkurat det innrykket man foretrekker ved å justere tab-bredden, men for at dette skal fungere må følgende være oppfylt:

 

• Tabs skal bare brukes på begynnelsen av linjer.
  
• Antallet tabs skal samsvare med innrykkingsnivået, dvs. én tab per nivå.
  

I Visual Studio får man dette ved å sette «Tab Size» lik «Indentation Size». I Emacs, Vim og andre programmer som bruker en mer forfinet innrykkingsstil, må man være oppmerksom på følgende:

 

if(foo) {
   char quux[4] = {0, 1,
                   2, 3};
}

Her får fortsettelseslinjen en blanding av «indentation» og «alignment». Smart Tabs (Emacs) / Indent with tabs, align with spaces (Vim) sørger automatisk for riktig formatering:

 

if(foo) {
--->char quux[4] = {0, 1,
--->................2, 3};
}

Visual Studio har en enklere stil hvor fortsettelseslinjen rykkes inn et helt ekstra «nivå», og omgår dermed problemet.

Endret 3. januar 2012 av ....

[....]

For dem som ønsker en kort, grafisk innføring i lokal versjonskontroll, har jeg skrevet et par innlegg:

 

• Innføring i versjonskontroll
  
• Fordeler med versjonskontroll
  

Eksemplet bruker Git og TortoiseGit, men man kan like godt bruke Mercurial og TortoiseHg.

Endret 3. januar 2012 av ....

[asicman]

For dem som ønsker en kort, grafisk innføring i lokal versjonskontroll, har jeg skrevet et par innlegg:

 

Veldig bra beskrivelse for å få folk i gang med revisjonskontrollsystem. Jeg er også GIT fan. Har brukt en del revisjonskontrollsystemer opp gjennom årene SCCS (slutten av 80-tallet), RCS, CVS, SVN og nå GIT (har også brukt Darcs og Mercurial i mindre grad).

 

Men det er mer optimalt å bruke disse inne fra Emacs (forstår at du ikke har med det i din tutorial siden det ville sikker forvirre mange ikke-Emacs brukere). Personlig så liker jeg egg (Emacs Got Git). Det er utrolig effektivt å kunne sjekke inn (C-x v i), logge (C-x v l), diffe (C-x v =), gjøre commit (C-x v w), lage brancher (b), sjekke ut brancher (o), pushe (U) osv. inne fra Emacs uten å måtte gå ut til et annet program for å gjøre dette.

[....]

Veldig bra beskrivelse for å få folk i gang med revisjonskontrollsystem.

Takk!

 

Men det er mer optimalt å bruke disse inne fra Emacs (forstår at du ikke har med det i din tutorial siden det ville sikker forvirre mange ikke-Emacs brukere).

Ja, den er eksplisitt rettet mot nybegynnere (pek og klikk), så det gjøres ikke noe poeng ut av at jeg bruker Emacs. Men når man har det grunnleggende inne, bør man selvsagt se etter integrert støtte i programmene man bruker (og Emacs har veldig god Git-støtte).

 

For øvrig kan man i prinsippet versjonskontrollere hva som helst (skjønt diffing/merging begrenser seg til tekstbaserte formater), og veiledningen er da også postet i en LaTeX-tråd. (Versjonskontroll er ikke bare for programmerere!)

Endret 3. januar 2012 av ....

[tickinghd]

Er det stor forskjell på å stage og å bruke "externals" i GIT contra SVN? Er arbeidsflyten så lik på dette området at det er raskt å plukke opp?

 

Bruker SVN selv av gammel vane, og samt at andre jeg jobber med bruker det, men er i en situasjon hvor GIT kan vurderes innført.

[asicman]

Hvis du bruker CLI verktøyene så er det ikke stor forskjell. Det tar kanskje litt tid å venne seg til terminologien. Det er mange bra GIT tutorials på nettet.

 

Du kan også bruke GIT som front-end til SVN.

 

git svn clone svn://svn/url/til/ditt/repo repo.git

 

vil gi deg et git repo som er en kopi av svn (det tar litt tid første gangen siden du tar med all historien slik jeg har vist ovenfor). Du kan da gjøre:

 

git branch mitt-super-hack
git checkout mitt-super-hack

edit
hack
edit

git commit -a -m "my wonderful hack"

git log

git checkout master
git merge mitt-super-hack
git branch -D mitt-super-hack

git svn rebase  # henter inn endringer fra svn
git svn dcommit # gjør commit i mot svn

 

Skrevet fra hukommelsen vær obs for mulige feil da jeg stort sett gjør dette i fra egg i Emacs.