<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DZone Snippets: compactness code</title>
    <link>http://snippets.dzone.com/posts</link>
    <pubDate>Wed, 23 Jul 2008 02:21:09 GMT</pubDate>
    <description>DZone Snippets: compactness code</description>
    <item>
      <title>compactness considered harmful</title>
      <link>http://snippets.dzone.com/posts/show/3761</link>
      <description>the guys over @ http://101out.com/optimize_html_size.html have a nice post about writing compact code to &#8216;give your site that edge&#8217; (my words) by compacting the hell out of your html and css. Sound as it sounds, it may very well not be what you want, or need.&lt;br /&gt;&lt;br /&gt;for coding means authoring, writing, creating engines that do work. meaningful work, at the least working around meaning. your snippets count. they&#8217;re also a technology that is about posterity, and be that the next day. even if you don't plan your work, you still have some sort of goal when doing it, a future state. &lt;br /&gt;&lt;br /&gt;there's a reason for most programming languages to be readable. however, programming and natural languages alike are but slate for chalk. so while it is perfectly possible to say `vals1=parms[:attrs]`, in most cases code like `attributiveValues=parameters[:attributes]` can assist you and others in reading, understanding, &amp; writing code that makes that more sense. &lt;br /&gt;&lt;br /&gt;in other words, so that others may better undestand me, i try to use language in a way that is less terse and cryptic than some of the usage that bytecount-aficionad&#243;s defer to. you'll be soon outgrown by tomorrow&#8217;s technologies if your hard work goes into maxing out byte efficency by hand. consider how much you can squeeze out of a webpage in turns of size. a few thousand bytes. i'm not talking about oversized `*.jpg`s here, those are still chunky. i talk about your `*.js`es, your `*.html`s and your `*.py`s. look, you squeeezed those bytes out of &lt;code&gt;.top-left-div{border-width:1px}&lt;/code&gt; so now it reads &lt;code&gt;.tld{border-width:1px}&lt;/code&gt;, and with 8-odd bytes still dripping from your fingers, you *forget* about that, it&#8217;s *history* to you. &lt;br /&gt;&lt;br /&gt;meanwhile, some nerd has installed a freifunk wifi repeater in your street, meaning that the increased efficiency of your ambience means a far bigger increase in website availability than what your lexical shortcircuiting achieved. &lt;br /&gt;&lt;br /&gt;back in the future, generations write many commentaries about the possible hidden semantics in css class `.tld`. did those guys really plan to take over a `top-level-domain` and thrive on `http://*.music` as soon as back in 2007? five years before they did? who knows? &lt;br /&gt;&lt;br /&gt;this is not against abbreviations. my own code is full of `*P`s and `**Q`s, what would be `*args` and `**kwargs` much anywhere else. when i find i can establish a useful convention, i do that. so, maybe think it this way: are those `attributes` worth of being called the `A`s here and elsewhere? if you&#8217;re sure, go for it. you just saved 9 times repetitions bytes, that may add up to a lot. if you hate that much typing, get yourself a word completing ide (see, another abbr). but drop those `attrs` and `attribs`. &lt;br /&gt;&lt;br /&gt;&lt;br /&gt;&lt;br /&gt;</description>
      <pubDate>Wed, 04 Apr 2007 19:01:53 GMT</pubDate>
      <guid>http://snippets.dzone.com/posts/show/3761</guid>
      <author>LoveEncounterFlow (Flow)</author>
    </item>
  </channel>
</rss>
