<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Reacties op: Mooie code!</title>
	<atom:link href="http://www.software-innovators.nl/2008/08/13/mooie-code/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.software-innovators.nl/2008/08/13/mooie-code/</link>
	<description>Sogyo over het realiseren van software innovaties</description>
	<lastBuildDate>Thu, 02 Feb 2012 15:39:47 +0100</lastBuildDate>
	<generator>http://wordpress.org/</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>Door: Mooie code! &#124; Edwin van Dillen</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-1129</link>
		<dc:creator>Mooie code! &#124; Edwin van Dillen</dc:creator>
		<pubDate>Tue, 30 Sep 2008 10:06:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-1129</guid>
		<description>[...] Lees de rest hier: http://www.software-innovators.nl/2008/08/13/mooie-code/         Doorzoek de site [...]</description>
		<content:encoded><![CDATA[<p>[...] Lees de rest hier: <a href="http://www.software-innovators.nl/2008/08/13/mooie-code/" rel="nofollow">http://www.software-innovators.nl/2008/08/13/mooie-code/</a>         Doorzoek de site [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Sebastiaan</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-711</link>
		<dc:creator>Sebastiaan</dc:creator>
		<pubDate>Sun, 31 Aug 2008 11:01:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-711</guid>
		<description>Mooie code heeft niks met nerdigheid te maken. Leesbaarheid van code heeft veel te maken met de mate waarin de schrijver van die code zich kan uitdrukken. Iemand die zich goed kan uitdrukken wordt doorgaans niet bestempeld als nerd. Een goede structuur maakt de code herbruikbaar en overzichtelijk. Om een component herbruikbaar te maken is veel inzicht nodig in visie, missie en doelstellingen van het bedrijf; dit is ook de reden dat de service georienteerde architectuur in een korte tijd zo mateloos populair is geworden. Nerds houden zich veelal niet bezig met de bedrijfsdoelstellingen, wat overigens een groot probleem is in ICT in het algemeen (de business/IT gap). In defence of the nerds: managers houden zich ook te weinig bezig met problemen in de ICT.

Dus: iemand die mooie code kan schrijven zou het eigenlijk ook goed moeten kunnen verkopen aan zijn baas. ;-)</description>
		<content:encoded><![CDATA[<p>Mooie code heeft niks met nerdigheid te maken. Leesbaarheid van code heeft veel te maken met de mate waarin de schrijver van die code zich kan uitdrukken. Iemand die zich goed kan uitdrukken wordt doorgaans niet bestempeld als nerd. Een goede structuur maakt de code herbruikbaar en overzichtelijk. Om een component herbruikbaar te maken is veel inzicht nodig in visie, missie en doelstellingen van het bedrijf; dit is ook de reden dat de service georienteerde architectuur in een korte tijd zo mateloos populair is geworden. Nerds houden zich veelal niet bezig met de bedrijfsdoelstellingen, wat overigens een groot probleem is in ICT in het algemeen (de business/IT gap). In defence of the nerds: managers houden zich ook te weinig bezig met problemen in de ICT.</p>
<p>Dus: iemand die mooie code kan schrijven zou het eigenlijk ook goed moeten kunnen verkopen aan zijn baas. ;-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Ype</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-624</link>
		<dc:creator>Ype</dc:creator>
		<pubDate>Mon, 18 Aug 2008 10:45:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-624</guid>
		<description>Ik heb het vaak over elegante code. Nu heb ik niet ervaring met heel veel programmeertalen, maar het begrip elegante code is wel ontstaan bij het werken in Smalltalk (wat ik helaas voor mijn werk niet meer doe). Vergeleken daarmee heb ik het idee dat je in Java niet echt mooie/elegante code kan schrijven. Taalfeatures als block closures en symbols in Smalltalk helpen naar mijn mening erg bij het schrijven van elegante code. Daarbij helpt refactoring bij mij heel erg om tot elegante code te komen.
Het maken van elegante code geeft een goed gevoel, maar meestal merk ik aan het goede gevoel, dat ik (denk ik) elegante code aan het schrijven ben. 
Dat gevoel heb ik met Java helaas niet meer zo vaak... (of ben ik nu werk een zeurpiet)</description>
		<content:encoded><![CDATA[<p>Ik heb het vaak over elegante code. Nu heb ik niet ervaring met heel veel programmeertalen, maar het begrip elegante code is wel ontstaan bij het werken in Smalltalk (wat ik helaas voor mijn werk niet meer doe). Vergeleken daarmee heb ik het idee dat je in Java niet echt mooie/elegante code kan schrijven. Taalfeatures als block closures en symbols in Smalltalk helpen naar mijn mening erg bij het schrijven van elegante code. Daarbij helpt refactoring bij mij heel erg om tot elegante code te komen.<br />
Het maken van elegante code geeft een goed gevoel, maar meestal merk ik aan het goede gevoel, dat ik (denk ik) elegante code aan het schrijven ben.<br />
Dat gevoel heb ik met Java helaas niet meer zo vaak&#8230; (of ben ik nu werk een zeurpiet)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Edwin van Dillen</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-617</link>
		<dc:creator>Edwin van Dillen</dc:creator>
		<pubDate>Sun, 17 Aug 2008 20:25:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-617</guid>
		<description>Zeker interessant vraagstuk. Bij code wordt al gauw gedacht aan de resultaten van de programmeertaal waarmee we werken. Even achterwegen gelaten dat UML ook als programmeertaal beschouwd kan worden, heb ik het toch al snel over een derde generatie programmeertaal als Java/C#/Ruby. Dat kan een valkuil zijn. 
Zelf heb ik in het verleden meerdere applicaties mogen ontwikkelen in een modelleeromgeving (case-tool): Cool:gen. Daar heb ik aan de lijven mogen ondervinden dat het zeker belangrijk is wat voor code gegenereerd wordt. Natuurlijk is het zo dat je de gegenereerde code niet meer aan hoort te raken. Maar helaas liet de praktijk toen toch zien dat de gegenereerde code niet altijd optimaal was. Onder de motorkap af en toe fine-tunen was (nog) nodig. Dan wil je wel dat de code wel mooi is (wat het zeker niet altijd was ). 
Hierbij geldt wel dat je invloed kunt uitoefenen op de code die gegenereerd wordt. Op zichzelf simpele dingen als bijvoorbeeld consistentie in naamgeving is toch iets dat je zelf in hand hebt, of je nu aan het modelleren bent in een hogere taal of het rechtstreeks schrijft in een derde generatie taal. Het achterliggende metamodel en het begrip daarvan bij de ontwikkelaars/modelleurs hebben een grote invloed op de gegenereerde code. Zo zag  je in Cool:gen dat het bij complexere queries moeilijker was te voorspellen hoe deze gegenereerd zouden worden. Daarmee weet je dus niet wat, in dit geval, voor SQL gegenereerd wordt. Zelf ben ik daarom wel fan geworden van de modelleeromgevingen waarin gewerkt wordt met generatie templates die open zijn. Daarmee kun je tenminste nog invloed uitoefen op het eind resultaat. 
Ik heb nog niet nagedacht over de eisen die je zou moeten stellen op een lagere abstractie. Het zou natuurlijk mooi zijn als je mooie assembly code overhoud. Zeker interessant in situaties waar met reversengineering gewerkt moet worden.</description>
		<content:encoded><![CDATA[<p>Zeker interessant vraagstuk. Bij code wordt al gauw gedacht aan de resultaten van de programmeertaal waarmee we werken. Even achterwegen gelaten dat UML ook als programmeertaal beschouwd kan worden, heb ik het toch al snel over een derde generatie programmeertaal als Java/C#/Ruby. Dat kan een valkuil zijn.<br />
Zelf heb ik in het verleden meerdere applicaties mogen ontwikkelen in een modelleeromgeving (case-tool): Cool:gen. Daar heb ik aan de lijven mogen ondervinden dat het zeker belangrijk is wat voor code gegenereerd wordt. Natuurlijk is het zo dat je de gegenereerde code niet meer aan hoort te raken. Maar helaas liet de praktijk toen toch zien dat de gegenereerde code niet altijd optimaal was. Onder de motorkap af en toe fine-tunen was (nog) nodig. Dan wil je wel dat de code wel mooi is (wat het zeker niet altijd was ).<br />
Hierbij geldt wel dat je invloed kunt uitoefenen op de code die gegenereerd wordt. Op zichzelf simpele dingen als bijvoorbeeld consistentie in naamgeving is toch iets dat je zelf in hand hebt, of je nu aan het modelleren bent in een hogere taal of het rechtstreeks schrijft in een derde generatie taal. Het achterliggende metamodel en het begrip daarvan bij de ontwikkelaars/modelleurs hebben een grote invloed op de gegenereerde code. Zo zag  je in Cool:gen dat het bij complexere queries moeilijker was te voorspellen hoe deze gegenereerd zouden worden. Daarmee weet je dus niet wat, in dit geval, voor SQL gegenereerd wordt. Zelf ben ik daarom wel fan geworden van de modelleeromgevingen waarin gewerkt wordt met generatie templates die open zijn. Daarmee kun je tenminste nog invloed uitoefen op het eind resultaat.<br />
Ik heb nog niet nagedacht over de eisen die je zou moeten stellen op een lagere abstractie. Het zou natuurlijk mooi zijn als je mooie assembly code overhoud. Zeker interessant in situaties waar met reversengineering gewerkt moet worden.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Andre Boonzaaijer</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-613</link>
		<dc:creator>Andre Boonzaaijer</dc:creator>
		<pubDate>Sun, 17 Aug 2008 11:53:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-613</guid>
		<description>Voedsel voor discussie dan maar:
- Kan assembly code ook &#039;mooi&#039; zijn? In feite is assembly een tweede abstractie van executeerbare code (2 GL taal). Ik denk dat de meesten zullen instemmen dat er wel degelijk &#039;mooie assemblycode&#039; te maken is.

Echter één brug verder: Kan machine code ook mooi zijn? Bijvoorbeeld:
10110101 doet hetzelfde als 111000. (geen idee of dit zo is, maar we gaan er maar even vanuit). Denk eraan dat dit net zo goed code is, als in een bepaalde abstractie/instructies die nog worden vertaald naar stroompjes richting flip-flops e.d. in processoren.

Waar ik naartoe wil? Kunnen we eigenlijk wel spreken van &#039;mooie code&#039; of meer van &#039;mooie modellen&#039; of &#039;mooie abstracties&#039;. Is gegenereerde Java of C# code eigenlijk wel te kwalificeren als mooi of niet mooi, moeten we niet meer naar de bovenliggende handgemaakte modellen kijken?</description>
		<content:encoded><![CDATA[<p>Voedsel voor discussie dan maar:<br />
- Kan assembly code ook &#8216;mooi&#8217; zijn? In feite is assembly een tweede abstractie van executeerbare code (2 GL taal). Ik denk dat de meesten zullen instemmen dat er wel degelijk &#8216;mooie assemblycode&#8217; te maken is.</p>
<p>Echter één brug verder: Kan machine code ook mooi zijn? Bijvoorbeeld:<br />
10110101 doet hetzelfde als 111000. (geen idee of dit zo is, maar we gaan er maar even vanuit). Denk eraan dat dit net zo goed code is, als in een bepaalde abstractie/instructies die nog worden vertaald naar stroompjes richting flip-flops e.d. in processoren.</p>
<p>Waar ik naartoe wil? Kunnen we eigenlijk wel spreken van &#8216;mooie code&#8217; of meer van &#8216;mooie modellen&#8217; of &#8216;mooie abstracties&#8217;. Is gegenereerde Java of C# code eigenlijk wel te kwalificeren als mooi of niet mooi, moeten we niet meer naar de bovenliggende handgemaakte modellen kijken?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Rick van der Arend</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-595</link>
		<dc:creator>Rick van der Arend</dc:creator>
		<pubDate>Thu, 14 Aug 2008 18:45:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-595</guid>
		<description>De laatste zin moet denk ik als volgt worden:

En zorg er ook voor dat je die onderliggende waarden op de pijnbank blijft leggen.</description>
		<content:encoded><![CDATA[<p>De laatste zin moet denk ik als volgt worden:</p>
<p>En zorg er ook voor dat je die onderliggende waarden op de pijnbank blijft leggen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Rick van der Arend</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-594</link>
		<dc:creator>Rick van der Arend</dc:creator>
		<pubDate>Thu, 14 Aug 2008 18:34:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-594</guid>
		<description>Een mooie post, Edwin. Ik heb er nog een toevoeging op, die het wel enigszins nuanceert. 

Ik denk dat spreken over &#039;mooie&#039; en/of &#039;stinkende&#039; code een mooie metafoor is, maar ook een gevaar in zich heeft. Iedereen kan iets mooi vinden en iemand anders kan iets anders heel mooi vinden. In de praktijk blijkt ook dat de smaak van persoon tot persoon verschilt (toegegeven, ook weer niet zo heel veel: zie IKEA). 

Echter, het &#039;mooi&#039; waar jij op doelt heeft vaak ook de onderliggende aanname dat experts in hetzelfde domein dezelfde dingen mooi zullen vinden (gegeven dezelfde randvoorwaarden). Het lijkt dan eigenlijk weer meer op het rechtvaardigheidsgevoel. Maar natuurlijk zitten daarin ook verschillen van mens tot mens. 

Waar komen deze verschillen vandaan? Mijns inziens komen ze van verschillende waarden. Als je &#039;genericiteit&#039; veel belangrijker vind dan &#039;zo eenvoudig mogelijk&#039;, dan vind je andere software mooi. En als beginnend programmeur zijn je waarden waarschijnlijk nog niet zo getraind en helder en heb je dus nog geen gevoel voor wat mooi én productief is. Je kunt die waarden trainen door in projecten te werken met een goede feedback van de resultaten (b.v. in een klein team of goede evaluaties). Je krijgt ze volgens mij helder door er met andere programmeurs over te discussiëren of erover te schrijven en te lezen. Door ze te moeten verwoorden, maak je je standpunt voor je jezelf vaak ook veel helderder..

Kortom: helemaal met je eens: gebruik je gevoel bij programmeren en spreek gerust over mooie code. Maar zorg er dan wel voor dat je die onderliggende waarden op de pijnbank blijft leggen.</description>
		<content:encoded><![CDATA[<p>Een mooie post, Edwin. Ik heb er nog een toevoeging op, die het wel enigszins nuanceert. </p>
<p>Ik denk dat spreken over &#8216;mooie&#8217; en/of &#8217;stinkende&#8217; code een mooie metafoor is, maar ook een gevaar in zich heeft. Iedereen kan iets mooi vinden en iemand anders kan iets anders heel mooi vinden. In de praktijk blijkt ook dat de smaak van persoon tot persoon verschilt (toegegeven, ook weer niet zo heel veel: zie IKEA). </p>
<p>Echter, het &#8216;mooi&#8217; waar jij op doelt heeft vaak ook de onderliggende aanname dat experts in hetzelfde domein dezelfde dingen mooi zullen vinden (gegeven dezelfde randvoorwaarden). Het lijkt dan eigenlijk weer meer op het rechtvaardigheidsgevoel. Maar natuurlijk zitten daarin ook verschillen van mens tot mens. </p>
<p>Waar komen deze verschillen vandaan? Mijns inziens komen ze van verschillende waarden. Als je &#8216;genericiteit&#8217; veel belangrijker vind dan &#8216;zo eenvoudig mogelijk&#8217;, dan vind je andere software mooi. En als beginnend programmeur zijn je waarden waarschijnlijk nog niet zo getraind en helder en heb je dus nog geen gevoel voor wat mooi én productief is. Je kunt die waarden trainen door in projecten te werken met een goede feedback van de resultaten (b.v. in een klein team of goede evaluaties). Je krijgt ze volgens mij helder door er met andere programmeurs over te discussiëren of erover te schrijven en te lezen. Door ze te moeten verwoorden, maak je je standpunt voor je jezelf vaak ook veel helderder..</p>
<p>Kortom: helemaal met je eens: gebruik je gevoel bij programmeren en spreek gerust over mooie code. Maar zorg er dan wel voor dat je die onderliggende waarden op de pijnbank blijft leggen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Johan Scholten</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-590</link>
		<dc:creator>Johan Scholten</dc:creator>
		<pubDate>Wed, 13 Aug 2008 09:53:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-590</guid>
		<description>Mooie code kan zijn: Begrijpbaar, simpel, logisch, kort, inventief... 

En dan is de code onderhoudbaar/wijzigbaar/uitbreidbaar (bij inventief en kort hoeft dat niet te gelden geloof ik), wat weer gunstig is.

Volgens mij ga je beschrijvende woorden gebruiken om een bepaald gevoel bij mensen op te wekken, een associatie met iets dat deels dezelfde eigenschappen heeft, ook al is dat niet helemaal objectief.
Voor mij bijvoorbeeld:
mooi: goed, waardering, persoonlijke mening;
stinkt: slecht, idee dat iets z&#039;n tijd gehad heeft of slecht samengesteld is, iets dat gemeden moet worden.

Zulke woorden moet je zeker gebruiken zolang mensen snappen wat je bedoelt.. Maar tegen iemand die niet zo thuis is in het onderwerp (in dit geval klant) is het misschien beter het gevoel iets te vertalen of uit te leggen.</description>
		<content:encoded><![CDATA[<p>Mooie code kan zijn: Begrijpbaar, simpel, logisch, kort, inventief&#8230; </p>
<p>En dan is de code onderhoudbaar/wijzigbaar/uitbreidbaar (bij inventief en kort hoeft dat niet te gelden geloof ik), wat weer gunstig is.</p>
<p>Volgens mij ga je beschrijvende woorden gebruiken om een bepaald gevoel bij mensen op te wekken, een associatie met iets dat deels dezelfde eigenschappen heeft, ook al is dat niet helemaal objectief.<br />
Voor mij bijvoorbeeld:<br />
mooi: goed, waardering, persoonlijke mening;<br />
stinkt: slecht, idee dat iets z&#8217;n tijd gehad heeft of slecht samengesteld is, iets dat gemeden moet worden.</p>
<p>Zulke woorden moet je zeker gebruiken zolang mensen snappen wat je bedoelt.. Maar tegen iemand die niet zo thuis is in het onderwerp (in dit geval klant) is het misschien beter het gevoel iets te vertalen of uit te leggen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Rob Vens</title>
		<link>http://www.software-innovators.nl/2008/08/13/mooie-code/comment-page-1/#comment-589</link>
		<dc:creator>Rob Vens</dc:creator>
		<pubDate>Wed, 13 Aug 2008 08:59:57 +0000</pubDate>
		<guid isPermaLink="false">http://www.software-innovators.nl/?p=245#comment-589</guid>
		<description>Een sterk onderschat zintuig, ons esthetische zintuig. Officieel is het zelfs geen zintuig, maar het is voor mij het zesde zintuig. Leer er op te vertrouwen. Een uitspraak van Kent Beck is beroemd geworden: &quot;code smells&quot;, wat een ander aspect is van schoonheid. Proeven, ruiken, voelen: alle zintuigen leveren naarmate je meer ervaren wordt steeds meer een &quot;gevoel&quot; op of iets klopt, of het goed is. Meesterschap staat gelijk aan feilloos &quot;aanvoelen&quot;.</description>
		<content:encoded><![CDATA[<p>Een sterk onderschat zintuig, ons esthetische zintuig. Officieel is het zelfs geen zintuig, maar het is voor mij het zesde zintuig. Leer er op te vertrouwen. Een uitspraak van Kent Beck is beroemd geworden: &#8220;code smells&#8221;, wat een ander aspect is van schoonheid. Proeven, ruiken, voelen: alle zintuigen leveren naarmate je meer ervaren wordt steeds meer een &#8220;gevoel&#8221; op of iets klopt, of het goed is. Meesterschap staat gelijk aan feilloos &#8220;aanvoelen&#8221;.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

