Stila policists

Labrīt, lasītāj!

Tev droši vien arī ir kolēģis, kurš izmanto ungāru pierakstu (es ceru, ka Tavā uzņēmumā tas nav standarts)? Kolēģis, kurš spītīgi neraksta kodā dokumentējošos komentārus? Uzņēmumā ir pieņemts standarts par to, kā jāizkārto kods, bet neviens to neievēro? Varbūt Tev pašam piemirstās, ka kodam ir jābūt saprotamam, nevis smilšu kastei kur Tu spēlējies ar dažādām valodas piedāvātām konstrukcijām? Man reizēm tā gadās.

Tomēr, turpinot labākajās reklāmu tradīcijās, varu teikt, ka Tavām raizēm ir pienācis gals. Microsoft partizāni ir devuši pasaulei rīku ar nosaukumu StyleCop, kas ir koda analīzes (FxCop) radinieks. Atšķirības no FxCop, kurš analizē sakompilētās asemblijas, StyleCop analizē pirmkodu un tā atbilstību noteiktiem noteikumiem. Pēc StyleCop uzinstalēšanas, Visual Studio Tools izvēlnē parādās jaunas iespējas "Run Source Analysis" un "Run Source Analysis (Rescan All)", tiesa, es tā steidzos jums paziņot jaunumus, ka vēl neesmu pietiekami ar šo rīku izspēlējies, lai varētu sīki pastāstīt par atšķirībām starp šiem punktiem.

tool_source_analysis

 

Pēc "Run Source Analysis" izvēles, StyleCop veic pirmkoda analīzi un līdzīgi, kā koda analīze, parāda neatbilstības noteikumiem. Vienīgā būtiskā atšķirība ir tas, ka noteikumu kodi sākas ar "SA", nevis "CA".

sa_results

 

Tā kā pie mums pieņemtās vadlīnijas nedaudz atšķiras no noteikumiem, kas pēc noklusējuma ir uzstādīti StyleCop, tad mani ieinteresēja konfigurācijas iespējas. Jāsaka, tās ir nedaudz noslēptas un man nācās jautāt Gūgles tantei. Izrādījās, ka pie konfigurācijas tiek no projekta konteksta izvēlnes, kā parādīts attēlā.

project_context_menu

 

Konfigurācijas iespēju gan nav pārāk daudz, bet kā var lasīt StyleCop komandas emuārā, tas esot nepieciešams, lai varētu sasniegt galveno mērķi - elegantu un viendabīgu kodu, kuru būtu viegli lasīt. Pēc ekrānšāviņa gan neizskatās, ka iespēju būtu maz :)

sa_settings

Published 26 May 2008 09:20 AM by ivars.arins
Filed under: , ,

Comments

# Krišs said on 26 May, 2008 10:41 AM

Kādi ir apsvērumi, kādēļ Ungāru notāciju nevajadzētu lietot kā standartu, ja jau tas ir veiksmīgi ieviests?

# ivars.arins said on 26 May, 2008 11:02 AM

Galvenais iemesls, kāpēc nelietot ungāru pierakstu ir tas, ka šādam pierakstam nav nekādas pievienotās vērtības, tas būtībā ir tikai "troksnis" kodā.

Protams, ja viss esošais kods ir ungāru pierakstā, tad vienā dienā to neizlabos. Tomēr, ejot uz gaišo nākotni vajadzētu censties no tā izvairīties.

# Krišs said on 26 May, 2008 01:09 PM

Jāsaka, stils konstantes rakstīt UPPERCASE arī nedod īpašu pievienoto vērtību, bet sabojā lasāmību ;-)

Lietoju ungāru pierakstu, lai mainīgajam piekārtotu tvērumu, kam tas piederīgs (klases mainīgajiem prefikss "c", parametriem - "p", metodes iekšienē definētiem mainīgajiem - nav), un šāda informācija labi noder, darbojoties vietās, kur vienlaikus jāapstrādā mainīgie no dažādiem tvērumiem. Piemēram, konstruktoros:

Public Sub New(ByVal pAppleCount as Integer)

cAppleCount= pAppleCount

End Sub

un šeit ir skaidri redzams, ka jaunās instances lauks AppleCount dabūs parametros padotā mainīgā AppleCount vērtību.

Vēsturiski iegājies lietot arī pa vienam burtam tipa apzīmēšanai (tas ir, šajā piemērā būtu ipAppleCount, nevis pAppleCount), bet šī daļa tiešām sāk pēdējā laikā šķist lieka.

Leave a Comment

(obligāts) 
(obligāts) 
(brīvizvēles)
(obligāts)