Archief - [JAVA]

forloRn_ · 1 mrt 2009

BrEeZiE zei:
die @override zorgt er voor dat de standaard implementatie van de toString functie "overschreven" wordt

als je in dat geval de tostring zal aanroepen zal ie niet de code uitvoeren die de programmeertaal zelf voorschrijft, maar in de plaats de code die je zelf geschreven hebt

Maar weer fout zeg. @Override zorgt er enkel voor dat je compiler checkt of je effectief een method aan het overriden bent. Je kan het ook gewoon weglaten (methods overriden kon uiteraard al vóór Java 5 annotations introduceerde) en dat zal prima werken, als het signatuur van de methods exact overeenkomt. Computers zijn er om de mens te dienen, laat de compiler dus maar die check uitvoeren.

Maar we wijken af.

MilM · 1 mrt 2009

De vraag is hoe ver je moet gaan met annotations en documentatie

Gurdt · 1 mrt 2009

een beetje commentaar kan al heel veel doen voor uzelf en andere programmeurs

Bubbling Zombie · 1 mrt 2009

Gurdt zei:
een beetje commentaar kan al heel veel doen voor uzelf en andere programmeurs

Als uw code zodanig onduidelijk is dat er commentaar voor nodig is kunde misschien uw code het beste voor uw eigen houden.

forloRn_ · 1 mrt 2009

Het ging over annotations en niet over commentaar. Annotations zijn er nog altijd om door de compiler en andere programma's geïnterpreteerd te worden; een programmeur heeft daar op zich hoegenaamd geen hol aan.

MilM · 1 mrt 2009

forloRn_ zei:
Het ging over annotations en niet over commentaar. Annotations zijn er nog altijd om door de compiler en andere programma's geïnterpreteerd te worden; een programmeur heeft daar op zich hoegenaamd geen hol aan.

Bwa, het gaat eerder of het werk dat je erin steekt de moeite is.
@override dient dan wel om door de compiler geïnterpreteerd te worden, het is nog altijd ter bescherming van de programmeur tegen bijv. een typfout.

Men zegt ook altijd goed documenteren en dan zie je vaak klasses waarbij elke methode gedocumenteerd is, maar de naam van de methode en argumenten al zoveel zeggen, dat de documentatie op zich weinig toegevoegde waarde heeft.

Maar het is maar muggenziften hoor.
Het is niet dat @override erbij zetten zoveel werk in beslag neemt en dan weet je als lezer ook dan het een methode is die overschreven wordt

JelleSampleThis · 1 mrt 2009

je hebt niet altijd de source als je aan het coden bent, dan kan je snel de javadoc gaan checken. Kom zeg, hoe kan je zeggen dat commentaar overbodig is. Niet omdat je duidelijk en klare code schrijft dat het niet makkelijk is om een regel comment toe te voegen. Waarom hier een for lus over een collectie, waarom dit item gaan persisteren, waarom een flush gaan doen voor je transactie ten einde is gelopen.

Ik vind de Override annotatie zeer handig want wanneer je dan een superklasse of interface aanpast zullen je subklasses fouten aangeven, wat zeer handig is en raar gedrag kan voorkomen.
Sinds SE 6 mag override ook gebruikt worden bij methodes overschreven van een interface, override klopt niet echt omdat het eigenlijk implements zou moeten zijn, maar het helpt veel als je iets anapast zonder te refactoren.

MilM · 1 mrt 2009

JelleSampleThis zei:
je hebt niet altijd de source als je aan het coden bent, dan kan je snel de javadoc gaan checken. Kom zeg, hoe kan je zeggen dat commentaar overbodig is. Niet omdat je duidelijk en klare code schrijft dat het niet makkelijk is om een regel comment toe te voegen. Waarom hier een for lus over een collectie, waarom dit item gaan persisteren, waarom een flush gaan doen voor je transactie ten einde is gelopen.

Wie zegt er dat commentaar overbodig is :wtf:

Het gaat erom hoe ver je daarin gaat en hoeveel ze bijdraagt.
Natuurlijk kan commentaar soms handig zijn.

Ik vind de Override annotatie zeer handig want wanneer je dan een superklasse of interface aanpast zullen je subklasses fouten aangeven, wat zeer handig is en raar gedrag kan voorkomen.
Sinds SE 6 mag override ook gebruikt worden bij methodes overschreven van een interface, override klopt niet echt omdat het eigenlijk implements zou moeten zijn, maar het helpt veel als je iets anapast zonder te refactoren.

True, maar bij toString is dat geen argument meer omdat dit geen methode is van uw eigen superklasse en toString dus niet kunt aanpassen in die superklasse.

JelleSampleThis · 1 mrt 2009

MilM zei:
Wie zegt er dat commentaar overbodig is
Het gaat erom hoe ver je daarin gaat en hoeveel ze bijdraagt.
Natuurlijk kan commentaar soms handig zijn.

True, maar bij toString is dat geen argument meer omdat dit geen methode is van uw eigen superklasse en toString dus niet kunt aanpassen in die superklasse.

Je hebt hier gelijk, maar ik doe dit omdat ik graag consistent ben.

Bubbling Zombie · 1 mrt 2009

JelleSampleThis zei:
je hebt niet altijd de source als je aan het coden bent, dan kan je snel de javadoc gaan checken. Kom zeg, hoe kan je zeggen dat commentaar overbodig is. Niet omdat je duidelijk en klare code schrijft dat het niet makkelijk is om een regel comment toe te voegen. Waarom hier een for lus over een collectie, waarom dit item gaan persisteren, waarom een flush gaan doen voor je transactie ten einde is gelopen

Yeah, wacht tot ge kunstwerken zoals het volgende tegenkomt

///<summary>
/// Adds persons to the library
///</summary>
///<param name="person">person</param>
public void AddPerson(Person person)
(blabla)

En op't moment da'k tijd heb om documentatie te schrijven zal ik da ook doen, maar 't zal dan ook wel deftig zijn. Nie't gene wat ge tegenwoordig ziet. En de commentaar die ik zie is in 99% van de gevallen overbodig.

Gurdt · 1 mrt 2009

Bubbling Zombie zei:
Als uw code zodanig onduidelijk is dat er commentaar voor nodig is kunde misschien uw code het beste voor uw eigen houden.

HAHA kerel
ik studeer informatica @ unief
als wij geen commentaar schrijven buizen ze ons, en geloof me, ik denk dat bij ons de code wel duidelijk genoeg is
commentaar is gewoon een must, zeker als ge in team werkt of delen van projecten moet verzorgen

commentaar is net zo belangrijk als een goede gestructureerde header-file (waarin dan liefst nog eens genoeg commentaar staat)

eigenlijk zou ge bij iedere functie een blokje uitleg moeten geven
dat is ook precies wat ge moet doen als ge een documentatie of een verslag schrijft

maar ik denk dat ik met iemand praat die informatica niet op dat niveau tegenkomt, dus soit

Gurdt · 1 mrt 2009

Bubbling Zombie zei:
Yeah, wacht tot ge kunstwerken zoals het volgende tegenkomt

///<summary>
/// Adds persons to the library
///</summary>
///<param name="person">person</param>
public void AddPerson(Person person)
(blabla)

En op't moment da'k tijd heb om documentatie te schrijven zal ik da ook doen, maar 't zal dan ook wel deftig zijn. Nie't gene wat ge tegenwoordig ziet. En de commentaar die ik zie is in 99% van de gevallen overbodig.

overbodige commentaar is even slecht als slordige code
dus niet goed
commentaar dient ter verduidelijking, en al wie zegt dat da nie nodig is, moet stoppen met programmeren

Bubbling Zombie · 1 mrt 2009

Gurdt zei:
maar ik denk dat ik met iemand praat die informatica niet op dat niveau tegenkomt, dus soit

ik verdien er mijn geld mee, beheer/werk mee aan vier projecten (op't moment) die op Europees niveau gebruikt worden. Misschien moet gij gewoon bij R&D blijven. Tenzij dat dat natuurlijk onder uw niveau is.

Gurdt · 1 mrt 2009

Bubbling Zombie zei:
ik verdien er mijn geld mee, beheer/werk mee aan vier projecten (op't moment) die op Europees niveau gebruikt worden. Misschien moet gij gewoon bij R&D blijven. Tenzij dat dat natuurlijk onder uw niveau is.

iedereen die informatica op eender welk niveau heeft gedaan verdient er z'n geld mee, zo iemand die geen aars van code kan schrijven maar wel dé database admin van kbc is
die moet ook enorm veel code schrijven, maar die z'n code is rotslecht

wij leren coderen op het hoogste niveau, namelijk imperatief
dan leert ge ALLE aspecten van het werken in team en conventies waar ge u aan moet houden
en als gij beweert dat de conventies die wij aangeleerd krijgen op de unief verkeerd zijn, denk ik dat er iets met úw programmeermethode scheelt

ik denk dat ik trouwens in naam spreek van alle andere programmeurs, dat er niets ergerlijkers is dan een teammember die geen commentaar neerpoot tussen z'n code

Bubbling Zombie · 1 mrt 2009

Gurdt zei:
iedereen die informatica op eender welk niveau heeft gedaan verdient er z'n geld mee, zo iemand die geen aars van code kan schrijven maar wel dé database admin van kbc is
die moet ook enorm veel code schrijven, maar die z'n code is rotslecht

Gij maakt hier eigenlijk wel veel veronderstellingen é.

wij leren coderen op het hoogste niveau, namelijk imperatief
dan leert ge ALLE aspecten van het werken in team en conventies waar ge u aan moet houden
en als gij beweert dat de conventies die wij aangeleerd krijgen op de unief verkeerd zijn, denk ik dat er iets met úw programmeermethode scheelt

Leert ge de volgende conventies ook:
- dat ge soms met mensen zit die al langer in't vak zitten dan dat gij oud zijt
- dat die mensen OO als iets cutting edge bezien
- dat ge soms met deadlines zit in de stijl van "omg, gisteren moest dat afzijn keke, finish it, we hebben nog wel geen analyse of geen document maar kom, begint er maar aan"
- dat ze u betalen om een product af te leveren, niet om uw principes toe te passen

Hell, laat mij (ons) uw conventies eens horen.

ik denk dat ik trouwens in naam spreek van alle andere programmeurs, dat er niets ergerlijkers is dan een teammember die geen commentaar neerpoot tussen z'n code

Ik denk trouwens dat ik uit naam van al mijn teamleden spreek dat een arrogant eikeltje dat juist van't school af is en denkt alles beter te weten een pak lastiger is dan iemand die het waagt de public methods niet te becommentariëren.

MilM · 1 mrt 2009

Discussies worden altijd veel te zwart/wit gevoerd.

Het is niet een discussie van wel of geen documentatie etc, maar hoe ver je daarin gaat.
Je moet dat zelf ook beetje aanvoelen.

Je mag ook het commerciële aspect niet vergeten waarbij je tegen deadlines werkt.

Idem voor het designen van een programma. Soms kan het de moeite lonen om dit zwaar te documenteren, soms moet je tevreden zijn met minder.

Aan de Ugent viel dat trouwens zeer goed mee die nadruk op het documenteren van code.

Gurdt · 1 mrt 2009

Bubbling Zombie zei:
Gij maakt hier eigenlijk wel veel veronderstellingen é.

tgaat over m'n pa

Bubbling Zombie zei:
Leert ge de volgende conventies ook:
- dat ge soms met mensen zit die al langer in't vak zitten dan dat gij oud zijt
- dat die mensen OO als iets cutting edge bezien
- dat ge soms met deadlines zit in de stijl van "omg, gisteren moest dat afzijn keke, finish it, we hebben nog wel geen analyse of geen document maar kom, begint er maar aan"
- dat ze u betalen om een product af te leveren, niet om uw principes toe te passen

wij hebbe genoeg projecten en deadline's geloof me, der worden echt wel keuzes gemaakt tussen dingen, en commentaar wordt zeker nie geschrapt :')
die schrijft ge wanneer ge de code zelf schrijft erbij, ook voor uzelf zijn zo dingen handig

gij vertelt nu dat als ze u geld geven om iets te maken, dat gij dingen verwaarloosd die ze toch nie zien in het eindproduct? dat is net waarom ze het u aanleren, natuurlijk gaan de gebruikers nooit uw code zien, het is net voor u en voor uw teamleden dat ge conventies toepast duh, naar zulke dingen werken versnelt heel het proces en bevordert gwn de kwaliteit van de code, kvind da raar da ge da nie weet, da IS net het nut van conventies

Bubbling Zombie zei:
Hell, laat mij (ons) uw conventies eens horen.

die conventies gaan over vanalles,
leesbaarheid moet heel hoog zijn (bepaalde dingen gescheiden houden dmv spaties, enters, andere files etc)
zo mogen onze functies nie langer zijn dan een bepaald aantal regels om zo de code te verbeteren en duidelijker te maken

hierbij komen dan nog een heleboel afspraken die ge onder elkaar best afspreekt maar die normaal gezien bedrijfsgebonden zijn (wie nu bij een degelijk bedrijf begint krijgt eerst een opleiding 'conventies' waarin afpsraken gemaakt worden over documentatie, da kost een bedrijf heel veel geld die opleidingen, maar uiteindelijk rendeert da enorm, wederom: het nut van documenteren)

en natuurlijk niet te vergeten: indische code is not done (ik denk dat ik niet moet uitleggen wat dat is, maar die code kom ik HEEL vaak tegen op fora's en enorm veel websites, dat is dan bijvoorbeeld: while( !false == XXX ))

Bubbling Zombie zei:
Ik denk trouwens dat ik uit naam van al mijn teamleden spreek dat een arrogant eikeltje dat juist van't school af is en denkt alles beter te weten een pak lastiger is dan iemand die het waagt de public methods niet te becommentariëren.

ik denk niet dat ik moet opkijken naar iemand die al langer codeert maar er evenveel van kent als gij u laat tonen

Bubbling Zombie · 1 mrt 2009

Gurdt zei:
tgaat over m'n pa

yeah, zo'n mensen komen wij ook constant tegen. Mag nu zo'n ex-vba programmeur z'n code onderhouden. Dikke feest.

wij hebbe genoeg projecten en deadline's geloof me, der worden echt wel keuzes gemaakt tussen dingen, en commentaar wordt zeker nie geschrapt :')
die schrijft ge wanneer ge de code zelf schrijft erbij, ook voor uzelf zijn zo dingen handig

Wacht tot ze die keuzes voor u beginnen te maken.

gij vertelt nu dat als ze u geld geven om iets te maken, dat gij dingen verwaarloosd die ze toch nie zien in het eindproduct? dat is net waarom ze het u aanleren, natuurlijk gaan de gebruikers nooit uw code zien, het is net voor u en voor uw teamleden dat ge conventies toepast duh, naar zulke dingen werken versnelt heel het proces en bevordert gwn de kwaliteit van de code, kvind da raar da ge da nie weet, da IS net het nut van conventies

Wij hebben conventies aangaande de manier van programmeren: de methodenaam moet zeggen wat de methode doet, SOLID principes toepassen, bepaalde architecturale en dus ook bepaalde dingen die voor heel het bedrijf gelden etc.

hierbij komen dan nog een heleboel afspraken die ge onder elkaar best afspreekt maar die normaal gezien bedrijfsgebonden zijn (wie nu bij een degelijk bedrijf begint krijgt eerst een opleiding 'conventies' waarin afpsraken gemaakt worden over documentatie, da kost een bedrijf heel veel geld die opleidingen, maar uiteindelijk rendeert da enorm, wederom: het nut van documenteren)

Hebben wij ook gekregen, nu gaat ge der wel vanuit dat iedereen die toepast en die opleiding gekregen heeft.

en natuurlijk niet te vergeten: indische code is not done (ik denk dat ik niet moet uitleggen wat dat is, maar die code kom ik HEEL vaak tegen op fora's en enorm veel websites, dat is dan bijvoorbeeld: while( !false == XXX ))

Damn straight. Indiers moet ge goed africhten.

ik denk niet dat ik moet opkijken naar iemand die al langer codeert maar er evenveel van kent als gij u laat tonen

We zullen er nog eens over spreken als ge afgestudeert zijt en een jaartje werkt. Let wel, ik heb het hier niet over werken bij een IT bedrijf maar wel over ine en bedrijf waar IT een ondersteunde functie heeft. Mag ik zo onbeschoft zijn om te vragen hoe lang ge nog te doen hebt en wat uw "droomjob" is?

Tyfius · 1 mrt 2009

Ik wil mij niet al te veel moeien maar toch even wat duidelijkheid scheppen:

de deadlines waar je op school mee te maken krijgt zijn peanuts, de klant belt vandaag, en gisteren moet die feature er in, dan is er dikwijls geen tijd voor een deftige analyse en veel commentaar. Zeker als de klant om 17u nog eens belt om 3/4de van wat tegen 18u af moet zijn te veranderen. En dan gaat het niet om iets simpel als een volledig agenda systeem aan uw boekhoud applicatie toevoegen.
commentaar moet ook nuttig zijn in het bedrijfsleven, als ik een functie checkSatelliteType(uint8_t *message) schrijf moet ik daar niet in commentaar gaan bijvertellen dat die functie controleert of de data in de message parameter GPS, GLONASS, SBAS of GALILEO data bevat, dat kan er uit afgeleid worden. Als ik binnen mijn functie ook nog eens een "if (type == GLONASS) { SVID -= 37; }" doe moet ik daar ook niet speciaal documentatie gaan bij zetten. Als ik daar echter uit die message de eerste 12 bits ga inverten omdat de data die afkomstig is van een bepaald type GPS ontvanger little endian is kan ik daar best wel in 1 zin iets bij vertellen omdat dit niet kan afgeleid worden uit de code. Maar dat moet allemaal geen epistel worden, daar hameren ze op school wel op maar daar heeft de doorsnee programmeur geen boodschap aan, die zit dat ook wel.

Misschien een boek dat eens te bekijken valt is Amazon.com: Code Craft: The Practice of Writing Excellent Code: Pete Goodliffe: Books

Cycloon · 1 mrt 2009

Documenteren om te documenteren werkt eerder contraproductief omdat andere programmeurs je documentatie dan veel te vlug diagonaal gaan lezen, omdat er teveel zaken instaan die niet nuttig zijn, waardoor de cruciale zaken overlezen worden en je documentatie dus totaal geen zin heeft gehad.

Ik ken ook zo mensen die elk regeltje code zouden documenteren, als je die code dan mag gaan lezen ben je ook wel even zoet.

Archief - [JAVA]

forloRn_

Legacy Member

MilM

Legacy Member

Gurdt

Legacy Member

Bubbling Zombie

Legacy Member

forloRn_

Legacy Member

MilM

Legacy Member

JelleSampleThis

Legacy Member

MilM

Legacy Member

JelleSampleThis

Legacy Member

Bubbling Zombie

Legacy Member

Gurdt

Legacy Member

Gurdt

Legacy Member

Bubbling Zombie

Legacy Member

Gurdt

Legacy Member

Bubbling Zombie

Legacy Member

MilM

Legacy Member

Gurdt

Legacy Member

Bubbling Zombie

Legacy Member

Tyfius

Legacy Member

Cycloon

Legacy Member