atmel studio 7 "blokken verbergen"

een goedendag,

ik ben in AS7 een code aan het schrijven die nogal behoorlijk lang is (in mijn ogen dan) zit nu op 624 regels, maar het worden er nog veel meer.
als ik nu aan het programeren ben dan scroll ik me wezeloos van onder naar boven in het programma en terug, en de kans op het verliezen van het overzicht is nogal groot.
nu loopt er helemaal links in het programeer veld een licht grijs vertikale lijn over de gehele lengte van het programma, met zo hier en daar een vierkantje met daarin een -. klik je op die - dan "vouwt" er een deel van het programma in/weg,....en dat is fijn, hoef je niet zo veel te scrollen.
alleen die vierkantjes met die - erin lijken nogal willekeurig te staan.
de vraag is:
kan je de pos. van die blokjes aanpassen en ook de lengte wat hij daarmee "invouwt"

en nu ik toch aan het vragen ben: waar kan ik zien hoe groot het programma is in b.v. kbytes wat in de controller word gedownload.

Naar mijn mening: als je die [-] / [+] dingen nodig bent, dan is je file veel te lang. Een file moet niet meer dan 1 a 2 A4'tjes zijn. Sources voor verschillende functies horen in aparte files te staan.

Overigens, die []'en staan niet willekeurig. Ze staan bij iedere functie, if statement, etc.

[Bericht gewijzigd door flipflop op (24%)]

ja dat klopt, maar ze vouwen in mijn ogen willekeurig "in"

Op 21 december 2019 15:32:54 schreef flipflop:
Sources voor verschillende functies horen in aparte files te staan.

bedoel je daar mee dat verschillende blokken zoals b.v. "homing stepper" in een file moet staan die je "included" ?

edit: ik zei net ja dat klopt, maar dat blijkt toch niet overal het geval te zijn.

[Bericht gewijzigd door trix op (11%)]

Dat was een van de weinige 'features' van de Visual Basic IDE... ;)
Je kon iedere functie/sub apart in de editor krijgen uit een drop-down list... (heel overzichtelijk)

@flipflop
Kan zijn dat dat voor jou werkt maar dat is lang niet altijd haalbaar.
Wij hebben hier sourcefiles met meer dan 25000 regels code. Die ga je niet opdelen in 500 sourcefiles van 50 lijnen elk.

Wij hebben ook diverse sourcefiles van 2000...4000 regels, is soms gewoon handiger.
Daar zitten ook nog include files bij van elk een paar duizend regels zelfs...
(zijn voor aansturing PCI kaarten in PC en heeft weinig zijn om op te delen omdat alles bij elkaar hoort. Wordt dan eerder slechter als beter)

Als je naar een bepaalde functie/sub wilt krijg je (in deze IDE) een drop-down list bij drukken F8, dus kun je direct er naar toe...

[Bericht gewijzigd door Arco op (34%)]

is zoiets ook mogelijk bij AS7 ?

Schijnt een losse extensie te zijn: https://www.avrfreaks.net/forum/function-list-atmel-studio-6

Atmel studio heeft drop-down listboxes bovenin het edit venster. Als je die opent krijg je een lijst met de funkties in de sourcefile. Klik daar maar eens op.

Een beetje IDE heeft wel een functie lookup zodat je makkelijk kunt springen naar de definitie van een functie of variable etc. Dus dat houd je niet tegen om meerdere files te gebruiken.

Als je code echt vreselijk lang wordt ben je vaak toch niet echt goed bezig. Dan is er meestal toch wel iets mis met je code design. Dus ik ben het met flipflop eens.

Het aantal regels in een file is wat relatief, de ene geeft 500 regels aan, iemand anders een paar duizend. Maar 25000 regels is wel heel erg veel.

Even afgezien van code die je genereerd uit een andere programmeertaal, daar hoef je niet in te kijken als het goed is.
Een voorbeeld is gSoap: met een 50 tal interface functies genereerd die makkelijk 10000 regels code of nog meer (weet zo de getallen niet meer maar het was echt belachelijk veel).

Kortom: Maak meerdere sourcefiles waar functioneel dingen bij elkaar zitten en link die aan elkaar. Hoe dat in AS7 precies moet weet ik niet want ik heb die nog nooit gebruikt. Soms zijn het project files, soms makefiles.

Op 21 december 2019 16:50:11 schreef deKees:
@flipflop
Kan zijn dat dat voor jou werkt maar dat is lang niet altijd haalbaar.

Toch is het een van de ongeschreven regels in software design (en voor hardware/hdl geldt het ook). Het is natuurlijk geen harde zwart/wit regel, maar wel een goede richtlijn. Je geeft in je startpost zelf al aan waarom dat is.
Wb includen: nee, je include niks. Een software project kan bestaan uit een hele bundel source files. Die worden allemaal apart gecompileerd en door de linker aan elkaar gelinkt tot een eindresultaat (bv een exe file, of hex bij embedded).

klinkt alsof het datgene is wat ik zoek. gaat dat mer de "drop-down listboxes" die dekees aanhaalde bij AS 7 ?

Die sourcefile met 25000+ regels code is een onderdeel van een professioneel software pakket. Het project waar deze source in zit bestaat op zich al uit meer dan 100 sourcefiles en daar is dit er eentje van. Alleen al de definitie van een enkele class beslaat in een aantal gevallen al duizenden regels code, en we hebben ook enums met duizenden entries. En dat is dan een enkel project uit een pakket dat bestaat uit zo een 80 projecten die allemaal samenwerken en niet zonder elkaar kunnen funktioneren.

Dan kun je wel roepen dat het allemaal te groot en te complex wordt maar die code zit daar niet voor niks.

Een ander voorbeeld is database library sqlite. Die heeft het merendeel van de code in een enkele sourcefile van 70000+ regels code.

De include directory van de borland c++ compiler (BC55) voor windows bestaat uit 991 header files met in totaal 1125873 regels code. De grootste van die header files (mshtmlc.h) is alleen al goed voor 92435 regels code. En dit zijn alleen nog maar definities, nog geen enkele implemetatie.

[Bericht gewijzigd door deKees op (16%)]

@deKees: Als ik in de sloot spring, spring jij er dan achteraan?

Dat er vele voorbeelden van (commerciele) code zijn met lange source-files betekent niet dat dat dus een goed (of acceptabel) idee is.

Kleine, overzichtelijke stukken zijn makkelijker te maken en te onderhouden, en het is al meer dan 40 jaar bekend in zowel software-ontwikkeling als in de ontwikkeling van complexe systemen in het algemeen dat het beter werkt als je het probleem en de oplossing in kleine, afgeschermde stukken opdeelt.

Natuurlijk zijn er situaties waarin een source-file van >1000 regels de beste oplossing is, maar die zijn heel zeldzaam. Zeker als je gegenereerde code (een YaCC grammar kan met 10 regels makkelijk 1000 regels C opleveren, maar dan moet je de YaCC grammar beoordelen, niet de gegenereerde C-code) of HW-gerelateerde opsommingen (de .h file met registers van een microcontroller moet je niet opdelen, dat is zinloos) negeert.

In de praktijk is een lange, onoverzichtelijke file meestal het gevolg van een lang, onoverzichtelijk ontwerp. Als je dat oplost (classes opbreken, functies in deelfuncties verdelen) wordt een andere file-indeling vaak ook evident.

Het argument dat die code daar niet voor niks zit is onterecht. Dat die code zo is laat zien dat de auteur het probleem (dat de code moet oplossen) niet overzag. (of daar de tijd niet voor kreeg). Geen enkel probleem is zo complex dat het een superlange code nodig heeft.

Op 22 december 2019 01:24:49 schreef deKees:
Dan kun je wel roepen dat het allemaal te groot en te complex wordt maar die code zit daar niet voor niks.

Dat een project groot kan worden is daar aan toe, de getallen die je noemt aan totale aantal source/header-files is niks bijzonders ik heb nog veel gekkere dingen gezien.
En complexiteit is weer iets anders: Met een klein programma kun je ook iets complex maken.

Een ander voorbeeld is database library sqlite. Die heeft het merendeel van de code in een enkele sourcefile van 70000+ regels code.

Kijk dat klopt dus niet, slecht voorbeeld gekozen. In ken sqlite ook. Hier heb je het over de "amalgamation" versie van sqlite. De originele sources zijn allemaal netjes functioneel gescheiden en voor de distributie kun je kiezen of je de samengevoegde file wilt gebruiken, dan zijn ze allemaal aan elkaar geplakt.

-edit- Net even opgezocht: De /src/ directory bevat 157 source en header files en meer dan 1100 tests voor alle functies.

De include directory van de borland c++ compiler (BC55) voor windows bestaat uit 991 header files met in totaal 1125873 regels code. De grootste van die header files (mshtmlc.h) is alleen al goed voor 92435 regels code. En dit zijn alleen nog maar definities, nog geen enkele implemetatie.

Dat is wat ik boven ook al bedoelde, het gaat niet om het aantal totale regels maar de opsplitsing in behapbare en begrijpbare blokken.
En ik sta er niks van te kijken dat die headerfile in het originele archief van borland gewoon meerdere files zijn (maar ik weet dat niet).

Voor distributie van hulp paketten en libraries is het eigenlijk niet boeiend hoe groot een header file is (zie de sqlite lib). Je zou documentatie moeten hebben van de API om de functies te kunnen gebruiken (wat helaas bij een hele hoop open source spul ontbreekt). Dan hoef je nooit in de header files te gaan zoeken.

-edit- Trouwens: sqlite is een van de best gedocumenteerde en geteste open source libraries die ik gezien heb. Daar weten ze dus precies hoe het dus wel moet.

@blurp

Nonsens. Het klopt wel dat kleine overzichtelijke programma's makkelijker zijn natuurlijk. Maar professionele pakketten zijn gewoon groot en complex doordat er veel functionaliteit in zit. Ik ben gewend om te werken met een pakket met meer dan 30 miljoen regels code. Die wordt echt niet overzichtelijker als je die gaat opsplitsen in 200k sourcefiles als dat al mogelijk zo zijn. We hebben structs van meer dan een megabyte. Hoe ga je die declareren in een header file van 100 regels? Alleen de lijst me include files is soms al meer dan 100 regels.

En SqLite is inderdaad een van de best werkende libraries. Niks dan lof, ook voor de bijgeleverde documentatie. Maar wel een voorbeeld van een pakket dat behoorlijk complex is tgv veel funktionaliteit.

[Bericht gewijzigd door deKees op (15%)]

@deKees:

Groot en veen functionaliteit hoeven niet synoniem te zijn met complex. Ik geloof je direct dat je met een complex, groot project van 30miljoen regels werkt.
Ik zie ook dat heel veel grote (commerciele) softwarepakketten buggy en/of traag as hell zijn.

Het punt is juist dat als je je ontwerp goed aanpakt, je code en sorcefiles niet groot en complex hoeven te zijn. Meer specifiek:

We hebben structs van meer dan een megabyte. Hoe ga je die declareren in een header file van 100 regels?


//triviaal:
struct megabyte {
    char c[1024*1024];
}
// meer inhoudelijk
enum pinType { IN, OUT, BI, POWER, GND, MAGIC, HAIR };
struct pin {
    char name[32];
    char num[32];
    pinType type;
    int id;
}
struct comp {
   char name[32];
   char ref[32];
   struct pin pins[1024];
   int id;
}
struct wire {
   int pin1_id, pin2_id;
   int id;
}
struct wire_list {
    int this_id;
    int next_id;
}

struct net {
   int id;
   char name[32];
   struct wire_list wires;
}

En er is geen enkele reden waarom net en wire in dezelfde source moeten staan. Maar als je nu een struct maakt met een circuit (die alle netten, wires, pins en components meeneemt) haal je de megabyte makkelijk. (Uiteraard zou je in het echt ook de char[32] nette, variabele-lengte strings maken.)

Als je 100 headers wil includen in een source file, kun je ook een aparte header maken met de includes. Of je afvragen waarom je abstractie-grenzen zo vaag lopen.

Maar complexiteit in de code is altijd een keuze. Soms welliswaar om historische redenen, soms omdat oplossen onderhand meer kost dan maar gewoon laten bestaan (zeker op de korte termijn van aandeelhouders), maar het is altijd een keuze.

Nutteloze code opsporen kost momenteel meer dan er winst te halen valt in het verwijderen er van. In een wat verder verleden was elke code uiterst belangrijk en werd er gewikt en gewogen welke het eindproduct haalde en welke niet. Tenslotte moest het werken op een 286 met 640kb geheugen. Vandaag is het wat dat betreft de sky is the limit. Waarom dan gaan zoeken achter een regel code die niet meer gebruikt wordt?

Enkele weken geleden was ik bij QinetiQ, het vroegere Verhaert space, in Kruibeke. Daar wordt nog steeds nagedacht over elke regel code in de satelliet. Hun Proba 1 draait momenteel al 18 jaar rond de aarde. De boordcomputer werkt nog steeds perfect. Initieel gebouwd om 2 jaar mee te gaan.

Op 22 december 2019 11:10:44 schreef deKees:
...Het klopt wel dat kleine overzichtelijke programma's makkelijker zijn natuurlijk. Maar professionele pakketten zijn gewoon groot en complex...

Jij leest niet goed wat er geschreven wordt! Niemand zeg dat een pakket niet heel groot kan zijn, dat snapt iedereen hier wel. Het gaat erom dat er structuur in zit, en daaruit volgend een nette verdeling in losse files. En dat hoeven echt geen files van 50 regels te zijn, maar 10k is veel te veel. Dan heb je gewoon alles bij elkaar in geplempt.
PS, er zit ook nog verschil in embedded en "dat andere". Embedded is vanzelf al compacter.

[edit] Het gaat dus niet om include files. Daar zit je functionaliteit niet.

.

[Bericht gewijzigd door trix op (99%)]

Ik heb hier includefiles van 50k+ Die worden nu eenmaal zo aangeleverd, en zijn ook logisch, omdat alles wat erin zit bij elkaar hoort.
(het kost veel meer tijd en moeite om met meerdere includes uit te spitten waar alles gebleven is omdat er niet echt lijnen zijn waarop het te splitten is.

Men heeft ooit geprobeerd dat te scheiden, maar dat was een drama. Je kon niks meer eenvoudig vinden. Ook hele korte includes die weer doorverwezen naar andere.
(ze worden zo aangeleverd dus wijzigen heeft weinig nut)

Ik vind sourcefiles tot een paar duizend regels geen probleem en een stuk makkelijker als allemaal kleine files.
(vaak bij wijzigingen resulteert dat in aanpassingen in diverse functies en dan is alles-in-een een stuk handiger)

ik ben eigenlijk nog op zoek naar een manier om mijn code op te delen in "hapklare" blokken zoals b.v. een blok homing stepper. als dat blok eenmaal werkt, kan dat worden verborgen.
nu heb ik denk ik een manier gevonden, alleen weet ik niet zeker of dat wel een goed idee is ?

zo'n blok sla ik op als een appart programma.
vervolgens doe ik in het hoofd programma:
solution explorer (is een appart veld)
rechter muisknop : add
dan exsisting item
vervolgens het bestand op zoeken in de browser en toevoegen.

dan krijg je in de solution explorer onder liberies je bestand te zien, als ook main.c.

een beetje omslachtig, maar het werkt.

of kan dit simpeler ?

edit: werkt denk ik toch niet.....wat beter testen nog.
edit2: drop-down listboxes kan ik niet vinden (geopperd door dekees)

Bij mij geeft Atmel studio een stel listboxes bovenin het edit window, net als VisualStudio waar het van afgeleid is. Heb jij dat niet?

ja...die heb ik wel inderdaad.

even kijken wat ik daar mee kan.

[Bericht gewijzigd door trix op (38%)]

Hoeveel code past er trouwens op een A4'tje? Dat is nogal afhankelijk van het font-size, en het is alweer een tijdje geleden dat ik nog sourcefiles heb afgeprint.

Toen werkten we trouwens nog met ketting-papier en hadden we nog applikaties die draaiden vanuit een 2732 Eprom, dus zo rond 1982.