<?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/  -->
<rss version='2.0'  xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:media='http://search.yahoo.com/mrss/' xmlns:atom10='http://www.w3.org/2005/Atom'>
<channel>
  <title>OpenVZ</title>
  <link>https://openvz.livejournal.com/</link>
  <description>OpenVZ - LiveJournal.com</description>
  <lastBuildDate>Tue, 17 Nov 2009 20:50:43 GMT</lastBuildDate>
  <generator>LiveJournal / LiveJournal.com</generator>
  <lj:journal>openvz</lj:journal>
  <lj:journalid>9392309</lj:journalid>
  <lj:journaltype>community</lj:journaltype>
  <image>
    <url>https://l-userpic.livejournal.com/128680075/9392309</url>
    <title>OpenVZ</title>
    <link>https://openvz.livejournal.com/</link>
    <width>100</width>
    <height>100</height>
  </image>

  <item>
  <guid isPermaLink='true'>https://openvz.livejournal.com/30163.html</guid>
  <pubDate>Tue, 17 Nov 2009 20:50:43 GMT</pubDate>
  <title>vzctl-3.0.24 is on its way; some thoughts on code refactoring</title>
  <author>k001</author>
  <link>https://openvz.livejournal.com/30163.html</link>
  <description>Long time no see. It&apos;s 11pm here now and I&apos;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&apos;m mostly working on new vzctl release lately (you can see the progress in vzctl&apos;s git web interface &lt;a href=&quot;http://git.openvz.org/?p=vzctl;a=summary&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;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&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&quot;http://en.wikipedia.org/wiki/Code_refactoring&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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&apos;ve planned, commit; (C) fix it, make a separate commit, then continue working on what you&apos;ve planned.&lt;br /&gt;&lt;br /&gt;Way A is not that bad, actually, it&apos;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&apos;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&apos;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&apos;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&apos;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=&quot;http://bugzilla.openvz.org/1300&quot; target=&quot;_blank&quot; rel=&quot;nofollow&quot;&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=&apos;cutid1-end&apos;&gt;&lt;/a&gt;&lt;br /&gt;&lt;br /&gt;The way to perfection is never easy. That doesn&apos;t mean we shouldn&apos;t try.</description>
  <comments>https://openvz.livejournal.com/30163.html?view=comments#comments</comments>
  <category>programming</category>
  <category>openvz</category>
  <category>vzctl</category>
  <lj:security>public</lj:security>
  <lj:poster>k001</lj:poster>
  <lj:posterid>990679</lj:posterid>
  <lj:reply-count>4</lj:reply-count>
  </item>
</channel>
</rss>
