Are Local Scopes Good Practice?

[Stove]

Hello Everyone,

I have a quick question about local scopes: I've always wondered whether or not using them is good practice. I find them useful for long blocks of code where its convenient to use 1 letter variable names that only need to be used temporarily, usually for general output or writing to files. That way you don't have random 1 letter variables floating around after the scope. For example:

C#:

//Writes text to a custom console control (console1) through an interface (ConsoleWriter). {     ConsoleWriter r = (ConsoleWriter)console1;     r.Write("Today is: ");     r.Write(DateTime.Today.ToLongDateString(), Color.Blue);     r.Bump();     r.Write("The current time is: ");     r.Write(DateTime.Now.ToLongTimeString(), Color.Blue);     r.EndSegment(); } for (int r = 0; r < 10; r++) {...}

I also find they make code easier to read, if you add a comment describing what the block does.

So, are local scopes good practice? Or should I avoid using them altogether? Or are there certain conditions I should avoid using them for? Any thoughts would be appreciated.

-Stove

[Zeroth]

Well, scope, or namespaces as they are called in some languages, really come into their power in a language that handles memory for you. They also make sense as a mini-way to organize code, make it more readable. Its not a bad practice, and neither is it good. Its all in how you use it. /pragmatic view

[md]

I would say it can be good, but re-using variable names like you do in your example is always bad.

If you have multiple scopes with an integer i then that's fine. If some scopes have i as a class then it can get confusing.

[btiffin]

This is an awesome computer science question. And I could simply ditto Zeroth, but I'm old and like to ramble.

Two of the languages that paid my bills growing up, polyForth and COBOL, are designed around the global namespace. Locals are possible, but require work. Global names in large systems require a fair sized piece of discipline. In COBOL, names are usually prefixed or suffixed (mnemonic source code namespace in that case). polyFORTH is blessed with a highly interactive console, and ease of use of LOCATE and REF (cross reference) meant that we could build a 100,000 word system and didn't really have to worry too too much about being able to find the difference between MLR, mlr, @mlr, @MLR, +MLR, +mlr and the forty or so other mechanized line record handling words. And to encapsulate meaning to "READ", we had hundreds of similar named words, some in french, italian, latin ... just because we kept bumping into the fact that words that conveyed meaning had already been used by another programmer on the team. Without LOCATE and REF we would have drowned in unmanageable details.

And for a history lesson ... Forth back then only had the first three letters and the length of the word saved in the dictionary. COMPILER and COMPUTER would be equivalent. When we got onto the Vaxen, we cranked the dictionary to a full 32 characters - ahh...

Global namespaces scare some comp-sci professors, but in reality, tons of successful systems have been built around this paradigm. Humans are pretty smart and can succeed in areas where the "book" may predict failure. Lack of said discipline can also sink systems built on the most powerful tools available. (I still cringe at Booch/Rumbaugh cloud diagrams for Object systems, having never seen a large scale project succeed when based (and relying) on this paradigm. Your mileage may vary.).

Skip ahead to today and my new favourite. REBOL. REBOL is funky. Namespaces are more conceptually "contexts". In the REBOL context, the word COPY is a function that will make copies of datatypes. While parsing, the PARSE dialect uses COPY as an action verb to capture results of pattern matching. Relative Expression Based is where REBOL gets its name from. Function templates have a /local refinement but that sets up a different binding, not some name mangling that allows a "normal" link loader to get its job done.

Ok, getting to the end of the ramble ...

Local scope is great if properly used to apply meaning to conceptual details. i and n are good examples of "meaning" stemming from math class. But I'll also say I cringe a bit when a see float i, j;, that breaks the implied meaning and simply looks like a programmer that lazed out on some typing. Having seen systems with a huge number of functional words, it is nice when the conceptual meaning of something like "index" is localized to the task at hand and doesn't require a source code pageflip to find "what" is being indexed.

In my humble opinion, local scopes are good practice but will not magically make for good programs. Locals don't kill programs, people kill programs. A long winded semi dittoing of what md said.

Cheers

[wtd]

Use of locals is all about simplicity. You could use globals, but then you have more to keep track of when you're looking for the source of errors.

[Stove]

@ Zeroth

I never really thought about it terms of memory management. I use the .net and the like almost exclusively, so I'll definitely take that into consideration.

@ md

Yeah, that was just for example .

@ btiffin

One global namespace? That'd be kinda interesting, but would be pretty annoying, at least for me. A completely different paradigm than what I'm currently used to. Plus as you already said, You'd have to be pretty creative with your variable names.

@wtd

I've actually never used a global variable in any of my programs. Or at least created a variable with the explicit purpose of it being globally accessible.

[btiffin]

Stove; Kids now-a-days. Spoilt.

Oh and get off the .net It's like crack. It'll ruin your life and the lives of everyone you love.

<kidding>

or is he? It's too bad, but Microsoft does not really foster "best of" programming practise. They foster "best for" programming, "best for ... Microsoft" that is. Better to leave them behind, like you should any overly greedy and self-absorbed "friend". On the other hand, there are a lot of people that will pay a lot of money to be Microsoft's friend. So it can be lucrative ... like crack dealing.

Cheers