ProgrammeringsBaren! Småprat, om det du elsker!

[siDDis]

La oss si at du endrer klassenamnet. Så vil ein god refaktoreringsimplementasjon endre dette klassenamnet i alle filene i prosjektet ditt. Inkl tester.

 

Og kodeanalyse sjekker ofte mykje meir enn banalt enkle ting. Den kan f.eks plukke opp at databasespørringa di er uoptimal og at du bør endre denne med eit løysningsforslag.

Eit kodeanalyseverktøy er realtime code review. Alle, uansett kor gode dei er, skriver dårleg kode innimellom.

 

Dei hjelper og med å passe på at du følgje ein felles standard når det kjem til variabel/metodenamn, at du formaterer koden med riktige mellomrom og linjeskift her og der.

[Matsemann]

Når vi er inne på det: hva er det egentlig IDE-refactor gjør for noe? Search-and-replace på signaturer?

Nja. Det også. Ved renaming osv. gjør den nok bare det pluss cascading av litt småtteri (basert på semantikken han nevner) (oppdaterer navnene på gettere og settere til fielden som ble endret igjennom hele kodebasen, oppdatere kommentarer, xml/config-filer o.l.).

 

Men det de gjør veldig bra er "extracting" av kode. Dra ut funksjonalitet til egne klasser. F. eks. lage en subklasse med akkurat denne funksjonaliteten, eller dytte funksjonaliteten opp i en superklasse. Eller splitte det ut i en helt annen klasse om det er noe som er urelatert til klassen den ligger i.

 

En annen extract er å markere en blokk med kode inni en metode/funksjon, og extracte den delen til en ny metode. Altså bryte en stor metode ned i mindre metoder. IDEet passer på at ting forblir ekvivalent, altså at den nye metoden får variablene den trenger og at ting i den originale metoden fortsatt får verdiene det skulle.

 

Småting så klart, som kan gjøres manuelt, men et IDE klarer å se det i forhold til hele kodebasen bedre enn et menneske, og ting holdes derfor konsistent og ting breakes ikke i prosessen.

 

Det er også mange småting jeg bruker oftere, men de kan nok oppnås uten et IDE. I hvert fall i stor grad. F. eks. å flytte en lokal variabel inni en metode opp på klassenivå kan nok gjøres rett frem uten at man trenger hele analyseverktøyet i IDEet, holder med en simpel regex som leser riktige verdier ut i fra den eksisterende deklarasjonen og slenger den ut.

[Lycantrophe]

La oss si at du endrer klassenamnet. Så vil ein god refaktoreringsimplementasjon endre dette klassenamnet i alle filene i prosjektet ditt. Inkl tester.

Dette problemet dukker opp ofte? Og dette er jo en S&R. Og ikke noe jeg vil kalle refactoring.

 

Og kodeanalyse sjekker ofte mykje meir enn banalt enkle ting. Den kan f.eks plukke opp at databasespørringa di er uoptimal og at du bør endre denne med eit løysningsforslag.

Så ca. static analysis. Dette finnes det jo verktøy for som ikke er embedded i IDEer og.

 

(ikke at jeg har vært borti den situasjonen før, men det er mest fordi jeg ikke skriver queries)

 

Dei hjelper og med å passe på at du følgje ein felles standard når det kjem til variabel/metodenamn, at du formaterer koden med riktige mellomrom og linjeskift her og der.

Yeah. Det er en editor-jobb. Og det er får IDEer jeg vet om med gode editors.

[Lycantrophe]

Nja. Det også. Ved renaming osv. gjør den nok bare det pluss cascading av litt småtteri (basert på semantikken han nevner) (oppdaterer navnene på gettere og settere til fielden som ble endret igjennom hele kodebasen, oppdatere kommentarer, xml/config-filer o.l.).

Metoder forandrer jo ikke navn ved klasse-navn-endring, men det kan bare være en svak formulering. Still, renaming vil jeg ikke kalle refactoring, hvertfall ikke på egen hånd.

 

Men det de gjør veldig bra er "extracting" av kode. Dra ut funksjonalitet til egne klasser. F. eks. lage en subklasse med akkurat denne funksjonaliteten, eller dytte funksjonaliteten opp i en superklasse. Eller splitte det ut i en helt annen klasse om det er noe som er urelatert til klassen den ligger i.

Er ikke disse tingene allerede samlet i blokker? Jeg kan vel se hvorfor det kan være nyttig, men når/om jeg gjør slikt markerer jeg bare blokken og flytter direkte.

 

En annen extract er å markere en blokk med kode inni en metode/funksjon, og extracte den delen til en ny metode. Altså bryte en stor metode ned i mindre metoder. IDEet passer på at ting forblir ekvivalent, altså at den nye metoden får variablene den trenger og at ting i den originale metoden fortsatt får verdiene det skulle.

Dere har for store funksjoner! :---D

 

Men igjen, samme situasjon. På grunn av blokk-samling, er dette noe mer enn en mark-kill-paste-sykel? Minus det å flytte cursor, men det er jo en lek i en skikkelig editor uansett.

 

Småting så klart, som kan gjøres manuelt, men et IDE klarer å se det i forhold til hele kodebasen bedre enn et menneske, og ting holdes derfor konsistent og ting breakes ikke i prosessen.

Jeg har sett IDE-kode. Det er ikke nødvendigvis konsistent. :--) Og kan den garantere at logikk ikke breakes?

[GeirGrusom]

Utdyp, er du snill, for dette betyr ca. ingenting.

edit: jeg kan ikke være noe dårligere her selv. Ok, la oss anta den forstår semantikken i koden; hvordan kan den bruke dette? Nøyaktig hva er det den får til som gjør at det blir refactor?

Kan bruke ReSharper som jeg benytter i Visual Studio som eksempel. Dette er et refaktoeringsverktøy som kommer som en plug-in til Visual Studio (som har noe refaktoreringsverktøy, men disse går ikke lenger enn rename og extract method)

 

ReSharper kan gjøre analyse av koden og fortelle deg eksempelvis i følgende:

 

public IEnumerable<T> DoIterationThing<T>(IList<T> list)
{
  foreach(var item in list)
    yield return DoFoo(item);
}

I dette tilfellet så kan resharper fortelle deg to ting: list trenger ikke være av typen IList<T>: det kan bedre uttrykkes som IEnumerable<T>.

 

I tillegg kan den også foreslå at uttrykket også kan være et LINQ uttrykk:

 

from item in list select DooFoo(item);

Det kan også uttrykkes som et enkelt Select uttrykk:

 

list.Select(DoFoo);

public IEnumerable<T> DoIterationThing<T>(IEnumerable<T> list)
{
  return list.Select(DoFoo);
}

I tillegg vil resharper advare deg mens du skriver om du bryter navnekonvensjoner.

 

I C# 4.0 er det en bug i closure implementasjonen som gjør at scoping av variabelen går utenfor som fører til at closuren lukker om feil verdi. Dette advarer resharper deg om, og vil foreslå en fiks.

 

Den advarer også mot gjentatte reiterasjoner av IEnumerable<T> (ettersom dersom dette kan enten feile eller føre til at utregnignene blir gjort dobbelt opp)

 

Man kan si dette er programmeringsfeil, men det er ekstremt nyttig funksjonalitet som bedrer kodekvalitet, både funksjonelt og estetisk.

 

En kan også nevne en annen nyttig sak som heter NCrunch som i Visual Studio vil kontinuerlig kjøre unit-tester for koden du skriver og vil vise i margen dersom du gjør en endring som fører til at testen feiler. Den viser også full code-coverage kontinuerlig.

 

Så jeg er fullstendig for bruk av IDE-er.

Endret 27. september 2013 av GeirGrusom

[Matsemann]

Metoder forandrer jo ikke navn ved klasse-navn-endring, men det kan bare være en svak formulering. Still, renaming vil jeg ikke kalle refactoring, hvertfall ikke på egen hånd.

Jeg nevnte ingenting om klasse-renaming. siDDis gjorde, men jeg skrev mitt innlegg før jeg så hans.

Er ikke disse tingene allerede samlet i blokker? Jeg kan vel se hvorfor det kan være nyttig, men når/om jeg gjør slikt markerer jeg bare blokken og flytter direkte.

Jo, i en perfekt verden. Men det er jo en grunn til man refaktorerer.

 

Jeg har sett IDE-kode. Det er ikke nødvendigvis konsistent. :--) Og kan den garantere at logikk ikke breakes?

Der IDEA er usikker på hva den skal gjøre sier den i fra. Så klart kan noe breake, men da ikke pga at IDEet gjøre noe feil, men fordi det får utilsiktete konsekvenser.

 

Men som jeg skrev, mye av dette kan gjøres ved S&R med støtte for regex og å bruke matchede verdier. Men da må du skrive disse selv.

Det er også tilfeller der S&R ikke holder, basert på semantikken.

F. eks:

Car something1 = new Car();
Door something2 = new Door();
something1.unlock();
something2.unlock();

Om du renamer unlock på Car klassen, hvordan skal S&R finne ut om dette skal gjøres på something1 og ikke something2?

[Lycantrophe]

Kan bruke ReSharper som jeg benytter i Visual Studio som eksempel.

Supert.

 

[...]

 

from item in list select DooFoo(item);

Det kan også uttrykkes som et enkelt Select uttrykk:

 

 

Nå snakker vi. Dette er en kurant feature, men jeg ser ikke hvorfor den må være knyttet til et IDE. Jeg mener, dette kan fint sees på som static analysis. Jeg synes sånt er plagsomt om det kjøres kontinuerlig, og foretrekker å gjøre slikt i batches. Men fint; dette er også slikt som gir refactor-uttrykket mening.

 

 

I tillegg vil resharper advare deg mens du skriver om du bryter navnekonvensjoner.

Det løser jeg ved å ha ikke-retarded navnekonvensjoner :-----------D

 

 

 

I C# 4.0 er det en bug i closure implementasjonen som gjør at scoping av variabelen går utenfor som fører til at closuren lukker om feil verdi. Dette advarer resharper deg om, og vil foreslå en fiks.

Ok, men dette er ting som fint kan ligger i compilers og annet også. Eller static-analysis-tools. Det er forøvrig ikke en refactor-feature.

 

 

 

Man kan si dette er programmeringsfeil, men det er ekstremt nyttig funksjonalitet som bedrer kodekvalitet, både funksjonelt og estetisk.

Jeg vil klassifisere det under programmeringsfeil, ja, men det er jo trivelig med tools som plukker det opp. For min del ikke i editoren, men to each his own.

 

 

 

En kan også nevne en annen nyttig sak som heter NCrunch som i Visual Studio vil kontinuerlig kjøre unit-tester for koden du skriver og vil vise i margen dersom du gjør en endring som fører til at testen feiler. Den viser også full code-coverage kontinuerlig.

 

Tar ikke dette uhorvelig med ressurser og kan føre til stalls?

 

 

Jeg nevnte ingenting om klasse-renaming. siDDis gjorde, men jeg skrev mitt innlegg før jeg så hans.

Fair enough, sikkert jeg som rører.

 

 

Jo, i en perfekt verden. Men det er jo en grunn til man refaktorerer.

Skaff bedre teammates :--)

Endret 27. september 2013 av Lycantrophe

[GeirGrusom]

Nå snakker vi. Dette er en kurant feature, men jeg ser ikke hvorfor den må være knyttet til et IDE. Jeg mener, dette kan fint sees på som static analysis. Jeg synes sånt er plagsomt om det kjøres kontinuerlig, og foretrekker å gjøre slikt i batches. Men fint; dette er også slikt som gir refactor-uttrykket mening.

Det kunne vært statisk analyse ja, men poenget med et IDE er absolutt å effektivisere arbeidsprosessen, og det å ha alt man trenger av analyseverktøy tilgjengelig øyeblikkelig og kontinuerlig ser jeg på som en fordel.

 

 

Det løser jeg ved å ha ikke-retarded navnekonvensjoner :-----------D

Tja, fort gjort for eksempel å glemme _ foran en privat variabel (dersom det er navnekonvensjonen)

 

 

Ok, men dette er ting som fint kan ligger i compilers og annet også. Eller static-analysis-tools. Det er forøvrig ikke en refactor-feature.

Ja absolutt. Compileren burde sagt ifra, og feilen er rettet i C# 5.0 (ettersom det er ingen tilfeller hvor denne oppførselen faktisk er ønskelig). Mne når compileren ikke gjør det er det greit å ha et IDE som gjør det for deg med en blå linje under closuren.

 

Jeg vil klassifisere det under programmeringsfeil, ja, men det er jo trivelig med tools som plukker det opp. For min del ikke i editoren, men to each his own.

Jeg arkiverer det under effektivitet.

 

Tar ikke dette uhorvelig med ressurser og kan føre til stalls?

Har ikke opplevd hverken stalls eller at det tar mye ressurser, men regner med dette har med kvaliteten på unit-testene å gjøre. En unit-test burde ikke bruke stort mer enn et millisekund på å kjøre. Den kjører også bare tester som har code-coverage der man redigerer, men så fort man skriver noe så kjører den testene som dekker området på nytt. Dersom disse av en eller annen grunn går mot databaser så får man vel treg respons fra NCrunch, i verste fall kræsjer test-runneren, men det skal ikke føre til stalls i selve IDE-et.

 

Alle disse tingene kunne vært gjort av separate verktøy, men poenget med verktøyene er å gjøre hverdagen enklere og øke effektivitet og bedre kodekvalitet, og ved at man øyeblikkelig ser analyseresultater rett i verktøyet du jobber i ser jeg på som en utelukkende fordel.

Endret 27. september 2013 av GeirGrusom

[Lycantrophe]

Det kunne vært statisk analyse ja, men poenget med et IDE er absolutt å effektivisere arbeidsprosessen, og det å ha alt man trenger av analyseverktøy tilgjengelig øyeblikkelig og kontinuerlig ser jeg på som en fordel.

Det er greit nok; jeg er ikke i den grupppen. Jeg synes slikt er i veien (mest fordi de har en tendens til å kicke inn før jeg faktisk er ferdig med å skrive) og foretrekker å ha de for seg selv. Do one thing etc.

 

Tja, fort gjort for eksempel å glemme _ foran en privat variabel (dersom det er navnekonvensjonen)

Det vil jeg tro. Jeg liker ikke _-notasjon. Jeg foretrekker eksplisitt this->, av flere grunner. Still, jeg synes det er irriterende, spesielt fordi det kan være at jeg ønsket en lokal (med samme navn som den private).

 

De smarte ser vel at dersom en ikke-prefikset er i scope så skriker de ikke, men likevel.

 

Ja absolutt. Compileren burde sagt ifra, og feilen er rettet i C# 5.0 (ettersom det er ingen tilfeller hvor denne oppførselen faktisk er ønskelig). Mne når compileren ikke gjør det er det greit å ha et IDE som gjør det for deg med en blå linje under closuren.

Greit nok. Men med dette knyttes verktøyet for min del for tett til språket. Eksempel: jeg bruker vim til mer enn C++.

 

Jeg arkiverer det under effektivitet.

Jeg arkiverer det under ikke-gjøre-feil. :--------D

 

Har ikke opplevd hverken stalls eller at det tar mye ressurser, men regner med dette har med kvaliteten på unit-testene å gjøre.

Eller maskinen du sitter på. :>

 

Den kjører også bare tester som har code-coverage der man redigerer, men så fort man skriver noe så kjører den testene som dekker området på nytt.

Dette er ikke like greit i språkene jeg stort sett bruker, men kult nok.

 

Dersom disse av en eller annen grunn går mot databaser så får man vel treg respons fra NCrunch, i verste fall kræsjer test-runneren, men det skal ikke føre til stalls i selve IDE-et.

Bra.

[tomsi42]

Skal du skrive fin kode er det best å ikke bruke en IDE.

Oksebæsj.

 

Skal du skrive fin kode, så skal du vite hva holder på med, enten du bruker en IDE, vi, emacs eller ed.

Endret 29. september 2013 av tomsi42

[Foxboron]

Oksebæsj.

 

Skal du skrive fin kode, så skal du vite hva holder på med, enten du bruker en IDE, vi, emacs eller ed.

 

Bare jeg som sverger til ed?

[tomsi42]

 

Bare jeg som sverger til ed?

Tror du er med i en liten ekslusiv klubb der, ja

[banansplitt™]

Har etterhvert laget noen klasser som begynner å inneholde veldig mange metoder. Er det noen spesiell måte det er vanlig å sortere disse metodene på? Alfabetisk?

 

EDIT: I dette tilfellet er det snakk om Java, hvis det skulle ha noen betydning.

Endret 16. november 2013 av banansplitt™

[Lycantrophe]

Lag mindre klasser. :-----)

[banansplitt™]

Spørsmålet står fortsatt, uavhengig av hvor mange metoder det er.

[tomsi42]

Min erfaring er at det kan være lettere å gruppere funksjoner som har noe felles. Et godt utviklngsverktøy viser deg en sortert liste over funksjonene uansett.

[Lycantrophe]

Spørsmålet står fortsatt, uavhengig av hvor mange metoder det er.

Jeg grupperer etter funksjons-"familier". Ting som beregner lignende ting samles.

 

Nå er ikke det like problematisk i C++ ettersom C++ har headere. I selve implementasjonsfilene er det litt både-og hvordan jeg gjør det. Noen ganger splitter jeg i flere. Som regel prøver jeg å definere de i samme rekkefølge de står i headeren.

Endret 17. november 2013 av Lycantrophe

[Leif-Reidar]

Jeg grupperer etter funksjons-"familier". Ting som beregner lignende ting samles.

 

Nå er ikke det like problematisk i C++ ettersom C++ har headere. I selve implimentasjonsfilene er det litt både-og hvordan jeg gjør det. Noen ganger splitter jeg i flere. Som regel prøver jeg å definere de i samme rekkefølge de står i headeren.

Hva er en implementasjonsfil, og hva vil det si å implementere?

[Occi]

.h er header, .cpp er for implementasjonen

[Matsemann]

Har etterhvert laget noen klasser som begynner å inneholde veldig mange metoder. Er det noen spesiell måte det er vanlig å sortere disse metodene på? Alfabetisk?

 

EDIT: I dette tilfellet er det snakk om Java, hvis det skulle ha noen betydning.

Vanligste er å sortere slik at relaterte metoder kommer etter hverandre. F. eks. om metode A kaller metode B og C, og metode C kaller D, legger man de A, B, C, D, så det blir lettere å "lese" koden nedover. Her snakker man også om "vertikal distanse", relatert kode bør ligge nærme.

 

Men enig med lycan. Grupperer du metodene slik jeg beskrev nå, og du ser mange av metodene kun brukes av noen få metoder og har liten tilknytning til resten kan det nok splittes ut til en ny klasse.