sciencetalk

Dikwijls hoor je van alles en nog wat over open source code. Het zou zijn voordelen hebben daar iedereen kan kijken hoe het werkt.

Wel ik had graag ook eens een open source project bestudeerd, liefst één of andere editor geschreven in java of c++

Probleem is dat ik altijd een hoop files download waar ik het bos niet meer door de bomen zie één grootte war boel waar ik eigenlijk niets uit haal.

Mijn vraag is nu is er een project goed gedocumenteerd en is er iets aan te raden voor beginners of vindt ik ergens een voorbeeld studie een soort wegwijzer?

Groeten.

Algemene regel: open source, code in C of aanverwante taal, begrijpelijke commentaar en documentatie... kies maximaal 2.

Wat bedoel je met kies maximaal 2?

Van de drie eisen die je noemt: open source, code in C of aanverwante taal, begrijpelijke commentaar en documentatie.

Maw je hebt maar twee echte opties:

- open source en een begrijpelijke commentaar en documentatie -> niet in C of verwante taal geschreven.

- open source en in C of verwante taal geschreven -> helaas geen begrijpelijke documentatie of commentaar

Maar wellicht hebt je iets aan deze twee links: google's codesearch, en koders

Ik neem aan dat je de gnu build tools(automake, autoconf, more) wel al kent en kunt gebruiken?

Ik neem aan dat je de gnu build tools(automake, autoconf, more) wel al kent en kunt gebruiken?

Nee ik gebruik windows, ken niets van linux. Ben vooral op zoek naar code van windows programma's zoals bv open office.

Die code opzich vind ik wel maar éénmaal gedownload heb je een hoop mapjes waar ik niet wijs uit raak, er zit nooit een handleiding, uitleg bij wat wat doet. hoe de structuur van een programma ineen zit.

Je wilt te veel.

Bij een grote onderneming, zoals Philips, is de tijd die men uittrekt voor het samenstellen van documentatie veel groter dan de tijd die men besteed aan het daadwerkelijke coderen.

Als je als individu de uiteindelijke hoeveelheid geproduceerde documentatie bekijkt, dan kom je er niet meer uit.

Bij open source projecten is het nogal eens omgekeerd. Velen willen graag coderen, maar weinigen voelen de behoefte heel veel tijd aan documenteren te besteden. Ieder individu werkt ook aan een klein onderdeel van het geheel. Een totaaloverzicht heeft niemand. Als je in een open source programma iets wilt doen moet je weten wat je precies wilt doen. Pas dan kun je zoeken naar de plek in de code waar je module of class zijn plek moet vinden.

Er werken zoveel mensen aan dergelijke projecten, en ieder met zijn eigen specialisme, dat je niet moet proberen het programma te begrijpen, of ontmoedigd moet raken als je de brij aan bestandjes ziet.

Ik zou zeggen, bedenk zelf een programma dat je zou willen ontwikkelen en zoek anderen die met je mee willen doen.

Van bestaande open source code leer je niets.

Zelf ben ik de laatste tijd nogal bezig met phpBB3. Daarvan heb je de phpBB3 sourcecode documentation. Is dat wat je bedoelt?

Geen idee eigenlijk of dat ook bestaat voor dingen als OpenOffice, maar dat lijkt mij wel handig.

Bert F schreef:Nee ik gebruik windows, ken niets van linux. Ben vooral op zoek naar code van windows programma's zoals bv open office.

Die code opzich vind ik wel maar éénmaal gedownload heb je een hoop mapjes waar ik niet wijs uit raak, er zit nooit een handleiding, uitleg bij wat wat doet. hoe de structuur van een programma ineen zit.

Hoe ziet jouw ontwikkel omgeving er dan uit?

Kijk hier maar eens, speciaal voor windows.

http://osswin.sourceforge.net/

Sun's Open office? You're kidding. Duizenden manuren zitten daarin. Onmogelijk om daar iets van te begrijpen.

Idd, ik denk dat het sowieso onmogelijk is om van grote projecten je een volledig beeld te kunnen vormen. Laten we maar open office als voorbeeld gebruiken, de kans dat je ooit het volledige overzicht doorhebt (wat naar waar link, etc) zal vrij klein zijn als je er geen ettelijke uren zal met bezig zijn. Je kan hoogstens op specifieke zaken gaan zoeken (bv hoe voegt men een tabel in, hoe voegt men opmaak in, ...) om te kijken hoe hun het doen en daar uit te leren. Een volledig project bestuderen, daar is bijna geen beginnen aan (zelf met goede documentatie).

Toegankelijkheid is ook een van de reden waarom veel mensen beginnen met een unix-like os (bv. Freebsd): De meeste applicaties zijn nog klein en goed te begrijpen (bv. cat, uniq, sort).

Als je een beetje overweg kunt met SCM dan kun je zelfs de stappen waarin het programma zich ontwikkelde volgen.

Bedankt voor de reacties.

Bvb open office de manier waarop de interface werkt of het algoritme achter de spellingscontrole is dat specifiek genoeg? En hoe begin je dan aan zo’n klein stukje.

Wat ik ook altijd vreemd vind, als je de code dan download dan krijg je ne hoop rare bestanden en niet gewoon klassieke tekstbestanden waarin je programmeert.

Groeten.

Geef eens een voorbeeld van wat jij ''rare bestanden" noemt?

Een deel van die bestanden zijn bedoeld voor andere platformen. Een andere deel zijn bedoeld voor de build-tools: In wezen programmas die de build-tools vertellen hoe het de applicatie moet maken. Bij grote software met graphisch interfaces zijn er dan nog (al dan niet leesbaar onder jouw platform) plaatjes, tekst, xml, fonts en andere bestanden...

Hier haal ik de source van open office volledig onderaan bij source package

http://download.openoffice.org/2.4.0/source.html#browsing

dan klik ik op core source package

bestanden met
in.

Ik heb de source opnieuw gedownload omdat ik niet meer op mijn laptop geraak en nu zie ik dat er idd ook gewoon code bijzit.

Groeten.

Inzake een offcie pakket met tekstverwerker e.d.

Een tekstverwerker is niet een eenvoudig programma.

Vooral als men te maken heeft met een goede snelle grafische interface naar de gebruiker toe.

Bepaalde zaken in tekstvewerking zijn nogal lastig.

Ik heb zelf ooit een eenvoudige tekstverwerker gemaakt met een printprogramma.

Tegenwoordig heb je 1.6 miljoen bytes aan code voor een eenvoudige tekstverwerker en dat betekent rond de:

100000 programmeerregels.

dat is rond de 2000 A4 tjes aan code...

(dat is dan zonder de documentatie)

Zo'n programma heeft een telefoonboek aan documentatie.

Als men zo'n programma naar je hand wilt zetten of speciale dingen erbij wil maken dan vergt dit een studie van maanden als men 100% betrouwbaar wilt blijven.

(ligt er ook aan wat men erin bouwd)

In zo'n groot programma zit soms zelfs materiaal dat niet eens wordt toegepast maar voor latere doeleinden is geschreven alvast...

Ook zitten er testroutinen in voor de programmeur.

(ik kom soms van die stukken tegen in mijn software die ik schrijf)

Het afwerken van vele tekstformaten vergt ook conversies van het formaat naar het interne formaat en andersom.

Intern wordt de tekst niet in 1 reeks opgeslagen maar met speciale technieken.

Dit is nodig om teksten van 2 megabyte enzo aan te kunnen zonder gedonder in het vooronder.

Dus een simpele letter die jij typt gaat via veel software.

(dit is bij frontpage express dus niet goed gedaan want die gaat op tilt bij belasting)

Het bestuderen van een code kan men het beste doen door de routinen apart te gaan bekijken en wel zodanig dat men eerst de lagere bestudeert.

De grote algemene zeggen meestal niets.

Routine auto zegt niet hoe de auto werkt...

Routine startmotor zegt wel dat hij de motor start.

Dus als men routine startmotor en de rest bestudeert weet men vanzelf wat de routine auto doet.

En die startmotor werkt op 12 volt en niet op 24....

(dus zomaar de startmotor toepassen in een ander projekt kan niet zomaar)

Zo heb ik in mijn compiler programma wat delphi zaken toegepast maar elk stukje heeft wel een probleem, een missende eigenschap of een ander naar probleem.

DUS: alles zelf schrijven is dan de remedie.