DIM x_ID, x_created, x_updated, x_date, x_subject, x_text, x_viewTo
Jag har också sett varianter där man skriver variablerna under varandra, men det är kanske för tydlighetens skull.
Däremot fattar jag inte varför man inte kan skriva som man måste skriva i Visual Basic, typ:
DIM x_date as date
Hur skriver ni i stora projekt? I små pluttegrejer som att lista poster från en gästbok är alldeles för enkelt utan jag syftar på värsta tänkbara scenario med massa includefiler och från kanske 50-75 olika varaiablenamn. Hur skriver man en sån grej tydligt!?
Men det var steget efter jag ville åt. Låt mig uttrycka mig lite bättre.
Skriver ni alla DIM grejset längst upp på första sidan, även de som finns inne i includefilerna eller DIMar ni precis innan namnet förekommer, då det behövs liksom.
Fördelen med en första varianten är att man ser vilka variabler som finns med på sidan, fördelen med den andra varaianten är att variabler tilldelas då de behövs på relevant ställe i koden.
Hela anledningen med option explicit är att man ska hitta felstavade variabelnamn... men poängen försvinner lite om man "bara skriver på" och DIMar allt som finns.
I så fall skulle man kunna inckludera en fil där man har alla 100 variabelnamnen DIMade och sen bara kör på... Och om man skulle hitta på ett namn som inte finns bara lägga till det... och includera hela listan på alla sidor??
Ja men nu frågade jag inte hur ni gör närr ni har tre eller 20 variabelnamn utan hur ni gör när ni har 50 eller fler. Alltså oöverskådligt många.
Då skulle nog jag kommenterat mina variablar typ
*Dessa variblar används vid det första recordsettet (rad 10 till 20)
Dim strSQL
Dim ObjRS
...
...
...
Jag har aldrig gjort nått sånt, men jag skulle nog uppskatat det om jag skulle ta "över" koden från nån annan.......man kan ju inte kommentera för mycket.....
PS. Detta är vad jag skulle göra och inte nån metod som jag tycker att alla ska "köra" DS.
Jag slänger upp allt överst, alltid. Jag grupperar mina variabler efter datatyp / subtyp.
' Declare all integers
Dim intCounter ' as integer
Dim intCollectThing ' as integer
' Declare all longs
Dim lngArticleID ' as long
Dim lngThingy as long
' Declare objects
Dim objFileSystem ' as Scripting.Filesystemobject
Dim objXmlDox ' as MSXML2.DOMDocument
' Declare strings
Dim strArticleName ' as String
Jag skriver som jag gör i Visual Basic, och lägger in lite remark-apostrofer här och där för att slippa syntaxfel.
Det gäller att vara tydlig, det är inte jag som ska förstå koden.
Men det är ju en smaksak. :-)
OK, @nders, det verkar vara ett bra sätt men faktum kvarstår, det blir FETT med scroll med den varianten.
Vad tycker ni om att includera en fil med alla DIMade variabler och sen använda den filen på varje sida?
Hmm... det kanske inte är så bra trots allt... jag har lite svårt att bestämma mig.
De flesta av mina namn återkommer i varje tabell, x_name, x_created, x_date osv. Om man då en gång för alla DIMar dom så blir det ju bra... Även om dom innehåller olika värden varje gång så är de fortfarande relevbanta i sitt sammanhang.
Hajjar ni??
Kort frågat, är det någon uppenbar nackdel att DIMa för mycket??
Ah! Läckert! Här om dagen konstaterade jag att jag i en annan tråd tidigare diggade dina val av variabelnamn och precis som då känner jag stor sympati för namn som cfg_UsernameMaxLength. Jag kan iofs inte på rak arm fatta vad "cfg" betyder, kanske configfile eller liknande. Men det går inte att missuppfatta i alla fall! :-)
Vi har diskuterat val av variabel namn och vi har liknande syn på temat.
----
Hur skulle ni göra med nedanstående kod? Ta er ann skiten eller bara skita i det? Scenen är ett webbverktyg och filen i fråga är för administratörerna att i rent informativt syfte kunna få reda på medlemmars adressuppgifter.
Vad jag menar är, det känns lite meningslöst att lägga tid på prestanda på A: En fil som nästan inte innehåller någon data. B: En fil som kanske har 20 - 50 klick i veckan.
Det man ska "fatta" eller andra ska "fatta" är vad det är för typ av variabel och vad innehållet ska vara. Tex om det handlar om tex ett användarnamn så bör man prefixa och namnge den efter följande:
strUserName
Då ser man direkt att variabeln är av typen string och den ska innehålla ett användarnamn. Om det är ett användarid:
lngUserID
På detta sätt ser man att variabeln är av typen Long och ska innehålla ett UserID
Lättare än så kan det inte bli
använder man som på detta vis: x_Subject så ser man endast vad den ska innehålla men ej vad det är för typ, strint, integer, long, date etc.
@ndersmetod är den klart bästa då man har mycket "gratis" om man i ett senare skede skull vilja göra en komponent av sin kod
Om du säger att du inte fattar vad x_subject är för något, då kontrar jag i all välmening med "är du trög?"
Man måste sätta gränsen nånstans och jag tycker det räcker med ett någorlunda tydligt namn. Är man dessutom konsekvent och använder samma tabellnamn i alla tabeller i samtliga projekt man producerar, vilket jag har gjort hittills, borde det finnas lite utrymme för egna tolkningar. Det kanske är dumt att göra så, men så har jag gjort i mina första tre år som webbprogrammerare.
Det arbetet jag gjorde för tre år sedan har jag stor nytta av idag.
Dessutom är i stort sätt alla tabellnamnen strängar. De som inte är det är antingen Integer, x_ID, eller Date, x_date, x_created, x_updated. Normalt sett framgår det av sammanhanget vilken typ en variabel är av. Gör det inte det så finns det förmodligen betydligt allvarligare fel i produktionen.
Man får endå utgå från att den som läser någon annans kod har en hjärna att tänka med. Det är i alla fall mitt utgångsläge! :-)
Ah! Läckert! Här om dagen konstaterade jag att jag i en annan tråd tidigare diggade dina val av variabelnamn och precis som då känner jag stor sympati för namn som cfg_UsernameMaxLength. Jag kan iofs inte på rak arm fatta vad "cfg" betyder, kanske configfile eller liknande. Men det går inte att missuppfatta i alla fall! :-)
cfg_ lade jag till när jag upptäckte att jag blandade ihop variablerna. cfg_ står här för "config" och är således inställningar för ett forum. Och när man ser namnet cfg_UsernameMaxLength så vet man att det handlar om längden på använarnamnet, men också att det är huvudinställningen och att det är så långt de SKA vara. :)
Vi har diskuterat val av variabel namn och vi har liknande syn på temat.
Nja, jag tycker det är onödigt att skriva x_ före strängen. Det är i så fall bättre med strSubject eller liknande. Exempel:
x_cellular = mySQL("x_cellular")
Hur vet man att x_cellular inte är heltal (dvs 070248553) istället för text (dvs "070-248553")?
Usch... nu måste jag stå till svars för allt jag gör... :-)
Jag håller helt med dig, jag är själv inte överväldigande förtjust i mitt val av variabelnamn. Jag väntar med spänning tills den dagen någon kommer upp med avsevärt bättre förslag än mina, vilket jag dagsläget inte kategoriserar strSubject att vara.
x_ grejen myntade jag rätt tidigt och det är primärt att "skydda" mina namn mot reserverade uttryck. Det har bara hängt med... I brist på annat. Egentligen inte heller någon höjdarlösning. Många blir lite halvirriterade på detta val.
mySQL gillar jag verkligen inte eftersom det lätt förväxlas med en databasmjukvara med samma namn och det är rätt olyckligt, särskilt i PHP projekten.
I och med användandet av GetRows() försvinner detta namnet mer och mer så det håller på att lösa sig själv.
x_cellular - nej det framgår inte av koden om det är Int eller String. Däremot framgår det tydligt i den skrivna dokumentationen som följer med källkoden till varje projekt i ett vanligt Word dokument och jag uppmanar alla som sliter med min kod och mina variabelnamn att skriva ut och titta på.
Är det något man tycker framgår oklart är det bara att slänga en blick på pappret vid ens sida:
ska man följa "god programmerar sed" så ska man använda ungersk notation, dvs str som prefix för strängvariabler.
Som sagt, det är det allra bästa och helt klart MYCKET bättre än x_ som inte säger ett skit.
OK... Jag har varit nere i gymmet och tänkt på saken och kommit fram till ungefär samma sak, mitt tillvägagångssätt hittils är värt att se över.
Det är bra att ha forumet att växla idéer med. Till min stora lycka är vi nu två på företaget som håller på med samma sak.
Hur som helst, vi ska ta tag i denna biten.
Jag ställer mig dock tveksam till om vi ska röra befintliga projekt eller om vi ska koncenterera oss på uteslutande nya projekt. En övergång till ett annat tillvägagångssätt skulle i så fall ta mellan ett och två år att genomföra. Över tre år är dock inte orealistiskt.
Det är helt klart en hypotetisk tidsrymd som jag i stora drag grundar på tidigare erfarenheter. Jag har gjort strategiska byten av mer övergripande karraktär tidigare och gamla grejer hänger med förvånansvärt och irriterande länge.
