Hi, I have some code more or less 500 lines, but very messy code. All codes containing several functions are in one module, besides, without documentation and testing. Could anyone give me some advice to organize my messy code in an accurate style including test function as well? Any answers will be appreciated, -- Bakhtiyor Zokhidov
I have some code more or less 500 lines, but very messy code. All codes containing several functions are in one module, besides, without documentation and testing.
Could anyone give me some advice to organize my messy code in an accurate style including test function as well?
This is a really broad, non-numpy specific question. You'd best read up on good programming practices in general. But you've answered a good portion of your questions already:
All codes containing several functions are in one module
Nothing wrong with that -- functions that are likely to be used together belong in one module -- and while Python supports namespaces (one honking great idea), pythonic style supports keeping those namespaces flat (flat is better than nested) So do you need to do any different stucture? I'd look for two things: 1) the DRY principle (Don't Repeat Yourself) -- if you have essentially the same code in multiple places, refactor that out into utility functions, or classes, or... 2) Do classes make sense? Look for patterns like: function_a(data_structure_1, some, other, arguments) function_b(data_structure_1, some, other, arguments) function_c(data_structure_1, some, other, arguments) that is the C procedural style -- nothing wring with that, but it may be better suited to a class -- the class holds your data structure and the functions that operate on it in one place. But: "if a class has only two methods, and one of them is __init__ -- you don't need a class": http://pyvideo.org/video/880/stop-writing-classes also see: http://pyvideo.org/video/879/the-art-of-subclassing For why you would want to use classes...
without documentation and testing.
This one is easy: add documentation and testing! put docstings in your functions and classes -- if the package is big enough to warrant it, use Sphinx to document it -- it can extract the docstrings, and give you a nice framework for writing up more extensive docs. Testing: This sounds like a collection of functions -- you want unit tests -- read up on unit testing (and test-driven development) and the write them. I suggest nose or pytest (I prefer pytest, it's got some nice features, but either is fine). You can also use the stdlib unittest, but I found it overly wordy and klunky. HTH, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On 12 June 2013 18:27, Chris Barker - NOAA Federal <chris.barker@noaa.gov> wrote:
without documentation and testing.
This one is easy: add documentation and testing!
This lecture may help you. It uses unittest, though, but the idea is applicable to whatever system you use: https://python.g-node.org/python-summerschool-2012/software_carpentry And for a brief introduction to best practices, you could see this: https://python.g-node.org/python-summerschool-2012/best_practices David.
participants (3)
-
Bakhtiyor Zokhidov -
Chris Barker - NOAA Federal -
Daπid