On Fri, 11 Feb 2011 16:31:09 -0800, Martin De Kauwe wrote: > The 100+ parameters just means "everything" can be adjusted outside of > the code, invariable most of it isn't.
If people aren't going to change all these parameters, why are you spending the time and energy writing code for something that won't happen? There are *real costs* to increasing the amount of customization people can do with your code. The more complex your code, the more bugs it will contain. You should consider this almost a law of nature. The more power you give people to change parameters, the more often they will hit unexpected interactions between parameters that you never imagined. You should expect bug reports that will take forever to track down, because (for example) the bug only occurs when param #37 is larger than param #45, but only if param #62 is less than param #5 and both are less than 100 and param #83 is a multiple of 17... The more complex your code, the more tests you will need to be sure the code does what you expect. The number of combinations that need testing *explodes* exponentially. You simply cannot test every combination of parameters. Untested code should be considered buggy until proven otherwise. Think very carefully before allowing over-customization. Take into account the costs as well as the benefits. Then, if you still decide to allow all that customization, at least you know that the pain will be worth it. > As I said I am happy to consider a dictionary, although some of the > calculations are quite complex and I *think* it is easier to read this > way, rather than with a dictionary. I believe that most of these calculations should be written as functions which take arguments. This will allow better testing and customization. Instead of writing complex calculations inline, you should make them functions or methods. There's little difference in complexity between: my_calculation(arg1, arg2, arg3, params.x, params.y, params.z) and my_calculation(arg1, arg2, arg3, params['x'], params['y'], params['z']) (although, as you have realised, the second is a little more visually noisy -- but not that much). Better still, have the function use sensible default values: def my_calculation(arg1, arg2, arg3, x=None, y=None, z=None): if x is None: x = params.x # or params['x'], who cares? if y is None: y = params['y'] # or params.x ... This gives you the best of both worlds: you can supply parameters at runtime, for testing or customization, but if you don't, the function will use sensible defaults. > That is purely an opinion, I don't > have a computer science background and so I am asking really, is what I > am doing very bad, and if so why? What do other people do? I have tried > to search a lot on this subject but I find the example not very > specific, (or I am reading the wrong places). Whether you use obj.x or obj['x'] is the least important part of the problem. That's merely syntax. -- Steven -- http://mail.python.org/mailman/listinfo/python-list