Har några sådana meddelanden när jag kodar i MPLAB IDE för PIC18F442 och skulle gärna gå över den gränsen regelbundet för att det blir lättare att namge sina funtioner korrekt då.
Spelar det någon vesäntlig roll att de förkortas eller blir det rätt i slutänden ändå?
Ser ju bra ut medans man kodar och kompilerar och har iaf inte märkt några problem hittils.
Någon som har en aning eller är det bara att skriva så långt man önskar?
"208 Label truncated at 32 characters", är det et
"208 Label truncated at 32 characters", är det et
Senast redigerad av nanopile 3 september 2008, 05:57:17, redigerad totalt 1 gång.
> De blir sannolikt bara rörigt i MAP och list filerna.
Förmodligen en korkad fråga om man vet vad man gör:
Vad spelar det för roll om det blir rörigt där?
Andvänds de annat än vid kompileringen?
> Mer än 32 tecken är *inte* "korrekt"...
> Du har valt väldigt konstiga/opraktiska namn om du tycker att du behöver det.
Säkert inte korrekt men väldigt andvändbart när man namger såhär:
ResetPointersIfSerialCommReceptionStackEndIsReached
Hur borde man namnge istället?
Förmodligen en korkad fråga om man vet vad man gör:
Vad spelar det för roll om det blir rörigt där?
Andvänds de annat än vid kompileringen?
> Mer än 32 tecken är *inte* "korrekt"...
> Du har valt väldigt konstiga/opraktiska namn om du tycker att du behöver det.
Säkert inte korrekt men väldigt andvändbart när man namger såhär:
ResetPointersIfSerialCommReceptionStackEndIsReached
Hur borde man namnge istället?
T.ex. Check_Serial_Rx_Stack
Jag använder ytterst sällan mer än 25 tecken till en funktion, det blir så mycket att skriva.
Dessutom luktar det lite av att du har en "shit-load" av processer som egentligen kan bakas ihop till stor del.
Jag har som tumregel att om en funktion bara används ett ställe bör den skrivas där den kallas ifrån och bara i sällsynta fall "brytas loss" som en självständig funktion. Kommentarer i koden anger självklart om en kodsnudd har speciell betydelse och varför den kan kännas felplacerat om det är så.
Jag använder ytterst sällan mer än 25 tecken till en funktion, det blir så mycket att skriva.
Dessutom luktar det lite av att du har en "shit-load" av processer som egentligen kan bakas ihop till stor del.
Jag har som tumregel att om en funktion bara används ett ställe bör den skrivas där den kallas ifrån och bara i sällsynta fall "brytas loss" som en självständig funktion. Kommentarer i koden anger självklart om en kodsnudd har speciell betydelse och varför den kan kännas felplacerat om det är så.
Nog för att det finns en "shit-load" av processer, de flesta har med debuggningen att göra.
Tar ut värden här och var o skickar till datorn så jag ser vad jag gör.
> T.ex. Check_Serial_Rx_Stack
Mjo, det har du ju rätt i, ligger nog mycket känsla i att vilja skriva utförligt.
Vill gärna kunna veta exakt vad funktionen gör.
Har sett i andras kodexempel att de inleder olika saker med både en två och tre underscore och ibland även olika antal mitt i, vad betyder de där olika strecken och dess placering?
Fast då pratar vi inte assembler utan C++ och C
Tar ut värden här och var o skickar till datorn så jag ser vad jag gör.
> T.ex. Check_Serial_Rx_Stack
Mjo, det har du ju rätt i, ligger nog mycket känsla i att vilja skriva utförligt.
Vill gärna kunna veta exakt vad funktionen gör.
Har sett i andras kodexempel att de inleder olika saker med både en två och tre underscore och ibland även olika antal mitt i, vad betyder de där olika strecken och dess placering?
Fast då pratar vi inte assembler utan C++ och C
funktionsanrop() //Reset Pointers If Serial Comm Reception Stack End Is Reached
Min bild är att underscorearna handlar om hur låg nivå funktionerna arbetar på. Ett underscore betyder att programmeraren bör ha koll på vad h*n pysslar med när funktionen anropas, ungefär. Två underscore betyder att användaren verkligen bör ha koll, typ. Fast jag vet inte om det är ett allmänt förfarande.
Min bild är att underscorearna handlar om hur låg nivå funktionerna arbetar på. Ett underscore betyder att programmeraren bör ha koll på vad h*n pysslar med när funktionen anropas, ungefär. Två underscore betyder att användaren verkligen bör ha koll, typ. Fast jag vet inte om det är ett allmänt förfarande.
> Andvänds de [map och list filer] annat än vid kompileringen?
De *skapas* vid kompileringen/assembleringen.
Och menigen är att de ska användas vid felsökning, och inte
blir det lättare av att namnen har trunkerats !
Skit samma, det finns absolut ingen anledning att använda
symboler som överskrider verktygets maxgräns, och det finns
massor av anledningar att *inte* göra det.
> ResetPointersIfSerialCommReceptionStackEndIsReached
Du måste skämta. Det där var inte speciellt smart.
Väldigt svårläst är det också, det ser bara ut som en
slumpvis rad med blandade tecken. Jag vågar inte tänka
på hur en kod ser ut som är full av sådana där anrop.
Namnet tar ju upp halva raden !
> Vill gärna kunna veta exakt vad funktionen gör.
Att ha hela dokumentationen i *namnet* på funktionen !?
Det måste finnas bättre sätt att dokumentera.
Angående underscore...
Många utvecklingsmilljöer har reserverat vissa namnformer för
systemets inbyggda funktioner (behöver inte vara de som är
anropbara, utan de som t.ex en kompilator själv anropar intern).
Ett ganska vanligt format är just en (eller två) inledande underscore.
Den miljö där jag jobbar har reserverat dollar "$" till systemanrop,
t.ex SYS$TIME(). I egna funktioner använder man inte "$" så det blir
aldrig några konflikter.
De *skapas* vid kompileringen/assembleringen.
Och menigen är att de ska användas vid felsökning, och inte
blir det lättare av att namnen har trunkerats !
Skit samma, det finns absolut ingen anledning att använda
symboler som överskrider verktygets maxgräns, och det finns
massor av anledningar att *inte* göra det.
> ResetPointersIfSerialCommReceptionStackEndIsReached
Du måste skämta. Det där var inte speciellt smart.
Väldigt svårläst är det också, det ser bara ut som en
slumpvis rad med blandade tecken. Jag vågar inte tänka
på hur en kod ser ut som är full av sådana där anrop.
Namnet tar ju upp halva raden !
> Vill gärna kunna veta exakt vad funktionen gör.
Att ha hela dokumentationen i *namnet* på funktionen !?
Det måste finnas bättre sätt att dokumentera.
Angående underscore...
Många utvecklingsmilljöer har reserverat vissa namnformer för
systemets inbyggda funktioner (behöver inte vara de som är
anropbara, utan de som t.ex en kompilator själv anropar intern).
Ett ganska vanligt format är just en (eller två) inledande underscore.
Den miljö där jag jobbar har reserverat dollar "$" till systemanrop,
t.ex SYS$TIME(). I egna funktioner använder man inte "$" så det blir
aldrig några konflikter.
>> ResetPointersIfSerialCommReceptionStackEndIsReached
> Du måste skämta. Det där var inte speciellt smart.
> Väldigt svårläst är det också, det ser bara ut som en
> slumpvis rad med blandade tecken.
Jag tycker det är som att läsa vad som helst men jag ska visst vara dyslektiker, kanske jag läser på annorlunda vis, för mig är varje ord grafik så jag läser inte varje bokstav för sig.
Intressanta saker läser jag snabbt och tråkiga långsamt, vet inte varför men så är det.
Kanske alla läser olika, trodde alla gjorde som jag innan jag såg en diskussion om saken på tv.
> "$" till systemanrop
Låter klokt
Map och list filer visste jag itne att de var till för felsökning, har nog aldrig behövt göra det, har varit lättare att titta i program listing i MPLAB IDE samt att stega sig fram o se vad som händer.
> Du måste skämta. Det där var inte speciellt smart.
> Väldigt svårläst är det också, det ser bara ut som en
> slumpvis rad med blandade tecken.
Jag tycker det är som att läsa vad som helst men jag ska visst vara dyslektiker, kanske jag läser på annorlunda vis, för mig är varje ord grafik så jag läser inte varje bokstav för sig.
Intressanta saker läser jag snabbt och tråkiga långsamt, vet inte varför men så är det.
Kanske alla läser olika, trodde alla gjorde som jag innan jag såg en diskussion om saken på tv.
> "$" till systemanrop
Låter klokt
Map och list filer visste jag itne att de var till för felsökning, har nog aldrig behövt göra det, har varit lättare att titta i program listing i MPLAB IDE samt att stega sig fram o se vad som händer.
När jag läste denna tråd, komm jag tänka på att jag frågat om liknande för ett tag sen, kolla på denna tråd: http://www.elektronikforumet.com/forum/ ... ht=#300519
