[Yum] code cleanup: one function in one source

[Vladimir Bormotov]

		Hi, seth!

>>>>> "sv" == seth vidal <skvidal at phy.duke.edu> writes:

 sv> I'm not going to respond to each individual point, but I will give my
 sv> general view:

 ;)
 
 
 sv> I do have to read all the patches that you send me b/c I _HAVE_ to
 sv> read them. I won't apply a patch w/o reading an understanding it so if
 sv> it seems like I'm taking a while its b/c I'm busy with other things.

 I think, 'reading and understanding before applying' is the only right way.
 
 No problem if other things has priority.


 sv> 2. The reason a lot of functions have import module at the beginning
 sv> of them is b/c I moved stuff around quite a bit. So I figured if I
 sv> could cut and paste the module w/little or no modification then it
 sv> made the function more easily used for me or for other things.

 I comment this later, if you please ;)
 
 At that time, we skip discussion about "where place import" ;)))
 
 
 sv> 3. I am not a full time programmer, I've never had any formal training
 sv> in programming save one class. I maintain a large number of linux
 sv> systems for a living and it probably shows in my code. I'm a sysadmin
 sv> who happens to end up doing a lot of weird stuff. Having said that, I
 sv> don't find it horribly unreadable code so I'm not sure how much
 sv> benefit comes from some of the modifications suggested in the style
 sv> guides.

 I am a full time programmer.  And I know, programming is easy science.
 You can do any other work and as hobby - write nice programms.  Not worse
 than experts ;)
 
 Code Styling - first step.  It's not dogma.  Any programming language has
 "style".  With some languages (like C) we can apply a number of styles.
 Proffesional programmer know "how and why" styling help in development.
 
 You can just use Guido's style, understanding comes with experience.
 
 If sometimes I don't understand "how write code better", I do "like Guido
 say".  And never get troubes.  Maybe because GvR one of most expirienced
 python programmers ;-)
 
 
 sv> 4. Regarding additional classes. I can see a couple of places where an
 sv> additional class would be handy but I've not seen a lot of them.
 
 My instructor once has told: "correct way - evolution, not revolution".
 IMHO, we all like small development iterations.  For beginning enough
 one place where we can "do better".
 
 
 sv> Arguments persuading me to remove all functions outside of classes are
 sv> going to need to be DAMNED impressive. I'm not always taken by
 sv> additional classes. Frequently, I find they do a lot for abstraction
 sv> but they also do A LOT for obfuscation. 
 
 Of course, classes only for better abstraction and understanding.  No
 obfiscuration ;)

  
 sv> MANY MANY MANY classes make it hard for non-programmers to begin to
 sv> understand the code, and given that this code is for a utility that A
 sv> LOT of sysadmins could use it would seem to me to be useful to make
 sv> sure that they can understand it.

 I agree.  But how many ppl can understand code like this:
 
        (e1, v1, r1) = rpmNevral.evr(name, arch)
        (e2, v2, r2) = str_to_version(obvalue[3])
        rc = compareEVR((e1, v1, r1), (e2, v2, r2))

 what they can do: 
   1. track up source, what we hold in 'obvalue'.  Suprize!  
      
      for ob in obs:
          obvalue = string.split(ob)
      
   2. track up source, from where we get 'obs'...
   3. ...
      
 eeehhh...  Me don't like criticize.
 
 Just small example ('code from head', not tested, simple an idea), how
 'for ob in obs:' must look:
 
   for package in obsoletes:
       if rpmNevral.has(package.name):
           if rpmNevral[package.name].obsoleting(package):
               packages.append(package)
               obsdict[package] = package.name
               log(4, '%s oblsoleting %s' % (package.name, package))
   
 more than 50 lines (more than two screens at standard text console) of
 code moved out into 'obsoleting' method of some 'abstraction'.  One action
 and one loging for all 15 "obsoleting or no?" varinats (3 result codes, 5
 comparisons).  No duplicates and no mistakes.
 
 
 btw, I don't understand what for to us 'packages' in returnObsoletes?
 At start we say packages = [].  Inside, we only append to them  some
 (name, arch).  At final, we return obsdict.  Anywhere in clientStuff 
 'packages' not used.
 
 How 'not expirienced guy' can understand 'for what we use packages?  What
 here magick?
 
 Nice casual illustration?  ;)
 

 sv> I'm not wed to this concept in anyway, and I might be more than glad
 sv> to get rid of it and add in a bunch of classes.  But I learned how to
 sv> program mostly in perl and some C, so I'm more comfortable with
 sv> procedural programming. 
 
 it's not a problem ;)

  
 sv> Object Orientation is great for some things but I know what the old
 sv> yup code looked like and I'm a little afraid of "object orienting" to
 sv> that extent.

 We shall help You to not be afraid OO-code ;)
 
 
 sv> 5. I'm using this program everyday on quite a few systems and the
 sv> reason I didn't go with apt-rpm was that I wanted to completely
 sv> understand what the code was doing when it did it, so if I'm slow in
 sv> integrating patches its b/c I'm thinking about them and making sure I
 sv> understand them.

 Once more "yes".  Ease of understanding - primary target.  If some code
 modification will complicate understanding, just say "we go in a wrong
 direction". 
 
 
 sv> So, in summary, I am reading through all the emails regarding style
 sv> and I'll address them as soon as I can. (refer to my last email about
 sv> the broken hard drive :)

 I wish the quickest decision a problem with a hard drive.
 
 
 sv> I'd like to make it cleaner looking but it is possible that your
 sv> concept of cleaner and my concept of cleaner might not gibe.

 Two persons always will come to agreement if they want it ;)))

-- 
		Bor.