Stefan, Agreed that writing code to handle all possible eventualities is usually overkill and results in bloated software delivered very late or not at all.
My point is that often OTHERS start adding requests afterward that seem trivial to THEM as they have no idea what it takes. I have often done some kind of data analysis for someone and made a few graphs and suddenly they ask if I can add something else to the graph such as a few horizontal lines showing where a danger zone lies, or some kind of average. No problem but to do that means the new info has to have been made available or can be calculated and often even means my function needs to take more arguments or a wider data.frame. Then they reconsider and ask if instead of a line, can I color the background above that point. Well, yeah, but now I might need to calculate another column to use to guide that feature. Ah, but can you show a series of related such graphs as a unit, or perhaps combine several unrelated graphs in a 3 by 2 matrix. Argh! Sure, I can do that but you did not ask me to before I started. I now might toss out much of my original code and rewrite something so all the things needed are made first and then the graphs are made and recombined in the right output format. This means that what used to make a graph will now make a data structure to return that can be used later to recombine into a bigger consolidated graphic. Does the story end here? Nope. Tons more requests like removing color and using shades of gray or dotted lines so it can be printed on any printer, changing the point size of text and other characteristics and introduce mathematical symbols and equations along the axes and I swear an amazing number of such fine tunings including taking a series of these things into one multi-page PDF. If this was a paid gig and someone offered me a fixed sum, should I tolerate almost any changes? If this was a regular paid job and this made me late and not get other things done? My bottom line is that it may not be reasonable to make a detailed top-down design and stock with it BUT that code written by ever-changing requirements can end up badly too. I shudder at times I wrote decent code full of comments explaining well and a while later had a mess where the comments lagged behind changes in the code as there was no point in bothering to update them unless it stopped changing. And, often, by then, I was no longer interested in spending any more time and sometimes just removed all the comments and moved on! Good luck to anyone coming along to maintain or improve the code. I have to think about when to make a function. Something trivial is often not worth is. And making a very abstract function that can do a dozen things if invoked just right with many arguments is sometimes a tad too much when a few simpler functions might do as well with less overhead and especially when the uses have fairly little in common. Some languages may discourage you if the repeated code needs to do things in the current environment and thus only part of the functionality can be moved away. -----Original Message----- From: Python-list <python-list-bounces+avigross=verizon....@python.org> On Behalf Of Stefan Ram Sent: Saturday, September 11, 2021 10:56 PM To: python-list@python.org Subject: Re: Friday Finking: Contorted loops "Avi Gross" <avigr...@verizon.net> writes: >I have seen not of sort-of redundant code because someone did not plan >ahead From my experience, the "plan ahead" approach (waterfall model) often is less applicable than the "code is design" (Reeve) + "refactoring" (Fowler) approach. (However, in some fields, planning ahead is a requirement). >and realize something very similar might be needed later and thus did >not make a general function they could re-use. Occasionally they may >later go back and re-do but often, not so much and just keep copying >lines and making minor modifications. Same general idea. I remember having read a discussion in the Web. The question was something like: How many times do you have to write a piece of code, before you create a function for it? I believe I still remember two answers: - One time. - Three times. The justification I can't remember, but what I would come up with now would be: (for "one time":) Functions structure your code. You don't have to wait for repetitions as an "excuse" to create them. (for "three times:) Relax. Don't overengineer. You need to have at least /three/ repetitions to be able to see a clear pattern. -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list