C#: Skrive kode selv eller bruke WYSIWYG-program?

[ilpostino]

jeg begyynte å programmere Java på Unix og er derfor vandt til å skrive all kode selv uansett hvilkent språk jeg holder på meg. Med Visual Studio er det klipp og lim (med unntak av når en skal oppdatere databaser som eneste tilfelle hvor en må inn å kode selv) har jeg inntrykk av.

 

hva er det mest vanlige blandt folk som bruker C# egentlig?

[HDSoftware]

jeg begyynte å programmere Java på Unix og er derfor vandt til å skrive all kode selv uansett hvilkent språk jeg holder på meg. Med Visual Studio er det klipp og lim (med unntak av når en skal oppdatere databaser som eneste tilfelle hvor en må inn å kode selv) har jeg inntrykk av.

 

hva er det mest vanlige blandt folk som bruker C# egentlig?

Jeg uenig at det er klipp og lim i VS. At VS generer en del ferdig kode for deg er en annen ting, men dette er høyest frivillig. Klipp og lim resulterer også i en håpløs debug situasjon fordi man må rette samme feilen flere steder

 

VS er jo et integrert utviklingsmiljø som gir deg alt du trenger, fra enkle console programmer til store flerbrukersystemer mot SQL, WEB og hva det måtte være. Når du trekker en kontroll fra en kontroll meny over i vinduet så genereres all koden som skal til for å posisjonere og behandle denne kontrollen. Tilsvarende kan man ha komponenter som gjør at du kan lage en samling av kontroller og klasser som har spesielle gjøremål. Utover dette må man selv skrive koden som gjør at kontrollen og klassene faktisk har nytteverdi.

 

Selv kommer jeg fra et helt annet miljø der Clarion er i fokus. Dette er også et system basert på templater, slik som VS, men forskjellen er at templatene er interaktive på den måten at man midt i den genererte koden kan legge sin egen kode, noe vi kaller EMBEDPOINTS.

 

For å svare konkret på spørsmålet ditt så er i hvertfall jeg vant til å få mye servert på et fat. Jeg finner dette absolutt nødvendig fordi skal man være konkurransedyktig i markedet må man kunne levere kjappt, trygt og billig.

For meg blir det helt håpløst hvis jeg måtte kodet alt fra bunnen av. Det har hverken jeg eller kunden tid til.

Videre er jeg avhengig av et godt TEMPLATE system. Clarion har et slikt et og VS begynner å komme seg veldig. f.o.m. VS.NET blei template systemet mye bedre og Clarion fikk seg en konkurrent, selv om template systemet i Clarion fortsatt ligger noe foran. Faktisk ganske mye foran.

 

Bare for morroskyld så klistrer jeg inn en enkel template kode her:

 

 

 

#CODE('En kul kodetemplate som smeller opp en messagebox')
#SHEET
 #TAB('Generellt')
#PROMPT('Meldingshodet:',@s30),%Meldingshodet
#PROMPT('Meldingen:',@s256),%Meldingen
 #ENDTAB
 #TAB('Hendelser')
#PROMPT('Bruke JA/NEI',check),%BrukJANEI
#boxed,Section
  #boxed('Bruke JA/NEI'),where(%BrukJANEI = %TRUE),at(10)
	#PROMPT('Prosedyre som skal kalles hvis ja:',PROCEDURE),%ProsedyreSomKalles
  #endboxed
  #boxed('Ingen handling'),where(%BrukJANEI = %FALSE),at(10)
  #endboxed
#Endboxed
 #ENDTAB
#ENDSHEET
!--< Template generert kode >--
#if(%BrukJANEI)
if Message(%Meldingen,%MeldingsHodet,,BUTTON:Yes+BUTTON:No) = BUTTON:Yes
 #EMBED(%FørProsedyrekall)
 %ProcedureSomKalles
 #EMBED(%EtterProsedyrekall)
End!if
#Else
Message(%Meldingen, %MeldingsHodet)
#EMBED(%VanligMessage)
#EndIf

#EMBED kommandoene gir steder i selve applikasjonen der jeg kan legge inn egen kode som påvirker programmet.

Ganske genialt og absolutt noe jeg savner i Visual Studio

Faktisk kan man lage templater i Clarion som genererer C# kode uten problemer, noe et nederlandsk firma beviste da de laget noe som de kallte Clarion.NET. Produktet gjorde at Clarion utviklingssystem genererte ren C#, JAVA eller VB.NET kode. Måtte selvsagt kompilleres i egnet kompilator.

 

 

 

Eneste grunnen til at jeg gikk over til C#/.NET er rett og slett støtten for .NET. Kunder er rare, de skal på død og liv ha .NET baserte løsninger. Ikke fordi de trenger det, men fordi det er det som gjelder

[GeirGrusom]

Jeg bruker Visual Studio, og grunnen er at Visual Studio slår opp funksjonsdefinisjoner og medlemmer i klasser og strukturer mens du skriver. Sparer programmereren for timesvis med arbeid i dokumentasjonen til det du holder på med.

 

Skjønner ikke helt hvordan det er klipp og lim though... alt skrives jo fremdeles, men med autocomplete, kommer en seg litt raskere fremover.

[Manfred]

Jeg kan heller ikke se at man kan si at "Med Visual Studio er det klipp og lim". Jeg kan ikke huske å ha klippet og limet en eneste funksjon.

[ilpostino]

var på en demo av Visual Studio 2008 her for et par måneder siden. det var ikke mange linjene med kode foredragsholderen skrev iløpet av den dagen.

[ze5400]

Standard salgstriks

 

For hver nye utgave lover de jo at "gjør det samme med 30% mindre kode" eller noe.

 

De skylder jo nesten kode nå

 

 

Selv fatter jeg ikke hva du mener med klipper/limer.

 

Jeg bruker WYSIWYG til å sette opp forms, men utover det skriver jeg koden selv.

 

Vet dog om noen som klipper og limer som helter. Gjerne fra andres prosjekter. Trenger jeg å si at de alltid har problemer med å få det til å virke riktig? ...

[HDSoftware]

var på en demo av Visual Studio 2008 her for et par måneder siden. det var ikke mange linjene med kode foredragsholderen skrev iløpet av den dagen.

Alle foredrags holdere gjør dette, nettop fordi det ellers ville tatt for lang tid å holde et foredrag. Bare ta en titt på alle online video seminarene på asp.net så ser du at de gjør det der også. Det er nemlig utrolig kjedelig å se en foredragsholder skrive kode, spesiellt hvis han/hun gjør en feil og må rette på ting hele tiden. Hele fokuset på foredraget forsvinner liksom ut i det grå.

 

Jeg vil si det er å foretrekke uavhengig av utviklingsspråg ;-)

[Lachrymol]

Hei på deg.

 

Jeg er også utdannet med Java i Linux-miljø, men jobber nå med Visual Studio/C#

 

Personlig setter jeg kjempepris på VS, for det gjør hverdagen mye enklere. Du slipper å huske/slå opp masse syntaks, og kan konsentrere deg om det som faktisk er morsomt med programmering (logikk og struktur).

 

Som nevnt over får du en del gratis ved design av Windows Forms og denslags i form av WYSIWYG editor. I starten var jeg skeptisk til denne selv, for tidligere har slike editorer ofte laget dårlig kode (HTML i Word anyone?) I VS derimot blir koden stort sett ryddig og fin, og du kan selv gå inn og ordne på alt du vil etterpå (noe du sjelden trenger. En annen nifty ting i VS er såkalte "partial classes", dvs at samme klasse fordeler seg over flere dokumenter. Dermed havner den autogenererte koden, som du sjelden trenger å røre, i et eget dokument, mens all koden du lager selv kommer i et annet. Høres kanskje rotete ut her, men det er veldig oversiktlig og fungerer veldig bra).

 

Så for min egen del lager jeg fortsatt minst like mye kode "for hånd", men VS gjør det mye enklere for deg. Når du for eksempel jobber med et objekt, får du opp en drop-down liste med alle tilgjengelige metoder i den klassen. På den måten slipper du å slå opp i API'er på web for å finne tilgjengelige metoder på klassens osv, samt at faren for syntaksfeil (skrivefeil) forsvinner.

 

Merk at denne funksjonaliteten får du også i Eclipse og IntelliJ som er rettet mot Java, så om du har lyst å forstette med det, men er LITT lei av å trulte rundt i Emacs, kan det anbefales. Eclipse er gratis.

 

Men når det er sagt, så trives jeg veldig godt med både C# og Visual Studio, så jeg kan trygt anbefale å laste ned Express Edition av Visual Studio (nedstrippa, gratis versjon) og leke litt rundt. Syntaktisk er Java og C# VELDIG like, så du burde komme greit inn i det.

[HDSoftware]

Siden du nevner partial classes

 

Hva er poenget egentlig med Partial Classes? jeg ser jo muligheten til å spre klassen ut over flere dokumenter, men er ikek dette egentlig bare det samme som vanlige klasser?

public partial class Klasse1
{
 public void Metode1()
 {
 }
}

public partial class Klasse1
{
 public void Metode2()
 {
 }
}

mot

public class Klasse1
{
 public void Metode()
 {
 }
}

public class Klasse2 : Klasse1
{
 public void Metode2()
 {
 }
}

 

Ser ikke helt forskjellen annet en at man har muligheten til å bruke PARENT metoder og egenskaper i sistnevnte metodikk. Derfor - hvorfor er PARTIAL så kult?

[Lachrymol]

Poenget med det er bare å skille maskingenerert kode fra den du skriver selv. Om du er inne og kikker i desginerfila som VS lager for deg når du lager Forms med WYSIWYG, så blir den ofte svær og er litt tunglest (selv om koden forsåvidt er "bra" jfr det jeg skrev over. Er bare det at GUI-progging trenger så mange linjer).

 

Poenget med partial classes er bare å holde det maskinen lager for deg utenfor, så du kan konsentrere deg om den koden du lager selv og har oversikt over.

 

Har ingenting med funksjonalitet eller muligheter i språket å gjøre. Vil ikke si det er så inmari "kult", men det er sabla praktisk å slippe å ha GUI kode og businessregler om hverandre i samme dokument.

Endret 30. juli 2008 av Lachrymol

[HDSoftware]

Poenget med det er bare å skille maskingenerert kode fra den du skriver selv. Om du er inne og kikker i desginerfila som VS lager for deg når du lager Forms med WYSIWYG, så blir den ofte svær og er litt tunglest (selv om koden forsåvidt er "bra" jfr det jeg skrev over. Er bare det at GUI-progging trenger så mange linjer).

 

Poenget med partial classes er bare å holde det maskinen lager for deg utenfor, så du kan konsentrere deg om den koden du lager selv og har oversikt over.

 

Har ingenting med funksjonalitet eller muligheter i språket å gjøre. Vil ikke si det er så inmari "kult", men det er sabla praktisk å slippe å ha GUI kode og businessregler om hverandre i samme dokument.

Så det er altså kun for å ha det i flere dokumenter. Jeg ser allikevel ikke gevinsten. I Clarion, som er det jeg har drevet med for det meste, så er mesteparten av kode generert av templater. Dette skaper ingen problemer med manglende oversikt i det hele tatt, av følgende grunn:

Alle grunnklasser er definert i egne dokumenter, kalt ABC (Application Builder Classes). På dette så har vi templater som genererer INC og CLW filer. Men, når jeg f.eks. dobbeltklikker på en knapp i skjerm editoren, så kommer jeg inn i en egen separat editor(eget dokument), der jeg kan skrive koden som håndterer eventet på knappen. Denne koden blir da generert som en VIRTUAL metode i klassen som benyttes. Akkurat det samme gjør jo Visual Studio. Når man dobbeltklikker på en knapp der så kommer en editor opp med ferdig prototypet metode. Ser jo at klassen i dette dokumentet er partial, men kunne den ikke like gjerne vert nedarvet? Hva skjer f.eks. om jeg lager en metode som tilfeldigvis har samme signatur som en av metodene som allerede er ferdigdefinert? Får jeg ikke problemer da? Med arving vil aldri dette være et problem, nettopp fordi man da kan skille på metodikken som ligger til grunn og den metodikken man selv velger. Men det er fullt mulig jeg har missforstått noe her altså ;-)

[Lachrymol]

Ser jo at klassen i dette dokumentet er partial, men kunne den ikke like gjerne vert nedarvet? Hva skjer f.eks. om jeg lager en metode som tilfeldigvis har samme signatur som en av metodene som allerede er ferdigdefinert? Får jeg ikke problemer da? Med arving vil aldri dette være et problem, nettopp fordi man da kan skille på metodikken som ligger til grunn og den metodikken man selv velger. Men det er fullt mulig jeg har missforstått noe her altså ;-)

 

Nei, det vil jo ikke gå for du er i samme klassen.

 

Poenget er at dette egentlig ikke handler om C#; det er egentlig en Visual Studio feature som tilfeldigvis krever et lite ord med i koden.

 

En partial class er akkurat som en helt vanlig klasse; du kan arve og styre og gjøre akkurat som før, det er bare at VS skiller ut den koden den selv genererer i et eget dokument. Den antar vel at når noen først lager noe med editoren, er det vel fordi de ikke har lyst til å sitte og dille med kode.

Endret 30. juli 2008 av Lachrymol

[Glenn F. Henriksen]

Hva er poenget egentlig med Partial Classes? jeg ser jo muligheten til å spre klassen ut over flere dokumenter, men er ikek dette egentlig bare det samme som vanlige klasser?

I eksempel nr to lager du en ny klasse og alle referanser må referere til den nye klassen din. I eksempel nr en utvider du den eksisterende klassen og alle referanser består. Du kan oppnå noenlunde de samme tingene både med partial klasser og med arvede klasser, det er bare to forskjellige veier til Rom. De overlapper mye og har et par små forskjeller.

 

I en partial klasse har du også tilgang til private variabler fra "hovedklassen", det har du ikke med arv.

 

Partial klasser kan også brukes til å strukturere koden din litt, hvis du f.eks. har en klasse som implementerer mange interfaces så kan du legge hver interface implementasjon i sin egen fil.

 

Hvis du får generert en førti, femti klasser (eller mer) så er det veldig greit å bruke partial klasser for å utvide disse. Det gjør nemlig namespacene dine mye mer ryddige, du slipper en masse MinKlasseBase klasser som ikke skal brukes til noenting.

[HDSoftware]

Hva er poenget egentlig med Partial Classes? jeg ser jo muligheten til å spre klassen ut over flere dokumenter, men er ikek dette egentlig bare det samme som vanlige klasser?

I eksempel nr to lager du en ny klasse og alle referanser må referere til den nye klassen din. I eksempel nr en utvider du den eksisterende klassen og alle referanser består. Du kan oppnå noenlunde de samme tingene både med partial klasser og med arvede klasser, det er bare to forskjellige veier til Rom. De overlapper mye og har et par små forskjeller.

 

I en partial klasse har du også tilgang til private variabler fra "hovedklassen", det har du ikke med arv.

 

Partial klasser kan også brukes til å strukturere koden din litt, hvis du f.eks. har en klasse som implementerer mange interfaces så kan du legge hver interface implementasjon i sin egen fil.

 

Hvis du får generert en førti, femti klasser (eller mer) så er det veldig greit å bruke partial klasser for å utvide disse. Det gjør nemlig namespacene dine mye mer ryddige, du slipper en masse MinKlasseBase klasser som ikke skal brukes til noenting.

Heisan. Mange gode poeng. Selv har jeg også kommet over en veldig fint ting med dette og det er å lage en egen BASE class for vinduer som trenger grunnfunksjonalitet. Eksempelvis har jeg laget en BASE class for mine WEB Forms som styrer session variabler. Faktisk ganske genialt. I Clarion har jeg lenge savnet en måte å gjøre dette på. Jeg har selvsagt kunnet lage min egen såkallte WindowManager Class som arver Clarion sin WindowManager class, men den som leveres med Clarion har en hel drøss med private metoder som jeg skulle hatt tak i, hvilket er umulig uten PARTIAL.

[teflonpanne]

Jeg syns editorer som emacs eller vim + et skikkelig shell + hundrevis av små programmer er utrolig mye kraftigere og fleksibelt enn et WYSIWYG-miljø. Litt brattere læringskurve, men når man begynner å få oversikten over alt sammen så er man mye mer effektiv. Nå skriver jeg veldig sjeldent GUI-programmer, men hvis jeg skulle gjort det så hadde jeg nok kanskje brukt forms-editoren (er det ikke det det heter?) til VS til gui-ting, men til alt annet hadde jeg nok fortsatt foretrukket et unix-liknende utviklingsmiljø.

[HDSoftware]

Jeg syns editorer som emacs eller vim + et skikkelig shell + hundrevis av små programmer er utrolig mye kraftigere og fleksibelt enn et WYSIWYG-miljø. Litt brattere læringskurve, men når man begynner å få oversikten over alt sammen så er man mye mer effektiv. Nå skriver jeg veldig sjeldent GUI-programmer, men hvis jeg skulle gjort det så hadde jeg nok kanskje brukt forms-editoren (er det ikke det det heter?) til VS til gui-ting, men til alt annet hadde jeg nok fortsatt foretrukket et unix-liknende utviklingsmiljø.

Unix lignende utviklingsmiljø??? Hva mener du med det egentlig? Text basert? Vi har da text editorer i Windows miljøet også. Både grafiske og "DOS" baserte. Ser liksom ikek helt argumentet. Selv bruker jeg UltraEdit mye når jeg jobber med Clarion, men det er bare fordi Clarion har en elendig editor. Editoren til Visual Studio er helt overlegen og jeg tror neppe jeg noen sinne kommer til å bruke UltraEdit til å skrive klasser for mine C# programmer. Det er ingen som tvinger en til å bruke Form-editoren i Visual Studio. Det er faktisk ikke noen begrensninger der i det hele tatt. Vil man age et CONSOLE program så er det bare å gjøre det. Greia er at editoren i Visual Studio er så utrolig bra at den vansklig lar seg erstatte. Muligens er SharpEdit "like" god.

 

Det som gjør meg litt nysgjerrig er hva som gjør en såkallt "Unix platform" så mye bedre å skrive kode i. Hva er det man mangler i et integrert miljø, og eventuellt, hva er det som gjør et integrert miljø så mindre brukervennlig? Er det mengden minne som et slikt miljø tar? Er minne egentlig et problem? Er man redd for at man får for mye overhead? Dette er da absolutt frivillig, også i Visual Studio. Lager man et prosjekt i VS så får man akkurat det man selv skriver. Hverken mer eller mindre. Bruker man en Skjerm editor, ja så får man naturlig nok noe overhead, fordi det som genereres skal fungere i alle tilfeller. Men igjen, dette er helt frivillig. Man kan godt skrive skjerm strukturene sine helt manuellt hvis man ønsker det. Tilsvarende kan man selvsagt skrive all filhåndtering manuellt. Man må ikke bruke Dataset generatoren eller Linq generatoren hvis man ikke vil.

 

Igjen holder jeg påstanden min oppe: Generelle Editorer i forhold til et integrert miljø blir å sammenligne som Windows Paint mot Photoshop.

[Glenn F. Henriksen]

Føler noen må skille litt mellom Visual Studio og de forskjellige wizard-ene som finnes i VS. VS er i hovedsak en veldig bra editor og debuggingsmiljø. Det er hovedgrunnen til at det er smart å bruke VS hvis du skriver .NET kode.

 

Så har du en del ting man kan gjøre i VS som gjør masse greier under panseret for deg. Koble deg til en database, dra noen tabeller her og der, dra på et grid, velg i en drop-down liste og vips så har du en applikasjon som leser fra en database, viser det i en tabell og lar deg legge til, endre og slette informasjonen. Og alt uten en eneste linje med kode.

 

Og så har du noen som mener at det er en Dårlig Ting at man kan gjøre sånn. Jeg er uenig. Noen ganger er det alt du trenger. Andre ganger så er det en grei måte å prototype ting på og andre ganger er det ikke aktuelt å bruke den metoden. Det fine med VS er at den ikke på noen måte tvinger deg til å gjøre det slik.

 

Jeg bruker VS fordi det er en utrolig bra editor, gir meg alt jeg trenger med lite bry, integrerer fint med andre verktøy jeg bruker og har noen gode add-ins som gjør jobben min enda enklere.

[HDSoftware]

Føler noen må skille litt mellom Visual Studio og de forskjellige wizard-ene som finnes i VS. VS er i hovedsak en veldig bra editor og debuggingsmiljø. Det er hovedgrunnen til at det er smart å bruke VS hvis du skriver .NET kode.

 

Så har du en del ting man kan gjøre i VS som gjør masse greier under panseret for deg. Koble deg til en database, dra noen tabeller her og der, dra på et grid, velg i en drop-down liste og vips så har du en applikasjon som leser fra en database, viser det i en tabell og lar deg legge til, endre og slette informasjonen. Og alt uten en eneste linje med kode.

 

Og så har du noen som mener at det er en Dårlig Ting at man kan gjøre sånn. Jeg er uenig. Noen ganger er det alt du trenger. Andre ganger så er det en grei måte å prototype ting på og andre ganger er det ikke aktuelt å bruke den metoden. Det fine med VS er at den ikke på noen måte tvinger deg til å gjøre det slik.

 

Jeg bruker VS fordi det er en utrolig bra editor, gir meg alt jeg trenger med lite bry, integrerer fint med andre verktøy jeg bruker og har noen gode add-ins som gjør jobben min enda enklere.

Innertier! Akkurat mitt poeng i forrige innlegg.

[teflonpanne]

Hvis du mener at emacs eller vim er som windows paint og VS er photoshop tror jeg det er fordi du aldri har satt deg ned og lært deg det skikkelig. Og som nevnt burde man kunne shell-scripting og kunne utnytte alle de små programmene som følger med en unix-platform også og ikke bare en editor. Men nå husket jeg at denne tråden var om C#, så det er litt vanskelig på windows uansett.

[Manfred]

Det var det vel absolutt ingen som sa, men det er godt gjort å mene at "unix-lignende utviklingsmiljø" er bedre enn VS sin kodeeditor på noen som helst måte.