1. Erstat tilgængelige felter med attributter
1、. .NET databinding understøtter kun databinding, og du kan få fordelene ved databinding ved at bruge attributter.
2. I get-and-set-adgangen til egenskaben kan du bruge lock til at tilføje multithreading-understøttelse.
2. readonly (runtime-konstant) og const (kompileringstidskonstant)
1. const kan kun bruges til primitive typer, enums og strenge, mens readonly kan være af enhver type;
2. const vil blive erstattet med en specifik konstant ved kompilering, så hvis både const- og readonly-værdier bruges i referencen, vil ændringen til readonly ændre designets oprindelige hensigt, nemlig behovet for at genkompilere den ændrede samling for at rereferere den nye konstantværdi.
3. Const er mere effektivt end readonly, men mister fleksibiliteten ved anvendelse.
3. IS og AS
1. Begge er typekonverteringer under kørsel, da operatorer kun kan bruges i referencetyper, mens den kan bruge værdier og referencetyper;
2. Den sædvanlige praksis er at bruge IS til at bestemme typen og derefter vælge selektivt at bruge som eller en stærk typekonverteringsoperator (konvertering defineret af en operatør).
4. ConditionalAttribute i stedet for #if #endif条件编译
1. ConditionalAttribute bruges kun på metodeniveau, og andre elementer som typer, attributter osv. er ugyldige. Og #if #endif则不受此限制;
2. ConditionalAttribute kan tilføje flere ELLER (ELLER) operationer for kompilationsbetingelser, og #if #endif则可以添加与(OG) [her kan fuldstændigt defineres som et andet separat symbol];
3. Definitionen af ConditioanlAttribute kan placeres i en separat metode for at gøre programmet mere fleksibelt.
5. Giv ToString()-metoden
1. Den kan give detaljeret information til brugerne på en mere venlig måde;
2. Brug metoden IFormatter.ToString() for at give mere fleksibel tilpasning, og hvis du tilføjer IFormatProvider og ICustomFormatter-grænsefladerne, giver det mere mening at tilpasse beskedoutputtet.
6. Forskellen mellem værdi og referencetype
1. Værdityper understøtter ikke polymorfi, hvilket er egnet til lagring af data, der drives af applikationer, mens referencer understøtter polymorfisme, som er egnet til at definere applikationsadfærd.
2. For arrays defineret som værdityper kan programmets ydeevne forbedres betydeligt;
3. Værditypen har mindre heap-hukommelsesfragmentering, hukommelsesaffald og indirekte adgangstid, og dens tilbagevenden i metoden sker i form af replikation for at undgå at eksponere den interne struktur for omverdenen.
4. Værdityper anvendes i følgende scenarier: Typernes ansvar anvendes hovedsageligt til datalagring; Offentlige grænseflader defineres fuldstændigt af nogle adgangsattributter til datamedlemmer; Der findes aldrig underklasser; Der er aldrig polymorf adfærd.
7. Værdityper bør implementeres så konstante og atomare typer som muligt
1. Gøre vores kode lettere at skrive og vedligeholde;
2. Tre strategier til initialisering af konstanter: i konstruktion; plantemetode; Byg en foranderlig hjælperklasse (f.eks. StringBuilder).
8. Sørg for, at 0 er værdig til gyldig status
1. Standardtilstanden for værditypen bør være 0;
2. 0'en af enum-typen bør ikke være ugyldig; I FlagsAttribute skal man sikre, at 0-værdien er gyldig tilstand;
3. Når strengen er tom, kan en streng returneres. Tom streng for tom.
9. Multiple repræsentationsforhold med lige vurdering
1. ReferenceEquals() bestemmer, at referencerne er ens, og det skal være sandt, når begge refererer til det samme objekt.
2. Den statiske Equals()-metode bruges først til at foretage referencevurdering og derefter til at bedømme værditypen;
3. Til vurdering af referencetypen kan du bruge omskrivningsmetoden Equals(), når du bruger værdisemantik.
4. Når Equals()-metoden omskrives, bør GetHashCode()-metoden også omskrives, og operationen operatorer==() skal leveres samtidig.
10. Forstå manglerne ved GetHashCode()-metoden
1. GetHashCode() anvendes kun på hashværdier af hash-baserede **-definerede nøgler, såsom HashTable eller Dictionary;
2. GetHashCode() bør følge de tilsvarende tre regler: to lige objekter skal returnere den samme hashkode; bør være en instansinvariant; Hashfunktionen bør give en tilfældig fordeling over alle heltal.
11. Giv prioritet til brugen af forhver-loop-sætninger
1. foreach kan eliminere compilerens kontrol af array-grænsen for for-løkken;
2. Den cirkulære variabel for for each er skrivebeskyttet, og der findes en eksplicit transformation, som kaster en undtagelse, når objekttypen for **-objektet er forkert;
3. Den **, der kræves for at bruge foreach, er: have den offentlige GetEnumberator()-metode; IEnumberable-grænsefladen er eksplicit implementeret. IEnumerator-grænsefladen er implementeret;
4. foreach kan bringe fordelene ved ressourcestyring, fordi hvis compileren kan bestemme det IDISPOSABLE interface, kan den bruge det optimerede try... endelig blokering;
12. Initialiseringen af standardfeltet er bedre end assignment-sætningen
1. Feltlevetiden initialiserer værditypen til 0 og referencetypen til nul som standard.
2. At initialisere det samme objekt flere gange vil reducere kodens eksekveringseffektivitet.
3. At sætte initialiseringen af feltet i konstruktøren fremmer undtagelseshåndtering.
13. Brug den statiske konstruktør til at initialisere statiske medlemmer
1. Den statiske konstruktør vil blive udført, før nogen metode, variabel eller attribut i en klasse tilgås;
2. Statiske felter vil også køre før den statiske konstruktør, og den statiske konstruktør er velegnet til undtagelseshåndtering.
14. Brug konstruktørkæden (i. NET 4.0 løser allerede dette problem med valgfrie parametre)
1. Brug dette til at overdrage initialiseringsarbejdet til en anden konstruktør, og brug base til at kalde konstruktøren af basisklassen;
2. Operationssekvensen for typeinstanser er: sæt alle statiske felter til 0; Udførelse af statiske feltinitialisatorer; en statisk konstruktør, der udfører basisklassen; Statiske konstruktører, der udfører den aktuelle type;
Sæt alle instansfelter til 0; Udfør instancefeltinitialisatorer; Udfør den relevante baseklasse-instanskonstruktør; Udfør instanskonstruktøren af den aktuelle type.
15. Brug using og try/finale-sætninger til at rydde op i ressourcer
I Dispose()-metoden i IDisposable-interfacet kan GC.SuppressFinalize() bruges til at underrette garbage collectoren om, at den endelige operation ikke længere udføres.
16. Minimer hukommelsesaffald
1. Det tager ekstra processortid at tildele og ødelægge objekter på en heap;
2. Teknikker til at reducere antallet af tildelte objekter: ofte anvendte lokale variable forfremmes til felter; Giver en klasse, der gemmer almindelige instanser af Singleton-objekter, som udtrykker specifikke typer.
3. Brug StringBuilder til at udføre komplekse strengoperationer.
17. Minimer pakning og udpakning
1. Vær opmærksom på den implicitte konvertering af en type til System.Object, og værditypen bør ikke erstattes med System.Object-typen;
2. Brug af grænseflader i stedet for typer kan undgå boksning, det vil sige at implementere værdityper fra grænseflader og derefter kalde medlemmer gennem grænseflader.
18. Implementér den standard Dispose-tilstand
1. For at bruge ikke-hukommelsesressourcer skal den have en finalizer; garbage collectoren tilføjer de implementerede finalizer-objekter til termineringskøen efter at have gennemført de hukommelsesobjekter, der ikke har afsluttet dem, og derefter starter garbage collector en ny tråd for at køre finalizerne på disse objekter. Dette kan undgå problemet med hukommelseslækage forårsaget af ikke-administrerede hukommelsesressourcer, der frigives.
2. Brug af IDisposable.Dispose()-metoden kræver fire arbejdsaspekter: frigivelse af alle uadministrerede ressourcer; Frigør alle administrerede ressourcer; Sæt en statusmarkør for at angive, om Dispose() er blevet udført; Kald GC.SuppressFinalize(this) for at annullere objektets termineringsoperation;
3. Tilføj en beskyttet virtuel metode Dispose() til typen, der kræver polymorfi, og den afledte klasse frigiver sin opgave ved at omskrive denne metode.
4. I typen, der kræver et IDisoposable interface, bør vi implementere en terminator, selvom vi ikke behøver en.
19. Definer og implementér grænseflader over arvetyper
1. Urelaterede typer kan i fællesskab implementere et fælles interface, og det er lettere at implementere et interface end arv;
2. Grænsefladen er relativt stabil, den indkapsler et sæt funktioner i et interface ligesom andre typer implementeringskontrakter, mens basisklassen kan udvides over tid.
20. Skeln mellem grænsefladeimplementering og omskrivning af virtuelle metoder
1. Når man implementerer et interface i baseklassen, skal den afledte klasse bruge nyt for at skjule brugen af baseklassemetoden;
2. Metoden for basisklassegrænsefladen kan erklæres som en virtuel metode og derefter implementeres i den afledte klasse.
21. Brug entrustment til at udtrykke callbacks
1. Delegerede selv giver ikke nogen undtagelsesfangst, så ethvert multicast-delegatkald vil afslutte hele kaldskæden.
2. Ved at vise og kalde hvert delegeringsmål på delegatkæden kan du undgå, at multicast-delegater kun returnerer outputtet fra den sidste delegerede.
22. Brug begivenheder til at definere eksterne grænseflader
1. Det bør erklæres som en fælles begivenhed, og lade compileren oprette add- og remove-metoder for os.
2. Brug beholderen System.ComponentModel.EventHandlerList til at gemme hver hændelseshåndter, og brug den til at skjule kompleksiteten af alle hændelser, når typen indeholder et stort antal hændelser.
23. Undgå at returnere referencer til interne klasseobjekter
1. Da adgangen til et værditypeobjekt vil skabe en kopi af objektet, vil attributterne ved at definere en værditype slet ikke ændre tilstanden inde i typeobjektet;
2. Konstante typer kan undgå at ændre objektets tilstand;
3. Definer grænsefladen for at begrænse adgangen til et delmængde for at minimere skaden på objektets interne tilstand.
4. Definer et wrapper-objekt til at begrænse adgangen til et andet objekt;
5. Når kundekoden ændrer de interne dataelementer, kan Observer-tilstanden implementeres, så objektet kan verificere eller svare til ændringerne.
24. Deklarativ programmering er bedre end imperativ programmering
Muligheden for at lave fejl i flere lignende håndskrevne algoritmer kan undgås, og klar og læsbar kode tilbydes.
25. Implementér typer så serialiserbare som muligt
1. Typen repræsenterer ikke en UI-kontrol, et vindue eller en formular, og typen bør understøtte serialisering;
2. Når den deserialiserede attribut NonSerializedAttribute tilføjes, kan standardværdien indlæses af OnDeserialization()-metoden, som implementerer IDeserializationCallback;
3. I versionskontrol kan du bruge ISerializable-grænsefladen til fleksibel kontrol og tilbyde en serialiseringskonstruktør til at initialisere objekter i henhold til dataene i strømmen, og også kræve tilladelse fra SerializationFormatter-undtagelser ved implementering.
4. Hvis du skal oprette en afledt klasse, skal du give en hook-metode for den afledte klasse.
26. Brug IComparable- og IComparer-grænseflader til at implementere sorteringsrelationer
1. IComparable-grænsefladen bruges til at implementere den mest naturlige sorteringsrelation for typer, overbelaste fire sammenligningsoperatorer og levere en overbelastet version af CompareTo()-metoden til at acceptere specifikke typer som parametre.
2. IComparer bruges til at give sorteringsrelationer, der adskiller sig fra IComparable, eller til at give os sorteringsrelationer, som typen selv siger ikke er implementeret.
27. Undgå ICloneable grænseflader
1. For værdityper er der ikke behov for at understøtte ICloneable-interface, blot brug standardtildelingsoperationen;
2. For baseklasser, der kan have behov for at understøtte ICloneable-grænseflader, bør der oprettes en beskyttet replikationskonstruktør til dem, og IConeable-grænseflader bør undgås.
28. Undgå tvungen ombygningsoperatør
At bruge konstruktører i stedet for konverteringsoperatorer kan gøre konverteringsarbejdet mere klart, hvilket nemt kan føre til nogle mærkelige fejl på grund af midlertidige objekter, der bruges efter konverteringen.
29. Overvej kun at bruge den nye modifikator, når ophobningen af nye versioner skaber problemer
30. Implementér CLS-kompatible samlinger så meget som muligt
1. For at skabe en kompatibel samling skal to regler følges: parametrene og returværdityperne, som alle offentlige og beskyttede medlemmer af samlingen bruger, skal være kompatible med CLS; Ethvert offentligt og beskyttet medlem, der ikke er kompatibelt med CLS, skal have et CLS-kompatibelt alternativ;
2. Du kan omgå CLS-kompatibilitetstypekontrollen ved eksplicit at implementere interfacet, og CLSCompliantAttribute vil ikke kontrollere CLS-kompatibiliteten for private medlemmer.
31. Implementér en kort og præcis metode så meget som muligt
1. JIT-kompilatoren kompilerer i enheder af metoder, og metoder, der ikke kaldes, vil ikke blive kompileret af JIT;
2. Hvis koden til Case-udsagnet i den længere Switch erstattes med én metode ad gangen, vil den tid, JIT-kompilatoren sparer, blive ganget op;
3. Korte og præcise metoder samt valg af færre lokale variable kan opnå optimeret registerbrug;
4. Jo færre kontrolgrene i metoden, desto lettere er det for JIT-kompilatoren at lægge variabler i registre.
32. Realiser små størrelser og høje sammenhængende samlinger så meget som muligt
1. Læg alle offentlige klasser og fælles base-klasser i nogle assemblies, læg værktøjsklasserne, der leverer funktioner for offentlige klasser, i samme assembly, pak de relevante offentlige interfaces ind i deres egne assemblies, og behandl endelig de klasser, der er placeret over hele den horisontale position i applikationen;
2. I princippet bør der skabes to typer komponenter: den ene er en lille og samlet samling med en specifik funktion, og den anden er en stor og bred samling med fælles funktioner.
33. Begræns typernes synlighed
1. Brug af grænseflader til at eksponere funktionerne af typer kan gøre det lettere for os at skabe interne klasser uden at begrænse deres tilgængelighed uden for assemblyen;
2. Jo færre offentlige typer der er eksponeret for omverdenen, desto flere muligheder har du for fremtidig udvidelse og ændringsimplementeringer.
34. Skab et stor-granulært web-API
Dette minimerer hyppigheden og belastningen af transaktioner mellem maskiner, hvilket giver store operationer og fintgående eksekveringer til serveren.
35. Omskrivning er bedre end hændelsesprocessorer
1. Hvis en eventprocessor kaster en undtagelse, vil andre processorer på event chain ikke blive kaldt, men dette vil ikke ske for den omskrevne virtuelle metode.
2. Omskrivning er langt mere effektiv end associative hændelsesprocessorer, som skal iterere over hele anmodningslisten, hvilket tager mere CPU-tid.
3. Begivenheder kan besvares under kørsel med større fleksibilitet, og flere svar kan knyttes til den samme begivenhed.
4. Den almindelige regel er at håndtere en afledt begivenhed, og omskrivningsmetoden er bedre.
36. Fair brug. .NET runtime-diagnostik
1. System.Diagnostics.Debug\Trace\EventLog leverer alle de nødvendige værktøjer for, at programmet kan tilføje diagnostisk information til runtime, og applikationen kan skrive til systemets begivenhedslog, når EventLog leverer ingrediensen;
2. Til sidst, skriv ikke dit eget diagnostiske bibliotek, .NET FCL har allerede det kernebibliotek, vi har brug for.
37. Brug standard konfigurationsmekanismer
1、. System.Windows.Application-klassen i .NET-frameworket definerer egenskaberne, så vi kan etablere en fælles konfigurationssti;
2. Application.LocalAppDataPath og Application.userDataPath vil generere stinavnene for det lokale datakatalog og brugerdata;
3. Skriv ikke data i ProgramFiles og Windows systemmapper, disse steder kræver højere sikkerhedsrettigheder, forvent ikke at brugerne har skrivetilladelser.
38. Tilpas og understøt databinding
1. De to objekter BindingMananger og CurrencyManager realiserer dataoverførslen mellem kontrollen og datakilden;
2. Fordele ved databinding: brug af databinding er meget enklere end at skrive sin egen kode; Den bør bruges til scopes andre end tekstdataelementer – andre displayegenskaber kan også begrænses; For Windowos Forms-databindinger, evnen til at håndtere multiple control synkronisering af checkrelaterede datakilder;
3. Når objektet ikke understøtter de nødvendige attributter, kan du understøtte databinding ved at blokere det aktuelle objekt og derefter tilføje det ønskede objekt.
39. Brug. .NET-validering
1. Der er fem kontroller i ASP.NET til at verificere gyldigheden, og du kan bruge CustomValidator til at udlede en ny klasse for at tilføje din egen authenticator.
2. Windows-validering kræver en sub-System.Windows.Forms.Control.Validating for at skrive en event handler.
40. Vælg den passende ** efter behovene
1. Arrayet har to åbenlyse fejl: det kan ikke ændres dynamisk i størrelse; Størrelsesændring er tidskrævende;
2. ArrayList blander karakteristika fra endimensionelle arrays og linkede lister, Kø og Stack er specielle arrays baseret på Array;
3. Når programmet er mere fleksibelt til at tilføje og slette elementer, kan det lave mere robuste typer, og når man opretter en klasse, der simulerer **, bør det implementere indeksere og IEnumberable interfaces til det.
41. Datasættet er bedre end brugerdefineret struktur
1. DataSets har to ulemper: interaktionen mellem DataSets ved brug af XML-serialiseringsmekanisme og non-.NET kode er ikke særlig god; DataSet er en meget alsidig container;
2. Stærke typer DataSets bryder flere designregler, og deres udviklingseffektivitet er meget højere end for de mere elegante designs, der er skrevet af dem selv.
42. Brug karakteristika til at forenkle refleksion
Ved at designe og implementere featureklasser, der tvinger udviklere til at erklære dynamisk brugbare typer, metoder og attributter, kan du reducere applikationsfejl under kørsel og forbedre softwarebrugertilfredsheden.
43. Undgå overforbrug af reflekser
1. De parametre og returværdier, som Invoke-medlemmer bruger, er System.Object, som konverterer typer under kørsel, men muligheden for problemer er blevet mere sandsynlig.
2. Interfacet giver os et klarere og mere vedligeholdelsesværdigt system, og refleksion er en meget kraftfuld sen bindingsmekanisme. .NET-frameworket bruger det til at implementere databinding for Windows-kontroller og webkontroller.
44. Opret specifikke undtagelsesklasser til applikationen
1. Den eneste grund til, at forskellige undtagelsesklasser er nødvendige, er for at gøre det muligt for brugere nemt at anvende forskellige tilgange til forskellige fejl, når de skriver catch-processorer;
2. Når der kan være forskellige reparationsadfærd, bør vi oprette en række forskellige undtagelsesklasser; ved at levere alle konstruktører, der understøttes af undtagelsesbaseklassen, kan vi skabe en fuldt funktionel undtagelsesklasse for applikationen og bruge attributten InnerException til at gemme al fejlinformation genereret af lavere fejlbetingelser.
45. Giv prioritet til unormale sikkerhedsgarantier
1. Strong exception guarantee giver den bedste balance mellem recovery fra undtagelsen og forenklet undtagelseshåndtering, og programmets tilstand forbliver uændret, når operationen afbrydes på grund af undtagelsen.
2. Foretag defensiv kopiering af de data, der skal ændres, modificerer den defensive kopi af disse data, operationen i midten kan forårsage en undtagelse, og den midlertidige kopi og det oprindelige objekt vil blive udvekslet;
3. Terminatorer, Dispose()-metoder og målmetoder bundet til delegerede bør sikre, at de under ingen omstændigheder kaster undtagelser.
46. Minimer interoperabilitet
1. Der er tre omkostninger ved interoperabilitet: omkostningerne ved dataopgørelse mellem managed og unmanaged heaps, omkostningerne ved at skifte mellem managed code og unmanaged kode, samt udviklingsarbejdet for udviklere, der arbejder med hybride miljøer;
2. Brug af den blittable type i interop kan effektivt replikere frem og tilbage mellem managed og unmanaged miljøer uden at blive påvirket af objektets interne struktur.
3. Brug In/Out-funktionen til at sikre de mest passende unødvendige multiple replikationer, og forbedre ydeevnen ved at angive, hvordan dataene oplistes.
4. Brug COM Interop til at implementere interoperabilitet med COM-komponenter på den simpleste måde, brug P/Invoke til at kalde Win32 API, eller brug /CLR-switchen i C++-kompilatoren til at blande managed og unmanaged kode;
47. Giv prioritet til sikkerhedskoderne
1. Undgå adgang til uadministreret hukommelse så meget som muligt, og isoleret lagring kan ikke forhindre adgang fra administreret kode og betroede brugere.
2. Når assemblies kører på web, bør man overveje at bruge isoleret lager, og når visse algoritmer kræver højere sikkerhedsrettigheder, bør disse koder isoleres i en separat assembly.
48. Mestre relevante værktøjer og ressourcer
1. Brug NUnit til at etablere automatiske enhedstests (integreret i VS2010);
2. FXCop-værktøjet vil indhente IL-koden i samlingen, analysere den i forhold til de heterogene kodningsregler og bedste praksis og til sidst rapportere overtrædelsen.
3. ILDasm er et IL-demonteringsværktøj, der kan hjælpe os med at få indsigt i detaljer;
4. Shared Source CLI er en implementeringskildekode, der indeholder .NET-frameworkkernen og C#-kompilatoren. |
Opslået på 15/03/2018 10.41.59
|
|
|
