<?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>
	Kommentare zu: Programmierrichtlinien	</title>
	<atom:link href="https://itservice-herzog.de/blog/programmierrichtlinien/feed/" rel="self" type="application/rss+xml" />
	<link>https://itservice-herzog.de/blog/programmierrichtlinien/</link>
	<description>Softwareblog von Matthias Herzog</description>
	<lastBuildDate>Thu, 03 Aug 2017 00:05:37 +0000</lastBuildDate>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=5.2.3</generator>
			<item>
				<title>
				Von: ReMaker				</title>
				<link>https://itservice-herzog.de/blog/programmierrichtlinien/#comment-5</link>
		<dc:creator><![CDATA[ReMaker]]></dc:creator>
		<pubDate>Wed, 31 Jul 2013 19:04:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.matthias-herzog.net/?p=63#comment-5</guid>
					<description><![CDATA[Hi Michael,

es ist richtig das es CVS und SVN&#039;s oder git und unzählige andere Tools gibt. Das Problem warum man Änderungen in den Header schreiben sollte ist eigentlich das man nicht immer in die Logdatei, des jeweiligen Programms, sieht. Stell dir doch einfach vor die arbeitest mit 10 anderen Programmierern an einer Software und musst eine Stelle &quot;Provisorisch&quot; Bug-fixen, weil wieder mal sofort ein Update raus muss ;) .  Ich finde es immer eine gute Idee das der ursprüngliche Programmierer die Info im Quellcode bekommt das da genau an diesem Part ein anderer Programmierer gearbeitet hat. Vielleicht ist ja durch diesen Bugfix an anderer stelle was kaputt gegangen, durch fehlende Unit Test noch nicht entdeckt, oder der Bugfix ist absolut verbesserungswürdig. Das sind meine Intention warum ich für mich sage ich schreibe diese Information in den Header wenn ich größere Projekte angehe.

Gruß Matthias]]></description>
		<content:encoded><![CDATA[<p>Hi Michael,</p>
<p>es ist richtig das es CVS und SVN&#8217;s oder git und unzählige andere Tools gibt. Das Problem warum man Änderungen in den Header schreiben sollte ist eigentlich das man nicht immer in die Logdatei, des jeweiligen Programms, sieht. Stell dir doch einfach vor die arbeitest mit 10 anderen Programmierern an einer Software und musst eine Stelle &#8222;Provisorisch&#8220; Bug-fixen, weil wieder mal sofort ein Update raus muss 😉 .  Ich finde es immer eine gute Idee das der ursprüngliche Programmierer die Info im Quellcode bekommt das da genau an diesem Part ein anderer Programmierer gearbeitet hat. Vielleicht ist ja durch diesen Bugfix an anderer stelle was kaputt gegangen, durch fehlende Unit Test noch nicht entdeckt, oder der Bugfix ist absolut verbesserungswürdig. Das sind meine Intention warum ich für mich sage ich schreibe diese Information in den Header wenn ich größere Projekte angehe.</p>
<p>Gruß Matthias</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				Von: Michael				</title>
				<link>https://itservice-herzog.de/blog/programmierrichtlinien/#comment-4</link>
		<dc:creator><![CDATA[Michael]]></dc:creator>
		<pubDate>Mon, 29 Jul 2013 18:05:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.matthias-herzog.net/?p=63#comment-4</guid>
					<description><![CDATA[Hi,

Ich richte mich zu 90% nach PSR 1/2. Aber hier gibt es ja zog Meinungen. Einzige Kritik, die ich beim schnellen drüberscrollen habe: warum im Header erwähnen wer wann was geändert hat? Gibt es dafür nicht das VCS und für sich sprechende Committmessages? Außerdem sehr praktisch: annotate in PHPStorm, falls man einen  Verantwortlichen sucht :-D]]></description>
		<content:encoded><![CDATA[<p>Hi,</p>
<p>Ich richte mich zu 90% nach PSR 1/2. Aber hier gibt es ja zog Meinungen. Einzige Kritik, die ich beim schnellen drüberscrollen habe: warum im Header erwähnen wer wann was geändert hat? Gibt es dafür nicht das VCS und für sich sprechende Committmessages? Außerdem sehr praktisch: annotate in PHPStorm, falls man einen  Verantwortlichen sucht 😀</p>
]]></content:encoded>
						</item>
						<item>
				<title>
				Von: KingCrunch				</title>
				<link>https://itservice-herzog.de/blog/programmierrichtlinien/#comment-3</link>
		<dc:creator><![CDATA[KingCrunch]]></dc:creator>
		<pubDate>Mon, 29 Jul 2013 09:59:47 +0000</pubDate>
		<guid isPermaLink="false">http://blog.matthias-herzog.net/?p=63#comment-3</guid>
					<description><![CDATA[Mir würde sicher noch mehr auffallen, aber echte Kritik gibts eigentlich nicht :D

Eine Sache bloß, weil es einfach verbreitet genug ist: Für die Schleifen (Punkt 7) werden in der Regel nicht &quot;einfach nur&quot; irgendwelche Zählvariablen verwendet, sondern ursprünglich sind sie der Mathematik entliehen. Das heißt &quot;i&quot; (&quot;j&quot;, &quot;k&quot;) steht für &quot;Index&quot; und stehen für die Index-Nummer in einem Feld (array). &quot;n&quot; (&quot;m&quot;, &quot;l&quot;) steht für &quot;Nummer&quot; und steht das &quot;wievielte Element&quot; (meist &quot;Index+1&quot;). &quot;k&quot; (oder nochmal &quot;l&quot;) steht für &quot;key&quot; und bezeichnet den Key in einer Map/einem Dictionary (&quot;assoziatives Array&quot;).
Von der Semantik her sind sie unterschiedlich und das hilft den Zweck besser zu erfassen

- Mehr als 3 verschiedene sind nie notwendig, denn verschiedene werden nur gebraucht, wenn Schleifen geschachtelt werden. Wenn mehr als 3 Schleifen geschachtelt werden, sollte man refactoren ;)
- Passt keiner der Begriffe so richtig, oder bleibt es trotzdem etwas ungenau (zB wenn man verschiedene Indeces meinen könnte) sollte man trotzdem die Variable wieder ausschreiben


Was anderes zu Punkt 9: Offenbar liegen im selben Ordner, in dem auch Ordner mit Code-Dateien liegen die Ordner für CSS und JS. Da letztere von Aussen erreichbar sein müssen, müssen sie im Document-Root liegen, was dann aber auch für die Ordner mit den Code-Dateien gilt. Das ist immer etwas riskant ;) Besser ist es ein &quot;web&quot;, &quot;public&quot; oder &quot;html&quot; einzusetzen, der dann als Document Root fungiert und in der sich bis auf die Bootstrap-Datei keine weitere Datei mit Code befindet.]]></description>
		<content:encoded><![CDATA[<p>Mir würde sicher noch mehr auffallen, aber echte Kritik gibts eigentlich nicht 😀</p>
<p>Eine Sache bloß, weil es einfach verbreitet genug ist: Für die Schleifen (Punkt 7) werden in der Regel nicht &#8222;einfach nur&#8220; irgendwelche Zählvariablen verwendet, sondern ursprünglich sind sie der Mathematik entliehen. Das heißt &#8222;i&#8220; (&#8222;j&#8220;, &#8222;k&#8220;) steht für &#8222;Index&#8220; und stehen für die Index-Nummer in einem Feld (array). &#8222;n&#8220; (&#8222;m&#8220;, &#8222;l&#8220;) steht für &#8222;Nummer&#8220; und steht das &#8222;wievielte Element&#8220; (meist &#8222;Index+1&#8220;). &#8222;k&#8220; (oder nochmal &#8222;l&#8220;) steht für &#8222;key&#8220; und bezeichnet den Key in einer Map/einem Dictionary (&#8222;assoziatives Array&#8220;).<br />
Von der Semantik her sind sie unterschiedlich und das hilft den Zweck besser zu erfassen</p>
<p>&#8211; Mehr als 3 verschiedene sind nie notwendig, denn verschiedene werden nur gebraucht, wenn Schleifen geschachtelt werden. Wenn mehr als 3 Schleifen geschachtelt werden, sollte man refactoren 😉<br />
&#8211; Passt keiner der Begriffe so richtig, oder bleibt es trotzdem etwas ungenau (zB wenn man verschiedene Indeces meinen könnte) sollte man trotzdem die Variable wieder ausschreiben</p>
<p>Was anderes zu Punkt 9: Offenbar liegen im selben Ordner, in dem auch Ordner mit Code-Dateien liegen die Ordner für CSS und JS. Da letztere von Aussen erreichbar sein müssen, müssen sie im Document-Root liegen, was dann aber auch für die Ordner mit den Code-Dateien gilt. Das ist immer etwas riskant 😉 Besser ist es ein &#8222;web&#8220;, &#8222;public&#8220; oder &#8222;html&#8220; einzusetzen, der dann als Document Root fungiert und in der sich bis auf die Bootstrap-Datei keine weitere Datei mit Code befindet.</p>
]]></content:encoded>
						</item>
			</channel>
</rss>
