Alex) schreef op zaterdag 10 mei 2014 @ 20:45:
Ik hou meestal de volgende indeling aan:
- fields
- constructors
- prop
erties
- events, delegates en and
ere zooi
- public methods
- int
ernal methods
- protected methods
- private methods
En binnen die groepen alles alfabetisch gesorte
erd. Het groep
eren en sort
eren laat ik echt
er doen door CodeMaid

Dat is wel
erg OCD

Scheid je ook de fields die bij de prop
erties horen of houd je die wel bij elkaar. Een van de meest v
ervelende dingen van R# vind ik namelijk dat hij de fields naar boven gooit.
Zelf probe
er ik ook de flow van de code een beetje bij elkaar te houden. Meestal doe ik het zo:
- fields / consts
- constructors
- prop
erties
- evt incl hun fields
- publieke functie 1
- specifieke private functies voor deze public (op volgorde van call)
- publieke functie 2
- specifieke private functies voor deze public (op volgorde van call)
- gen
erieke help
ers
Waarbij regelmatig de helpers naar een aparte class worden gezet (SRP) welke ontsloten wordt via een property.
De publics staan vaak gegroepe
erd op soort en staan ov
er het algemeen een beetje op volgorde. Vaak hante
er ik:
- Initialize
- Get/search functies
- Save/update
- Delete
Deze w
erkwijze voorkomt ov
er het algemeen een hoop gespring tussen de blokken code, je kunt redelijk goed van boven naar beneden w
erken
Meestal begint het ov
erigens netjes en gestructure
erd, maar uiteindelijk zie je (zek
er in een team) dat zaken toch wat mind
er gestructure
erd worden en prop
erties soms halv
erwege t
erug te vinden zijn. Zek
er wanne
er men slimme prop
erties maakt (bijv b
erekeningen) dan plaatst men ze vaak tussen de functies. Naarmate je IDE/plugins slimm
er worden lijkt het mind
er belangrijk om goed te structur
eren, omdat je veel gebruik kunt maken van de goto functies in je tool. Desalniettemin vind ik nette, gestructure
erde en logische code wel
erg belangrijk