"Uwe Mayer" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > con: If you are planning larger applications (for a reasonable value of > "large") you have to discipline yourself to write well structured code.
As always. > Then you will want to specify interfaces, accessor functions with different > read /write access, ... Why? What advantage does this really give you over indicative doc strings? interfaces in particular are a modern madness. Why not just define a class with a set of unimplemented methods. Who cares if someone tries to instantiate it? What can they do with it? They only make sense in languages which are statically typed and rely on inheritance to implement polymorphism. Pure accessor methods are usually a mistake anyway, but can be done using properties if you really must. > Unless you have designed the software interactions completely bevorehand > (which never works out) this is the only way to incorporate changes without > refactoring your source all the time. On really big projects it is fairly normal to define the structure of the code to quite a detailed level - often using Case tools and UML etc - so refactoring is only needed when you discover a hole. Thats true regardless of size of project but the Case approach tends to limit the damage. > this should be expanded further, i.e. more build-in decorators for > interfaces, abstract classes, parameter and return value restrictions. What kind of parameter and return value restrictions? In a dynamically typed language there is a limit to what can be applied, and much of that is of limited value IMHO. > with Perl than with Python and since there is no way of forcing a > programmer to do it a certain way, I'm always uncomfortable about trying to "force" a programmer to do it a certain way. I can never know what circumstances those client programmers might be facing when I write/design my code. And I can never be sure that I know better than the client programmer. I've seen too much C++ code that begins #define private public to believe that trying to force programmers rather than inform them is a good idea. (And FWIW I have worked on several multi million line projects with upwards of 400 programmers working in 5 or more locatons in Lisp, C, SQL, COBOL etc. Attempts to impose rules rather than agreed protocols have never been very helpful in my experience) > its often easyer to rewrite Perl programs over 400 lines That probably has a lot more to do with Perl's inscrutable syntax and "many ways to do it" approach than any of the classifiers being discussed here! I certainly didn't find us rewriting Lisp code rather than enhancing what was there, and Lisp shares much of Python's approach to life. -- Alan G Author of the Learn to Program web tutor http://www.freenetpages.co.uk/hp/alan.gauld -- http://mail.python.org/mailman/listinfo/python-list
