<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Cpp on Karpoke - Just Another Blog</title><link>http://karpoke.ignaciocano.com/tags/cpp/</link><description>Recent content in Cpp on Karpoke - Just Another Blog</description><generator>Hugo -- 0.167.0</generator><language>es</language><lastBuildDate>Sun, 08 Feb 2015 19:25:00 +0100</lastBuildDate><atom:link href="http://karpoke.ignaciocano.com/tags/cpp/index.xml" rel="self" type="application/rss+xml"/><item><title>The Exceptional Beauty of Doom 3’s Source Code</title><link>http://karpoke.ignaciocano.com/2015/02/08/the-exceptional-beauty-of-doom-3s-source-code/</link><pubDate>Sun, 08 Feb 2015 19:25:00 +0100</pubDate><guid>http://karpoke.ignaciocano.com/2015/02/08/the-exceptional-beauty-of-doom-3s-source-code/</guid><description>&lt;blockquote&gt;
&lt;p&gt;What would ”nice looking”—or ”beautiful”, for that matter—actually
mean when referring to source code? I asked some programmer friends
what they thought that meant. Their answers were obvious, but still
worth stating:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Code should be locally coherent and single-functioned: One
function should do exactly one thing. It should be clear about
what it’s doing.&lt;/li&gt;
&lt;li&gt;Local code should explain, or at least hint at the overall system
design.&lt;/li&gt;
&lt;li&gt;Code should be self-documenting. Comments should be avoided
whenever possible. Comments duplicate work when both writing and
reading code. If you need to comment something to make it
understandable it should probably be rewritten.&lt;/li&gt;
&lt;/ul&gt;
&lt;/blockquote&gt;
&lt;p&gt;» Shawn McGrath | &lt;a href="http://kotaku.com/5975610/the-exceptional-beauty-of-doom-3s-source-code"&gt;kotaku.com&lt;/a&gt;&lt;/p&gt;</description></item></channel></rss>