Kære gæst, velkommen til Tweak.dk. Hvis dette er dit første besøg her, bør du læse Hjælp. Her forklares i detaljer hvordan denne side fungerer. For at benytte alle funktionerne på denne side, bør du overveje at lade dig registrere. Benyt venligst registreringsformularen for at registrere her eller læs yderligere information om registreringsprocessen. Hvis du allerede er registreret, så log på her.

1

søndag, 30. maj 2010, 21:59


Hejhej !

Jeg er ved at prøve at lære at programmerer lidt C#. Jeg syntes det er begyndt at gå udemærket, hvor jeg endelig ligefrem kan få fremstillet noget brugbart :crazyeyes:

Så var det jeg tænkte at det nok ville være en god idé at få rodet lidt op i koden og skrevet den rigtigt, så jeg ikke for tilvendt mig alt for mange dårlige vaner ;)
Jeg ville være taknemlig hvis der var nogen der ville have lyst til at kaste et blik over koden, og evt. komme med noget kritik til hvordan jeg kan skrive den mere overskueligt og forståeligt. Det er svært at læse op omkring på nettet, men jeg kan forstå der er nogle der arbejder professionelt med faget herinde der garanteret kan give et par tips :D.

Programmet har til funktion at være et brændstofsregnskab hvor man indtaster hver gang man har tanket på bilen med pris og hvad kilometer tælleren stod på.
Programmet kan således udregne Km/L (forudsat man fylder tanken helt op hver gang), og en række statistiske gennemsnit osv.
Der er også en funktion til udregning af rejseomkostninger i benzin hvor man indtaster distancen og evt lader programmet tage gennemsnits km/l og pris/l fra "databasen", og kan få at vide hvad det fx koster at køre på arbejde hver dag, og hvor mange dage man kan køre inden man skal tanke.

Kunne også være sjovt hvis der var nogen der havde idéer til udvidelse af programmet så jeg kan lære nogle nye ting, ListView og Graph objektet har indtil vidre været sjovt og noget nyt jeg har "lært" at bruge udfra det her projekt indtil vidre :roller: Skal jo starte et sted =p

Programmet er lavet i microsoft's udviklingsværktøj express studio 2010 C#, projekt filen ligger i zipfilen sammen med et compiled program + en SamleFile.txt man kan åbne så man ikke behøver taste en masse optankninger ind :)
http://peecee.dk/upload/view/248417


2

mandag, 31. maj 2010, 08:11


Dårlige vaner er noget du kommer af med efter noget tid, både ved at snakke med andre udviklere, men også ved at opdage hvorfor det er dårlige vaner, når du prøver at videreudvikle dine programmer.. Du får dårlige vaner fordi du lærer udvikling for dig selv og ikke via f.eks. en underviser, der har forstand på det og kan fortælle dig mere end hvad bogen kan.. Så det er bare med at komme igang :) virker programmerne, så virker de, det plejer altid at virke godt i starten :) når du så bliver god kan du begynde at kredse hehe


3

mandag, 31. maj 2010, 17:27


Jeg starter (forhåbentlig) på AAU efter sommer, hvor jeg vil læse datalogi, dette har været en af hoved årsagerne til at jeg gerne ville "forberede" mig lidt, så jeg ikke starter på hel bar bund.

Kan dog håbe at de ikke starter alt for hårdt ud :)


4

onsdag, 2. juni 2010, 21:13


en hurtigt ting ihvertfald husk og brug #region istedet for de der //////////

Et andet eksemple i NewEntry.cs så er der en kommentar //end New NewEntrySaveButton_Click og //end switch osv. Dette er unødvendigt, hvis du skal lave kommentare i koden så lav noget der er beskrivende om hvorfor du gør noget og ikke hvad du gør da dette er selvsagt i koden :)

Husk osse ikke public variabler burde starte med _ :)

Eks:

Kildekode

1
2
3
4
5
6
#region Function
public void MyFunction(int ContactId)
{
   int _contactId = ContactId;
} 
#endregion

1x ASUS Maximus IV Extreme-Z
1x Intel® Core™ i7-2600K Processor @ 4.430 mhz - Corsair H60
2x Gainward GeForce GTX 570 1280MB
1x Corsair Vengeance™ DDR3 1600MHz 16GB CL9 Kit w/4x 4GB XMS3 modules
1x Corsair TX V2 850W PSU

Dette indlæg er blevet redigeret 2 gange, senest redigeret af "Jaiz" (03.06.2010, 01:55)


5

torsdag, 3. juni 2010, 21:55


Fedt program, god start... jeg lavede engang noget lignende hvor man også kunne angive x-antal personer og hvor mange km de havde kørt af den pågældende tank (så man kunne se hvor meget hver person skulle betale).

Hvordan du formaterer din kode betyder for så vidt ingenting når det kun er dig selv der arbejder på projektet. Så i hvilken udstrækning du bruger regions, og om du sætter _ foran non-public members betyder ikke rigtig noget.

Der er et par steder hvor du angiver den fulde reference til datatyper ved erklæring af variabler, eksempelvis Program.cs linje 195+. En using statement vil reducere kodemængden en del. Når du skriver en type der ligger uden for namespace kan du i Visual Studio bruge shift + alt + F10 til hurtigt at tilføje den.

Alternativt til Config.txt kan du bruge en app.config. Det er lidt mere standardiseret og så slipper man også for at læse fra en tekstfil (ikke at der er noget galt i det :) )

ToString() behøver du ikke kalde på properties der allerede returnerer en streng. Etc. NewEntry.cs linje 93+.

gl med refactoring.


6

fredag, 4. juni 2010, 07:28


Citeret

Oprindeligt indlæg af Simon Jensen
Hvordan du formaterer din kode betyder for så vidt ingenting når det kun er dig selv der arbejder på projektet. Så i hvilken udstrækning du bruger regions, og om du sætter _ foran non-public members betyder ikke rigtig noget.


Og dog. Det er kun tilfældet hvis du ikke har tænkt dig at arbejde sammen med nogen om det, og du absolut ikke regner med at skulle bruge det til noget om lang tid.

God formatering (og kommentering) er noget af det der sparer absolut mest tid når man skal tilbage og rette i et eller andet gammelt program som man lige skal bruge til et eller andet.

/ask

IBM t42 and IBM t23 still alive and kicking

7

fredag, 4. juni 2010, 16:05


Citeret

Oprindeligt indlæg af jacobask

Citeret

Oprindeligt indlæg af Simon Jensen
Hvordan du formaterer din kode betyder for så vidt ingenting når det kun er dig selv der arbejder på projektet. Så i hvilken udstrækning du bruger regions, og om du sætter _ foran non-public members betyder ikke rigtig noget.


Og dog. Det er kun tilfældet hvis du ikke har tænkt dig at arbejde sammen med nogen om det, og du absolut ikke regner med at skulle bruge det til noget om lang tid.

God formatering (og kommentering) er noget af det der sparer absolut mest tid når man skal tilbage og rette i et eller andet gammelt program som man lige skal bruge til et eller andet.

/ask


Ja det er jo og det


8

lørdag, 5. juni 2010, 06:56


Citeret

Oprindeligt indlæg af Simon Jensen
Ja det er jo og det


Du skulle måske også lige markere den næste del af sætningen også: "og du absolut ikke regner med at skulle bruge det til noget om lang tid."

/ask

IBM t42 and IBM t23 still alive and kicking

9

mandag, 21. juni 2010, 05:02


Citeret

Oprindeligt indlæg af jacobask

Citeret

Oprindeligt indlæg af Simon Jensen
Ja det er jo og det


Du skulle måske også lige markere den næste del af sætningen også: "og du absolut ikke regner med at skulle bruge det til noget om lang tid."

/ask


jeg har det med at ethvert program man skriver kan bruges engang i fremtiden til reference eller hjælp, SÅFREMT det er veldokumenteret kode man bruger, ellers kan man hurtigt bruge en del tid på at finde ting og sager i sin gamle kode.

Gode råd:

1. brug Stylecop (aner ikke om det duer til 2010 endnu, men når det kommer til det, så BRUG det. Stylecop giver dig en god stak warnings omkring selv de mindste detaljer om hvordan koden er bygget op, da det er beregnet til at gøre læsbarheden af din kode så god som muligt. Det kan i første omgang virke mega irriterende, men efter noget tid vænner man sig til det :)

2. kend de tre K'er (Kommentér, Kommentér og Kommentér lidt mer'). Et godt tip der holder med ethvert sprog. Sørg for at kommentere bl.a. hvad en given variabel skal bruges til, udregninger, mellemregninger osv. Hellere for mange kommentarer end for få.
Udover den regel, så gør jeg selv det alt jeg altid skriver kommentarer på ENGELSK, det forhindrer en masse hjernegym med at skulle skifte mellem to forskellige sprog hele tiden.
Kommentarer på en enkelt linje kan skrives med "//" mens kommentarer der fylder flere linjer startes med "/*" og afluttes med "*/".

3. Brug som sagt #region, det kan gøre det meget nemmere at finde rundt for dig selv og andre.

4. brug <summary> til de mere trivielle metoder, især metoder der bruger flere argumenter. Summary hjælper til hvis du vil lave kodedokumentation via fx. Sandcastle og Doxygen, og hjælper også til når du skal skrive calls til metoder i VS. Summary popper autiomatisk frem ved at skrive tre skråstreger ("///"). Hvis du laver en summary ved en metode med flere argumenter, så kommer <param> altid med, én for hvert argument, hvor du kan skrive info for argumentet.

Summary kan se således ud:

Kildekode

1
2
3
4
5
6
7
        /// <summary>
        /// Represent the Game Logic Subsystem of a game / game engine. It moves the player in the direction
        /// given by the Input system
        /// </summary>
        /// <param name="movement">Movement direction of player</param>
        private void GameLogic(MoveDirection playerMovement)
        { 

AMD FX 6300
8 GB Crucial DDR3-800
Gigabyte 970A-DS3P
AMD Radeon R9 270X

Nyeste Videoer og Trailers

Indsend nyhed
Har du fundet en fed nyhed så indsend den så alle andre på Tweak.dk kan få glæde af den.