for -- else: what was the motivation?

[avi.e.gross at gmail.com]

>>>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.