>>>Which is more disparaging: "I couldn't find anyone suggesting this" or "The only place I could find it was a PHP style guide"? >>>ChrisA
Chris, If someone says they heard something from their own personal guru, people often do not feel threatened or argue. I often am told nutrition or medical or other advice that I simply ignore especially if it is about exotic herbs to use or weird ideas like homeopathy or that I should use language X because it is the only way to a haven or heaven or whatever. What we had here was someone suggesting their advice was WELL-KNOWN followed by lots of people sputtering about not having heard of it. I actually think the advice would be reasonable in many circumstances as long as it did not conflict with dozens of goals I find more compelling but which vary on a case by case basis such as whether I am prototyping something I will use once, ... I have studied PHP but have never felt a need to use it and arguably the roles it has played are often done commonly by other programs or methods. Some people might say the same for many languages that are going extinct or that have had to change and adapt to keep being relevant. Had the user mention this was advice given regarding programs in the original BASIC or in COBOL or PASCAL or lots of other languages I may have once used but rarely see much point in caring about, it would be no different. But having ONE source is troublesome. I mean most languages used will suggest some form of making some kinds of variable names meaningful within various constraints. The constraints may be that the maximum length is bounded or that it cannot start with a number (or perhaps underscore) or contain some characters. But other advice varies enough that there is no RIGHT or WRONG across languages. I have seen suggestion to use camelCase or use periods or underscores between parts of a variable name. I have seen suggestions to use a unique prefix or suffix to mark all your own variables as a way to minimize the chance of namespace collisions. Some languages suggest or even enforce that some names be all upper case or have an initial uppercase letter while others should be completely lower case. I mean things like function names versus method names versus class names and so on. The more global advice is ADVICE that suggests whatever method you choose, be consistent. If you make class names a certain way, do it as much as possible for all class names and avoid doing the same thing for non-class names. I think quite a few suggestions fall into the category that they are similar or abstractly enough suggested in many programming languages and by many people. There may be a big enough consensus, perhaps with some outliers, that it may be accepted as reasonable advice to not be ignored without good reasons. So in my view, the objection is not about PHP but about uniqueness. If the author of one Python textbook and no others, suggest that your code should declare all imports in alphabetical order then declare all functions in alphabetical order, they can not only safely be ignored, but perhaps not taken seriously as imports sometimes need to be done carefully if something needs something else and if a language needs functions to be defined before another function body calls them, ... I was not questioning that someone had heard this advice somewhere and did not just make it up. Others searching had trouble finding it but that does not prove anything. Someone finally found one example, which is fine and I suspect there may be other examples found if the search was broader. I suspect there are plenty of places that advise that you should write such code so the main things is visible on the current screen and not buried deeply. But some people seem to miss a point we have discussed. The odd clauses like ELSE after a loop (and quite a few variants in similar and different cases) often provide guarantees such as making sure a file opened is closed. If you look at a Python protocol such as WITH, then things implementing it arrange it so under most circumstances other than pulling a power line out of the wall, the darn file gets closed no matter how you exit the area, and other scenarios try to clean things up even as exceptions are being handled. Sometimes not using these constructs and using something you think is identical but looks better to you, can result in unanticipated behavior. Putting items in a finally or other such clause can be meaningful and sometimes makes some things quite explicit and reliable. Are these things out of the way? Yes, but so what? I see things as a whole not as just a single screen shot. If a loop has several optional clauses lie we are discussing and you know they are normally near the end, then look for them where they are. I know some languages, JavaScript being an example, may have things you might consider odd such as promoting some things like function definitions found further in your code to near the top so you can use a function that is not defined till later even without something like a forward declaration used in other languages. A similar feature allows a default to a case-like statement to be placed anywhere but then be effectively moved to the bottom. This means you can make it very visible at or near the top if you want. As I say, languages and idioms vary. What may be easy to make visible in some is hard or not possible to do easily in another. Thus I keep suggesting you consider using things like comments that help spell out the logic up front and perhaps some that comment on which IF or ELSE the current close bracket (or change in indentation) is connected to or say up front that hundreds of lines later at the end of this loop, look for several clauses that are part of the same logic but have to be placed there, and later on comment at that site what these are there for to modify the above loop. Not perfect but sometimes you work with what you have. I am now going to stop replying on this topic as I have said way too much and am not in particular disagreement if we are discussing preferences and ideas. I see TOOLS here, not religion. Use what works or that has to be used for a task but don't take any one thing too seriously. -- https://mail.python.org/mailman/listinfo/python-list
