Go ahead. Stop programming. This ensures you from any mistakes.

In other words, the "outer" variable i has scope which includes the
part of the block before it was declared. There's then an extra rule:

It is a fact that statements are executed seqientially, one after another.
It is truth that a block of instructions is executed as one statement. It is
truth that the variables in the imerative languages, which allow deferred
declarations, are visible only past declaration. Acquiring these basic
matters, everybody understands that the parent block variables declared past
the block are not visible inside the block and that the block internal
variables are not visible past the block. The other considerations are
irrationale.



<quote>In certain
situations but not in the exampe above, this could lead to a compile-
time error if the statements of the block were later to be rearranged.
</quote>

Rearranging code always can yeild errors. Does this argument give me power
to infer arbitrary rules?



They tell us they pursue language
simplicity. The rule "do not define a variable more than once in the same
context" is natural, and simplest therefore. All normal languages obey it
therefore. Overcomplicating a grammar by injecting more barrieres is a
path
right away from simplicity.

Another obstacle at the plain place introduced
in C# for no reason is blocking "fall throughs" in switch -- the feature
wich can be very useful sometimes.

Very useful sometimes when it's deliberate, but also very painful when
you don't want it and accidentally have it. Note that you *can* use
multiple cases for a single block, you just can't have case/code/case/
code without a break.

I suspect that when working with C, I ran into more times when I
forgot to include the break than times when I deliberately wanted to
fall through.


I suppose that the first thing the programmers should know is the sequence
of instruction execution. Normally, the statements are eveluated
sequentially. Should we put an explicit branch after each and every
statement to avoid the natural "fall through"? The fallthrough ban does not
save you from the infinite kinds of errors you still can make, including
wrong branching. It just infers a fair amount of code where it is
unnecessariy. You should consider avoid programming be safe. I doubt that
the requirement to pile up the loads of syntactic salt improves the quality
of code the unconscious people produce.


.

Relevant Pages

  • Re: pseudo-namespacing in JavaScript
    ... SCRIPT element the outcome becomes very different. ... assignment, and if the DIV element had been shown to proceed the SCRIPT ... execution context where the spec says it should not. ... that function declarations will replace the ...
    (comp.lang.javascript)
  • Re: IE javascript bug: global variable
    ... Global variable declarations result in properties of the ... actual execution of code in that context. ... That's another aspect of this bug that puzzles me; ... both variable instantiation and actual code ...
    (comp.lang.javascript)
  • Re: =function(){...}
    ... function identifier() { ... are parsed into function objects before execution begins. ... Function expressions are different in that they only create function objects /if/ they are evaluated. ... That is, global function declarations are parsed immediately, but inner functions are only parsed when their outer function is called. ...
    (comp.lang.javascript)
  • Re: Go ahead. Stop programming. This ensures you from any mistakes.
    ... Statements can be, and some definitely are, executed in parallell or out of sequence, as long as the result in every relevant aspect is the same as if they were executed in the sequence specified in the code. ... truth that the variables in the imerative languages, which allow deferred declarations, are visible only past declaration. ... In a switch statement you are jumping into one of many code blocks, it's not at all unreasonable that each block should end with a statement that specifies where the execution should continue. ... This requirement adds a bit of unnecessary code in a few cases, but a bit of unnecessary code is very often used to keep the language consistent and clear. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: A note on Peter Seebachs vicious little tirade
    ... main may have declarations compatible with those. ... after, and correct code is provided from then on, IIRC. ... The first sample program in K&R2 is: ... In the interests of simplicity, ...
    (comp.lang.c)