On 10/16/06, Jonathon Sisson <[EMAIL PROTECTED]> wrote:
Chris Hengge wrote:
> I chose the way I used the names because to me...
>
> outFile = open(aFile.lower(), 'w') # Open output buffer for writing.
> = open a file with lowercase name for writing.
> it is implied that aFile is from the zip, since it is created in the
> loop to read the zip..
>
> outFile.write(zFile.read(insideZip)) # Write the file.
> = write what is read from inside the zip file.
>
> I guess for declaration it isn't very clear, but thats what comments are
> for?
> My naming was purely for my ease of mind.. I personally care less about
> what I call it when I declare, as to how it logically flows when I go to
> use it. I'm sure this is considered poor method, but once I declare a
> method I tend to never need to change the declaration, just how I use
> the info... I hope that makes sense.
>
Even if you're the only person that EVER lays eyes on that code (and you
inherited Perl code, so I assume someone will eventually take this code
over) it's vital to use names that are clear and concise. If you
disagree, put your code away in a locked box, then re-read it after six
months and see if it makes perfect sense.
As Kent said, this is quite a minor issue that shouldn't be paraded, but
I have been on the receiving end of code such as:
int a;
if (a == 0)
{
/* do something interesting */
}
else
{
/* do something less interesting */
}
(Sorry for the Java-ish flair...Java happens to be on my mind at the
moment...)
Even if I was there when the code was written, how could I know what "a"
means a month later without digging back through to see how it's used?
(and worse, "a" was used for conditional testing in this specific
example (i.e. on/off conditions), so a boolean would have done MUCH
better). Commenting can only help so much...the code must speak for
itself at some point. (Yes, I know this is an extreme example, but it
happens all the time).
Something like this is much more readable:
boolean fileExists;
if (fileExists)
{
/* do something interesting */
}
else
{
/* do something less interesting */
}
I'm not complaining, because afterall it's up to you to write the code
you're comfortable with (because you're not working on a team, that is),
but a friendly suggestion on naming conventions (especially when you can
refactor in most IDE's today) could go a long ways to helping you build
readable code that is easier to maintain.
Jonathon
> On 10/16/06, *Kent Johnson* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED] >> wrote:
>
> Chris Hengge wrote:
> > Here is my solution, completed with (I think) all your suggestions...
> >
> >
> #########################################################################
> > def extractZip(filePathName):
> > """
> > This method recieves the zip file name for decompression,
> placing the
> > contents of the zip file appropriately.
> > """
> > if filePathName == "":
> > print "No file provided...\n"
> > else:
> > try: # Attempt to unzip file.
> > zFile = zipfile.ZipFile(filePathName.strip('"'), "r")
> > for aFile in zFile.namelist(): # For every file in
> the zip.
> > # If the file ends with a needed extension,
> extract it.
> > for ext in ['.cap', '.hex', '.fru', '.cfg', '.sdr']:
> > if aFile.lower().endswith(ext):
> > insideZip = aFile # Copy of Filename.
> > if "/" in aFile: # Split the filename if '/'.
> > aFile = aFile.rsplit('/', 1)[-1]
> > elif "\\" in aFile: # Split the filename
> if '\'.
> > aFile = aFile.rsplit('\\',
> > 1)[-1]
> > outfile = open( aFile.lower(), 'w') # Open
> > output buffer for writing.
> > outfile.write(zFile.read(insideZip)) #
> Write the
> > file.
> > outfile.close() # Close the output file
> buffer.
> > print "Resource extraction completed successfully!\n"
> > except IOerror, message: # If file creation fails, let
> the user
> > know.
> > print "File could not be written: \n"
> > print message
> >
> >
> #########################################################################
> > Definatly an improvement! Thanks Kent.
>
> Yes, that is what I meant. One minor quibble, I think I would keep
> aFile
> as the name in the zip, since that is what it starts as, and use a new
> name for the external file name. Maybe you could use better names, for
> example zipPath and fileName. I think that would make the code a little
> clearer but it is a very minor point.
>
> Kent
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Tutor maillist - Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor
_______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
