<?xml version="1.0" encoding="utf-8"?>
<!-- If you are running a bot please visit this policy page outlining rules you must respect. https://www.livejournal.com/bots/ -->
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:lj="https://www.livejournal.com">
  <id>urn:lj:livejournal.com:atom1:openvz</id>
  <title>OpenVZ</title>
  <subtitle>OpenVZ</subtitle>
  <author>
    <name>OpenVZ</name>
  </author>
  <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/"/>
  <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom"/>
  <updated>2009-11-17T20:50:43Z</updated>
  <lj:journal userid="9392309" username="openvz" type="community"/>
  <link rel="service.feed" type="application/x.atom+xml" href="https://openvz.livejournal.com/data/atom" title="OpenVZ"/>
  <entry>
    <id>urn:lj:livejournal.com:atom1:openvz:30163</id>
    <author>
      <name>Kir Kolyshkin</name>
    </author>
    <lj:poster user="k001" userid="990679"/>
    <link rel="alternate" type="text/html" href="https://openvz.livejournal.com/30163.html"/>
    <link rel="self" type="text/xml" href="https://openvz.livejournal.com/data/atom/?itemid=30163"/>
    <title>vzctl-3.0.24 is on its way; some thoughts on code refactoring</title>
    <published>2009-11-17T20:50:43Z</published>
    <updated>2009-11-17T20:50:43Z</updated>
    <category term="programming"/>
    <category term="openvz"/>
    <category term="vzctl"/>
    <content type="html">Long time no see. It's 11pm here now and I'm still in the office. Just though about why not to post to the blog right before I drive home. Really, why not?&lt;br /&gt;&lt;br /&gt;I'm mostly working on new vzctl release lately (you can see the progress in vzctl's git web interface &lt;a href="http://git.openvz.org/?p=vzctl;a=summary" target="_blank" rel="nofollow"&gt;here&lt;/a&gt;). The ultimate task is to fix most of bugs opened for vzctl in OpenVZ bugzilla (some are dated back to 2007 -- no, they are not critical or even major, but anyway). So far &lt;a href="http://bugzilla.openvz.org/buglist.cgi?query_format=advanced&amp;amp;bug_status=NEW&amp;amp;bug_status=ASSIGNED&amp;amp;bug_status=REOPENED&amp;amp;component=vzctl&amp;amp;product=OpenVZ" target="_blank" rel="nofollow"&gt;the list of vzctl bugs yet opened&lt;/a&gt; are down to one singe page (i.e. scroll bar has disappeared from the browser window) which is a big improvement.&lt;br /&gt;&lt;br /&gt;The process is somewhat slow because of my attitute to fix even minor things thenever I notice them -- known as &lt;a href="http://en.wikipedia.org/wiki/Code_refactoring" target="_blank" rel="nofollow"&gt;code refactoring&lt;/a&gt;. The simplest example is when you open a C file in vim (or Emacs, whatever) and see that there are spaces instead of tabs. When you notice it, there are three ways to go: (A) leave it as is; (B) fix it in place, keep working on what you've planned, commit; (C) fix it, make a separate commit, then continue working on what you've planned.&lt;br /&gt;&lt;br /&gt;Way A is not that bad, actually, it's definitely better than B, because the result of B is a spaghetti of a functional (e.g. a new feature or a bugfix) and non-functional (e.g. whitespace cleanup) changes. Mixing apples and oranges is a bad thing to do: it makes patch review harder, it makes porting between branches harder, and in case you'll want to revert the patch (say because of a bug in new code) you will also revert those cleanups (which are not buggy). So, if you are not a perfectionist, better follow way A but please not B.&lt;br /&gt;&lt;br /&gt;Unfortunately I just can't ignore the bad things I see, so I follow the way C. Sometimes this is very annoying, because instead of implementing a new feature you keep refactoring your code for hours, sometimes even days. No, it's not only whitespace cleanups or fixing typos in comments. Sometimes you see that there are a few identical snippets of code and you put that code into a new function. Sometimes you notice that some function arguments are unused (or always the same) and you remove those. Sometimes you just read the code and see there is a bug in it, and you fix it. Oh, the text of error message is not clear enough -- you fix it. The typesetting of a man page is wrong (e.g. bold is used instead of italic for variable argument) -- you fix it. You see that a function is not used outside of the source file -- you make it static and remove its prototype from a header file. You notice a typo in the function name (and of course also in every place that calls it, since otherwise that code won't compile) -- you fix it. A typo in a comment -- fix it! And so on, and so forth...&lt;br /&gt;&lt;br /&gt;Every single thing from the above paragraph (and some more) happened to me when I was working on the boot order priority feature (the subject of &lt;a href="http://bugzilla.openvz.org/1300" target="_blank" rel="nofollow"&gt;OpenVZ bug #1300&lt;/a&gt;). So I ended up with 22 (twenty two) code commits, from which 3 implement the actual feature, 1 documents it, and the other 18 are all code refactoring, preparation and minor bugfixing.&lt;a name='cutid1-end'&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;The way to perfection is never easy. That doesn't mean we shouldn't try.</content>
  </entry>
</feed>
