<?xml version="1.0" encoding="utf-8" ?>

<rss version="2.0" 
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:admin="http://webns.net/mvcb/"
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
   xmlns:content="http://purl.org/rss/1.0/modules/content/"
   >
<channel>
    <title>Code in the hole (Entries tagged as readability)</title>
    <link>http://codeinthehole.com/</link>
    <description>David Winterbottom</description>
    <dc:language>en</dc:language>
    <generator>Serendipity 1.3.1 - http://www.s9y.org/</generator>
    
    

<item>
    <title>Return false with prudence</title>
    <link>http://codeinthehole.com/archives/33-Return-false-with-prudence.html</link>
            <category>Development</category>
    
    <comments>http://codeinthehole.com/archives/33-Return-false-with-prudence.html#comments</comments>
    <wfw:comment>http://codeinthehole.com/wfwcomment.php?cid=33</wfw:comment>

    <slash:comments>2</slash:comments>
    <wfw:commentRss>http://codeinthehole.com/rss.php?version=2.0&amp;type=comments&amp;cid=33</wfw:commentRss>
    

    <author>nospam@example.com (David Winterbottom)</author>
    <content:encoded>
    &lt;p&gt;From &quot;Javascript: the good parts&quot;:&lt;/p&gt;
&lt;blockquote&gt;
It is rarely possible for standards comittees to remove imperfections from a language because doing so would cause the breakdage of all of the bad programs that depend on those bad parts.  They are usually powerless to do anything except heap more features on top of the existing pile of imperfections.
&lt;/blockquote&gt;
&lt;p&gt;Douglas Crockford&#039;s terse yet lucid javascript primer makes some excellent points on writing in a language with more than its fair of share of shortcomings.  The advice is manyfold: constituting functionality or design decisions to avoid (the &quot;bad&quot; and &quot;awful&quot; parts) as well as patterns and practices making use of the strongest parts of the language.  Essentially,  one is guided to programming within a subset of the language, avoiding the poor quality and outright dangerous components.  This chimes in well with the notation of &quot;programming &lt;em&gt;into&lt;/em&gt; a language&quot; rather than within in it - stressed by the seminal &quot;Code Complete&quot; by Steve McConnell.&lt;/p&gt;
&lt;blockquote&gt;
Don&#039;t limit your programming thinking only to the concepts that are supported automatically by your
language. The best programmers think of what they want to do, and then they assess how to accomplish their objectives with the programming tools at their disposal.
&lt;/blockquote&gt;

&lt;p&gt;Both these concepts are relevant to programmers of PHP - a language carrying just as much baggage as javascript.  In my experience, developers who have only known PHP are prone to employing of a variety of bad practices and anti-patterns.  Such things are fostered by several influences, including the forgiving nature of the language, the veritable wealth of bad advice within the comments on the PHP manual, and a general lack of understanding of the art of object-oriented programming.  Indeed, I think it&#039;s essential that PHP developers learn to program (and hence &lt;em&gt;think&lt;/em&gt;) in other languages: python and java in particular.  Reading the work of Martin Fowler is a good place to start but that&#039;s a topic for another time.&lt;/p&gt;  &lt;br /&gt;&lt;a href=&quot;http://codeinthehole.com/archives/33-Return-false-with-prudence.html#extended&quot;&gt;Continue reading &quot;Return false with prudence&quot;&lt;/a&gt;
    </content:encoded>

    <pubDate>Thu, 28 Jan 2010 22:00:00 +0000</pubDate>
    <guid isPermaLink="false">http://codeinthehole.com/archives/33-guid.html</guid>
    <category>php</category>
<category>readability</category>

</item>

</channel>
</rss>