Hej!
Jag läste just veckobrevet och undrar lite över strängsammanslagningsexemplet. själva concat är en sub, borde det inte vara en funktion? (finns det egentligen någon anledning att använda sub? En funktion kan ju alltid returnera en Boolean som man använder om man vill, annars inte. Och den där variabeln ccOffset, borde inte den ingå i anropet, om den ens behöver existera utanför en komplett concatfunktion? Skall man skriva VB-program så? Jag anser mig inte vara VB-programmerare så jag vet inte men för mig ser det fult ut, inbjuder till fel. Variabler skall väl bara kunna ändras där dom hör hemma så att säga, så lite globalt som möjligt?
Jag förmodar att detta bara var ett snabbt exempel, men risken är ju att någon tar efter detta okritiskt, och får sen svårt att upptäcka om nåt går fel. För att inte tala om den andra person som skall försöka förstå programmet om några år när det behöver ändras.
Eller????

- Hans

Hej
Vore ganska bra om du kunde spalta upp ditt svammel,
och byta rad på lämpliga ställe.

Som det nu är skrivet blir det mycket oaptitligt att läsa,
därför orka man inte bry sig.

tycker
Sven

Det du säger stämmer men vad med attityden?

Är det så här det blir efter pellesoft's "trevliga" disskusioner som äger rum lite då och då?


mvh Frans

Hej
Om man skriver ett inlägg som handlar om stil, och
hur man skall behandla vårt skriftspråk,så får
man finna sig i att få påhopp,när man inte kan avstava,byta rad,
dvs skriva på ett läsligt sätt.

Tycker
Jag igen
DS

Det är ju ett elände att rutan man skriver i när man gör ett inlägg inte har samma bredd som slutresultatet i forumet (eller är det tvärt om...?).
Vad gäller placering av kommatecken och liknande har väl Sven en del kvar att lära.

Hej
Man ju göra som du gör ,strunta i kommatecken helt.

Till Kylberg du skrev bla.
>inte. Och den där variabeln ccOffset,

Inte kan man väl börja en mening med Och. Stil !!??

Phuuu
Sven

Du får ju tydligen avsluta meningar med kommatecken. Då borde väl Hans få börja meningar med 'Och'.

Det är ganska intressant att ingen hade några synpunkter på min
fråga om programmeringsstil, utan bara intresserade sig för att
jag skrivit svårläsligt.
Jag tror inte att det var svårt att läsa för den som verkligen bryr
sig om stilfrågor vad gäller programmering.
Jag vet inte hur jag skall tolka bristen på svar.

- Hans

Hmm.. måste fakstikt erkänna att jag inte svarade pga av den andra diskussionen som blossade upp...

Men visst har jag lite åsikter.

1. Jo visst är det snyggare med en funktion, men det är inte nödvändigtvis en bättre lösning

2. Globala variabler är aldrig bra. Förutom det gillar jag inte heller ByReflösningar då det inte är tydligt var ändringarna görs. Vill man använda byref, gör det för att spara minne, men använd den inte för att ändra. Vill man ändra något kan man skicka ut det igen.

Båda ovanstådende detaljer underlättar återanvändbarhet, förståelighet och underhåll.

//Emma

Hej
>Jag vet inte hur jag skall tolka bristen på svar.

Därför att dina inlägg är så elva in i helvete tråkiga.
Dessutom är dom inte speciellt konstruktiva.

Dina inlägg andas gnäll och negativism, det går aldrig hem.

DIXI
Sven

Hmm... Undrar om det verkligen kan vara så svårt att diskutera något konstruktivt istället för att gnälla på petitesser.

Hans frågade om programmeringsrekomendationer inte om hur man får ett bra betyg i svenska...

Visst underlättar det om man skriver väl - men det har vad jag vet aldrig varit ett krav för att programmera.

//Emma - som tycker att den delen av diskussionen aldrig borde börjat

Tack för din uppriktighet Sven!
Det är kanske delvis rätt det du säger att mina inlägg andas gnäll -
jag är inte speciellt förtjust i VB, det skiner säkert igenom. Jag är
ledsen för det. Men jag hoppas väl kanske att få hjälp att mera
se VB positiva sidor.
Jag ser fram emot VB.net, där kommer en del förbättringar.

Om jag skall vara helt uppriktig så hade jag nog ändå uppskattat
mer om du istället delat med dig av dina erfarenheter av programmeringsstil istället. Om jag förstått rätt har du lång erfarenhet
av VB-programmering. Som det nu blev, kom min fråga i skymundan
och jag tvekade länge om att fråga på nytt (tur att jag gjorde det
ändå eftrsom jag på det viset fick ett riktigt svar).

- Hans

Tack för svar Emma!
När menar du att subrutiner skulle behövas istället för funktioner
(om det var det du menade)? Dom är, som jag förstår det, bara
funktioner som inte returnerar något. Och eftersom man ändå inte
behöver ta hand om ett eventuellt ointressant resultat från en
funktion (man använder bara sidoeffekten av den) så kan man,
som jag tycker, likaväl slopa sub helt och hållet. Många språk
har ju bara funktioner och klarar sig bra ändå...

- Hans

Hans, det verkar som din fråga var lite för komplicerad för att SvenPondare skulle klara av att svara. Och han måste ju in och besservissa sej överallt så han fick hitta något att skriva om och då var det tyvärr du som råkade illa ut.

Men han bättrar sej säkert, eller?

Sven är ofta hjälpsam, men kan också vara lite väl uppriktig - det
är helt ok för mig. Alla kan inte vara överns om allt.
Men när jag skriver om något här vill jag gärna ha diskussion om
det jag tagit upp, inte något annat. (Jag vet att jag sitter i glashus
och kastar sten här, det har hänt att även jag har kommit med
sidoordnade inlägg.)

Är det verkligen bara Emma och jag som har synpunkter på
programmeringsstil i VB?
Jag skulle gärna vilja veta hur andra gör - eller hur dom tycker
att man borde göra :-)

- Hans

Hej igen

>Jag skulle gärna vilja veta hur andra gör -

Jag är uppfödd i ett fattigt hem,där vi hade jordstampat golv.

En sak kan jag om stil,du får inte ha kniven i mun när
du programmerar.

mvh
Sven

Hmm mina programmeringsåsikter gäller inte enbart VB iofs... =)

Tycker att de kan appliceras på de flesta språk. man ska lätt kunna se var man kommer in och går ut ur en funktion och även vad man får tillbaka. Globala variabler är alltid ett no-no, vilket även gör att jag ogillar VBs byRef argument så tillvida att det inte sparar minne (tex när jag behöver en minneskrävande inparameter som inte ska ändras - bättre med byref än byval... )

Hans - jovisst är det en bra standard att göra subar till boolean-funktioner. På så vis har man fixat en felhantering utan att behöva anstränga sig. Dock har jag inte fått in vanan ännu, och det behöver inte anses som bättre programmering... =)

Är lite anti-VB själv eftersom jag tycker att man börjar bakvänt iom att man börjar med gränssnittet. Själv föredrar jag att programmera programmet, testa alla metoder och sedan knyta det till ett gränssnitt.

//Emma - som är skadad av modelleringskurserna... =)

Jag skall ju ärligt säga att jag är en stilslarvare själv, faktiskt.
Jag kan bara skylla på att jag inte hittat rätt i VB ännu, jag vet inte
hur jag skall förhålla mig, det är därför jag ställer dom här frågorna.

Man kan väl skriva en hel del a programmet först och peta dit
användargränssnittet sist, om man har minsta möjliga kod i Formen?
Har inte provat eftersom det jag gör mestadels är väldigt dialogorienterat.
Inom Extreme Programming börjar man med att göra minsta möjliga
för att programmet skall kunna göra/visa bara något av det viktigaste,
det får inte ta mer än en eller ett par dagar. Sedan bygger man på
och provar sig fram. En funkande version skall finnas i slutet av varje dag. Man går hem i tid - håller 40 tim/vecka :-)

- Hans

Apropå att hålla sig från ämnet...
Copymemory är ändå snabbare än MidConcat metoden i exemplet.
Stränghanterings problemet försvinner i VB.NET.

Det är alltid applikationen som bestämmer om det är lämpligt att skicka
ByRef eller ByVal. Själv föredrar jag att alltid skicka ByRef då detta är
lämpligt.

Här är mina argument för detta.

1. Spar Minne
2. Snabbare program
3. Bättre struktur
4. Färre variabeldeklarationer
5. Snyggare program.

Vidare finns några andra grundregler.

1. Aldrig, aldrig, aldrig skicka in en ByRef-variabel i en funktion. OK
den kan skickas som ByRef, men den får inte ändras. En funktion
får endast returnera ett värde. Dess inparameter får ALDRIG ändras.
Då skall man istället deklarera en Subrutin. (Undvika tvetydigheter)

2. Alltid med omsorg välja namn på subrutinen så man vet vad den gör.

3. Aldrig, Aldrig använda property get, property let, property set. Detta
är ett av det värsta otygen som finns i VB. Man skall istället använda
funktioner för get och subrutiner för set och let. (Men det är ju min
personliga åsikt.)

När det gäller att skriva snyggt i detta forum gäller det som förövrigt.
MAX ca 6 rader per stycke. komma och punkt där så bör. Jag praktiserar
desuutom metoden att trycka enter då texten kommer till högermarginalen
i TEXTAREAN.

Nåja ha det gott allehopa.

/peterh

Hej
Tycker peterh :s inlägg hamnade under exakt rätt rubrik,
till skillnad av flera härovan. Inlägget hade Stil, lättläst sakligt.

Snyggt ett föredöme för stil i inlägg.
Fö tycker jag att Kartago skall förstöras.

mvh
Sven

Låter som något fler borde efterleva.. =)

/E

> 3. Aldrig, Aldrig använda property get, property let, property set. Detta
> är ett av det värsta otygen som finns i VB. Man skall istället använda
> funktioner för get och subrutiner för set och let. (Men det är ju min
> personliga åsikt.)

Varför?

Varför skulle globala variabler vara av ondo ???

Globala variabler har definitvt sina användinsgområden och är fantastiska hjälpmedel vid många programmerings problem ..

Sven, skärp dig nu lite va... DU har många vettiga åsikter om standard VB, men ingen tycker om en upplåst, uppkäftig, ofta svamlamde, gammal gubbe som helt enkelt bara är ute efter att vräka ur sig sin egen frustration på andra ...

Globala variabler ska användast i minsta möjliga mån...

Varför det ??? Hur motiverar du det??

Vinsten med globala variabler kan i vissa fall vara hur mycket som helst .. Det finns två drawbacks som jag kan tänka mig, tar mer minne, men kan man leva med det är det ok ...

Den andra varianten är när man kör en komponent i COM+/MTS då globala variabler kan liknas vid state och vi för isolerings problem ...

Men fö, vad är så dåligt med dem ???

Globala variabler...

visst är de praktiska att använda men tycker fortfarande att de bör undvikas.

Det är:

dålig programmering
du kan inte tydligt se var de används och till vad
du kan inte se var de ändras, vilket försvårar spårning vid ev bugg
programmet blir svårare att underhålla
koden blir svår (om inte omöjlig) att återanvända

//Emma

Hej
Ang Globala variabler.

Det finns ett fall där man absolut skall välja Global

Då man finner att i en Sub eller Function behövs en Static variabel.
Man skall aldrig använda Static.Gör variabeln Global istället.

mvh
Sven

>dålig programmering
håller inte med för 5 öre.. Dålig använding av globala variabler leder till dålig programmering, men globala variabler i sig tillhör de nyttiga verktygen.

>du kan inte tydligt se var de används och till vad
därför dokumenterar man sin kod. Dessutom ser jag inte ser man de t direkt om man tittar på en metod ... har man korrekt naming convention så finns det inget luddig tmed vad en variabel är för ngt .. sätt ett G framför så vet du att det är en global en ..

>du kan inte se var de ändras, vilket försvårar spårning vid ev bugg
>programmet blir svårare att underhålla
Håller inte med ... om du spårar ett program på rätt sätt så ser du direkt när en global variabel ändras och vart ... gäller bara att kunna sätta upp sin debugg miljö ordentligt.

>koden blir svår (om inte omöjlig) att återanvända
Varför det??? Det här argumentet förstår jag inte alls ..

Om jag har gjort en funktion som avänder sig av direktåtkomst
av en global variabel (alltså inte som argument till funktionen)
så kommer denna funktion endast att kunna användas i ett
sammanhang där denna variabel finns.

- Hans

Tack peterh för bra synpunkter. Särskilt vad gäller propertyset/get -
jag har alltid undrat vad dom skall vara bra för, men ändå använt
dom eftersom jag uppfattat att det är så man gör i VB. Dom finns
ju redan inbyggda i VB egna klasser (dessutom med en del
mysko default-properties som villat bort mig totalt ibland innan
jag begrep hur det hängde ihop).

- Hans

Svar till Andreas Hillqvist om varför inte använda property Get,Let och Set.

Som sagt det är min personliga åsikt. Det kanske beror på att jag från
början inte är VB-programmerare.

Jag tycker inte det känns rätt att använda dem bara.

De är säkert bra för nåt men jag har svårt att se till vad. Tala om för mig
så kanske jag kan ändra mig ?

/peterh

Public Property Let ID(value as long)

If value < 0 Then
err.raise vbObjectError + 1001, "wherever", "ID need to be a positive number"
Else
m_localID = value
End If
End Property

Public Property ForeColor(color as OLE_Color)
txtname.forecolor = Color
txtzip.forelcolor = Color
lblText.forecolor = Color
End property

tex ...

för att inte nämna de gånger då Set är suvveränt för att skicka objekts referenser till ett bussiness fascade objekt ...

Det går precis lika bra med selleri:

Public Function ID(value as long) as boolean
If value < 0 Then
ID = false
(+ev felhantering lika Patriks förslag)
Else
m_localID = value
ID = true
End If
End Function

På köpet får man möjlighet att hantera ev fel externt
- Hans

en sub returnerar inget,
men en function kan returnera vad som hellst.....

boolean, string, integer, long ect...

testa:
public function Test(strText as string) as string
Test = strText
end function

tjam det funkar ju men detr ör definitvt dåligt ur systemdesign synpunkt ... en egenskap skall aldrig vara en metod ...

dessutom så fungerar felhanteringen exakt likadant i en property set/let/get som i en function och om du gör ett test så vinner du ingenting i prestanda på att anropa funktionen istället för en set/let/get ...

men du vinner en hel massa på läsbarhet osv ..

Rent pedagogiskt är det fel med property get/let/set

När man jobbar med Objekt är meningen att objektets egenskaper skall
vara inkapslade. Med hjälp av property get/let/set så kan man ändra
dessa inkapslade egenskaper. Men vad är vitsen, du skulle lika gärna
kunna deklarera egenskaperna publika och använda likhetstecken för
att tilldela egenskaperna egenskaper.

Se koden nedan

Option Explicit

Private Sub Form_Load()
Dim s As myObject
s.pSize = 100 '// Public variabel
s.size = 100 '// Privat variabel via property let
s.setSize 100 '// Private variavbel via interface
End Sub

s.pSize = 100 ser exakt ut som s.size = 100
Den enda vinningen är att du kan kontrollera vilka värden som stoppas
in i objektets egenskap. Men det är exakt det du kan göra genom att
använda en subrutin istället.

Den sista interfacemetoden är rent pedagogiskt bättre ur den synvinkeln
att man inser att den ändrar egenskapen hos en i objektet inkapslad
egenskap.

Ser vi på motsvarande sätt att utläsa en egenskaps värde får vi följande
kod.

Option Explicit

Private Sub Form_Load()
Dim s As myObject
Dim size As Integer

size = s.pSize '// publik variabel
size = s.size '// property get
size = s.getSize '// interfacemetod

End Sub


Även här tycker jag det är mer pedagogiskt riktigt att använda
interfacemetoden för att hämta en egenskaps värde.

Jag tycker det känns fel att använda property get/let/set på grund av
dessa argument.

öhhh, jag vet inte vilken skola du lärt dig pedagogik på men har aldrig hört ditt resonemang förut ... För det första är även egenskaper interface beronde (om vi pratar COM) lika mycket som en metod ...

men det får stå för dig ... det finns en ganska given anledning till varför egenskaper för ett objekt har existerat i objekt orienterad programmering (riktig OO) en mycket lång tid. Det finns också en bra anledning till att de flesta objekt använder sig av egenskaper ...

Som sagt det skiljer 0 i prestanda att ropa på en property set/let/get och en subrutin. Men däremot så ur OO synvinkel är en egenskap något som formar eller beskriver ett objekt (likt färgen på en bil) och metoder är en händelse som objektet utför (likt gasa på en bil). Mer pedagogiskt än att skilja på egenskaper och händelser för ett objekt kan det ju inte bli .. .

Det enda argumentet jag kan tänka mig att properties skulel vara sämre än en sub ... är om datan skall vidare.. Då är en sub bättre eftersom du kan skicka all information på en gång istället för att sätta varje egenskap enskilt. Men då avviker vi från OO regler och de scenarion där vi vill använda det är nästa uteslutande när vi har externa / distribuerade COM/MTS/COM+ objekt.

Visst, du kan defintivt använda publika variabler om du känner för det. Men oftast så vill du kanske kontrollera värdet eller låta värdet replikeras över flera interna egenskaper. För att då stödja OO så existerar set/let/get .. Det fungerar på liknande sätt i c/c++ och alla andra språk som hävdar att de har OO stöd ...

>men det får stå för dig ... det finns en ganska given anledning till
>varför egenskaper för ett objekt har existerat i objekt orienterad
>programmering (riktig OO) en mycket lång tid. Det finns också en bra
>anledning till att de flesta objekt använder sig av egenskaper ...


Hmm... riktig OO säger du... antar att du tom menar OOP - men vi ska
inte vara så petiga.. =)

Då borde du också veta att all OOP använder sig av åtkomstmetoder
för att komma åt sina variabler(/attribut, om vi pratar OOA). Dvs precis
det som peterh verkar syfta till med det han kallar interface-metod.

//Emma

OO är ett fullgott uttryck vad gäller Objekt orientering OOP och OOA är specifka delar ...

I vb så är just Let/set ocg get till för åtkomstmetoder av egenskaper och utan dem kommer inte COM veta om att det är en egenskap vi pratar om utan tro att det är en metod..

För vi måste prata COM när vi tittar på VB eftersom vi inte kan prata någon annan objekst model i det språket.

I OO markerar du dina attribut som egenskaper även om du använder åtkomstmetoder, i VB gör du det samma genom att använda property procedures...

OK man kan lära sig OO på säkert många sätt. Två av dem kan vara
att.

1. Utöva det
2. Lära sig teorin bakom OO

Jag är en 2:a

Eftersom VB inte är OO utan bara Object Baserat språk. Så är inte OO
tillämpbart fullt ut på VB.

I alla andra språk som jag känner till sätts och hämtas ett objekts inkaplsade
egenskaper med hjälp av interface-metoder. Det är bara i VB där
property get/let och set finns.

Det måste ju vara av någon anledning som dom har kommit till. Olyckligtvis
som många andra gånger skall MS gå egna vägar och uppfinna egna
sätt att lösa saker på.

Jag anser att det varit bättre att dessa property.... inte skulle finnas

Tvetydigheten är ju påfallande.

Ledsen också Patrik Löwendal att du inte förstod vad jag menade.

Jag är en stor motståndare till publika deklarationer av entitesvariabler,
vilket det verkar som som du inte riktigt har förstått.

Objekt däremot kan tjäna ett greater purpose i att vara global eller publikt.

/peterh

Ännu en anledning att inte använda property Let/Get och Set..... kolla in tråden "Me i klasser i VB/Allmänt"

[peter.h]