«

BartC wrote:

> But what happens when the code defines a variable two pages into a function,
> but you happen to be reading some code using that same variable four pages
> into the function! Where do you go to find the definition? At the start of a
> function is usually a good place! You don't always know that a variable is
> only used once.

Functions should NEVER be 5 pages long.

> And with blocks having their own scope (?) the same name can be used more
> than once with different definitions; even more confusing.

Wow, I have a solution for that one! Don't reuse variable names
within a function.

And let me blow your mind, within an inner block, you can "shadow"
definitions from outer blocks (declare a new variable with the same
name). And that's bad practice too.

These are QoP (Quality of Programmer) issues.

If one is actively trying to write obfuscated code, nothing
can be done to educate them, except for the clue bat.

cf. also http://www.ioccc.org/

On Sun, 2012-06-17, BartC wrote:
>
>
> "Jorgen Grahn" <grahn+> wrote in message
> news:slrnjtr16f.rk7.grahn+. ..
>> On Thu, 2012-06-14, Varun Tewari wrote:
>>> Its simply not stupid, its a simple fact the C++/Java allow
>>> decalaration anywhere in the code, but C wants them the first thing
>>> when you code. That's all
>>
>> You could say that "declarations only at the start of block" was a
>> stupid design ... I'm very happy this got changed, and it should
>> probably have happened earlier, when 'const' and such things were
>> introduced.
>>
>> Now all that remains is to educate the users. Most code I read
>> doesn't even use the C89 "at the start of block" rule. It lumps all
>> the variables at the start of the function -- even those that are only
>> used and only make sense inside some loop, two pages down ...
>
> But what happens when the code defines a variable two pages into a function,
> but you happen to be reading some code using that same variable four pages
> into the function!

Then it's refactoring time. But IME the usual case is that a few
variables need function scope and the rest need only a quite narrow
scope down inside some loop or if ... else.

I'm not a fan of huge functions (who is?) but with proper variable
scope (and the things that follow: being able to apply 'const' and
initialize them at the declaration) you can make them much more
pleasant to work with. Breaking down the huge function into smaller
ones is a much bigger effort/risk, especially when maintaining old
code.

/Jorgen

PS. I also agree with what some other posters wrote.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Mon, 2012-06-18, Joe Pfeiffer wrote:
> Jorgen Grahn <grahn+> writes:
>
>> On Thu, 2012-06-14, Varun Tewari wrote:
>>> Its simply not stupid, its a simple fact the C++/Java allow
>>> decalaration anywhere in the code, but C wants them the first thing
>>> when you code. That's all
>>
>> You could say that "declarations only at the start of block" was a
>> stupid design ... I'm very happy this got changed, and it should
>> probably have happened earlier, when 'const' and such things were
>> introduced.
>>
>> Now all that remains is to educate the users. Most code I read
>> doesn't even use the C89 "at the start of block" rule. It lumps all
>> the variables at the start of the function -- even those that are only
>> used and only make sense inside some loop, two pages down ...
>>
>> /Jorgen
>
> It may be a sign of my age and when I learned C, but I really like
> defining all my variables, and then using them.

Might be a generation thing ... I learned C around 1992. But I've also
used C++ heavily in recent years; I guess that's where I learned not
to introduce variables until I need them.

> If defining a variable
> at the start of a block other than the start of the function (and not as
> the iterator of a for loop) makes sense, it's a really good clue my
> function is too long.
>
> If my variables are first used two pages down, the function is almost
> certainly too long. If "two pages down" is even a relevant phrase, my
> function is almost certainly too long.

Yes, of course. But if you're working in teams, it's not always your
fault the function looks like this, and "right now" may not be the
right time to break it down.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

"James Kuyper" <> wrote in message
news:jrkm86$43k$...
> On 06/17/2012 06:47 AM, BartC wrote:
>> "Jorgen Grahn" <grahn+> wrote in message
>> news:slrnjtr16f.rk7.grahn+. ..
> ...
>>> Now all that remains is to educate the users. Most code I read
>>> doesn't even use the C89 "at the start of block" rule. It lumps all
>>> the variables at the start of the function -- even those that are only
>>> used and only make sense inside some loop, two pages down ...
>>
>> But what happens when the code defines a variable two pages into a
>> function,
>> but you happen to be reading some code using that same variable four
>> pages
>> into the function! Where do you go to find the definition?
>
> Backwards from the point of use, until I find a definition. It's the
> only safe direction to look, and I'll get to the definition a lot
> quicker that way if it's closer to the point of use.

That means looking at every line of code before that point, for a variable
name that be similar to many others. Declarations at the start of a function
are easier for low-tech editors (even with one that can't switch quickly
between two locations, probably you can run two instances of it).

>
>> ... At the start of a
>> function is usually a good place! You don't always know that a variable
>> is
>> only used once.
>
> I find it quite easy to determine that; usually during design,
> definitely by the time I've finished coding. The future reader doesn't
> need to know this in order to perform his search, just search backwards
> from the point of use.

Look at this example from the middle of a function (from Python sources):

mz = z->ob_type->tp_as_number;

Applying a local declaration, and let's say you're lucky and this the first
use of mz you see, it might look like:

PyNumberMethods mz = z->ob_type->tp_as_number;

That's great; we know what mz is. Except that's not the full picture. The mz
variable is actually declared like this at the top of the function:

PyNumberMethods *mv, *mw, *mz;

Now we know there are three related variables, and there aren't any called
mx or my. Which can give an extra dimension to our knowledge (there are
parameters v, w, z, and mv, mw, and mz presumably correspond to these). It
also tells us that mx and my are available for other purposes.

With a smart IDE, and careful perusal, you would become aware of all this
anyway. But burying the details about local variables in a dozen assorted
places just obfuscates things and life a bit more difficult.

I was going to say that making in-place declarations makes things easier to
write, harder to read, but then imagine having to clutter your code with
three lots 'PyNumberMethods' instead of one!

--
Bartc

On 06/18/2012 07:34 AM, BartC wrote:
>
>
> "James Kuyper" <> wrote in message
> news:jrkm86$43k$...
>> On 06/17/2012 06:47 AM, BartC wrote:
>>> "Jorgen Grahn" <grahn+> wrote in message
>>> news:slrnjtr16f.rk7.grahn+. ..
....
>>> But what happens when the code defines a variable two pages into a
>>> function,
>>> but you happen to be reading some code using that same variable four
>>> pages
>>> into the function! Where do you go to find the definition?

As others have pointed out, this indicates that your function is
probably too long to be well-understood.

>> Backwards from the point of use, until I find a definition. It's the
>> only safe direction to look, and I'll get to the definition a lot
>> quicker that way if it's closer to the point of use.
>
> That means looking at every line of code before that point,

I suppose so, but it's the backward-search feature of my text editor
that does the looking, it's not at all tedious for me.

> ... for a variable
> name that be similar to many others.

Similarity doesn't matter to the backwards-search feature. Just cut and
paste the variable name into the search pattern, and you'll guarantee
it's the one you're looking for. If you can't find it, there's been a
misspelling. Choose the "whole words only" option (if available in your
editor), and you won't have to worry about false positives from other
identifiers whose names contain that variable's name.

> ... Declarations at the start of a function
> are easier for low-tech editors (even with one that can't switch quickly
> between two locations, probably you can run two instances of it).

My favorite editor (vi) is fairly low tech, and available just about
everywhere I need it; you may be less lucky. I don't think anyone should
settle for using a editor on a modern (in this case, modern means post
1980's) system that's not capable of backwards search.

Note: I would not recommend vi for new users; the learning curve is
quite steep, GUI editors are much easier to use, particularly if built
into an IDE. However, I've already learned it, and once you've learned
them, the power of vi's commands can be quite addictive. I've never seen
a GUI editor (other than gvim, which doesn't really count) where I could
do all (or even most) of the things I can do with vi commands.

>>> ... At the start of a
>>> function is usually a good place! You don't always know that a variable
>>> is
>>> only used once.
>>
>> I find it quite easy to determine that; usually during design,
>> definitely by the time I've finished coding. The future reader doesn't
>> need to know this in order to perform his search, just search backwards
>> from the point of use.
>
> Look at this example from the middle of a function (from Python sources):
>
> mz = z->ob_type->tp_as_number;
>
> Applying a local declaration, and let's say you're lucky and this the first
> use of mz you see, it might look like:
>
> PyNumberMethods mz = z->ob_type->tp_as_number;
>
> That's great; we know what mz is. Except that's not the full picture. The mz
> variable is actually declared like this at the top of the function:
>
> PyNumberMethods *mv, *mw, *mz;
>
> Now we know there are three related variables, and there aren't any called
> mx or my. Which can give an extra dimension to our knowledge (there are
> parameters v, w, z, and mv, mw, and mz presumably correspond to these). It
> also tells us that mx and my are available for other purposes.
>
> With a smart IDE, and careful perusal, you would become aware of all this
> anyway. But burying the details about local variables in a dozen assorted
> places just obfuscates things and life a bit more difficult.

My experience is the opposite. Putting declarations closer to the point
of use highlights them, it doesn't bury them in a huge pile of other
variables. Knowing that a given variable will be used only in one
particular inner scope makes it easier to understand it's meaning, not
harder.

Of course, the best way to document the meaning of a variable is with a
comment on the line where it's declared, or if there's not enough room
for that, on the previous or following line (it doesn't matter which,
but it does matter that the choice of 'previous' or 'following' be
consistent throughout a given body of code).

> I was going to say that making in-place declarations makes things easier to
> write, harder to read, but then imagine having to clutter your code with
> three lots 'PyNumberMethods' instead of one!

I often will do that even if they were all declared at the top of the
same block; only if they were all closely related variables of the same
type with short names would I merge their declarations like that. And if
those conditions are met, I'd carefully consider whether they should be
elements of a single array, rather than separate variables.

Using multiple declarations also often allows enough room for a short
descriptive comment on the declaration line.
--
James Kuyper

On Jun 18, 1:18*pm, James Kuyper <jameskuy...@verizon.net> wrote:
> I've never seen a GUI editor (other than gvim, which doesn't really count)
> where I could do all (or even most) of the things I can do with vi commands.

*cough*

M-x all-hail-emacs

On Mon, 18 Jun 2012 08:18:02 -0400, James Kuyper
<> wrote:

>My favorite editor (vi) is fairly low tech, and available just about
>everywhere I need it; you may be less lucky. I don't think anyone should
>settle for using a editor on a modern (in this case, modern means post
>1980's) system that's not capable of backwards search.
>
>Note: I would not recommend vi for new users; the learning curve is
>quite steep, GUI editors are much easier to use, particularly if built
>into an IDE. However, I've already learned it, and once you've learned
>them, the power of vi's commands can be quite addictive. I've never seen
>a GUI editor (other than gvim, which doesn't really count) where I could
>do all (or even most) of the things I can do with vi commands.

As a long-time vi user (from 'way back in the dark ages) and current
gvim-er, I agree of course. However, Notepad++ (aka npp) is FOSS and
also worth having around. It's pretty decent, as editors go. The visual
diff is quite handy. Windows only, though. http://notepad-plus-plus.org/

And, oh yeah, it will do a backwards search...

--
Rich Webb Norfolk, VA

On 06/18/2012 08:42 AM, gwowen wrote:
> On Jun 18, 1:18�pm, James Kuyper <jameskuy...@verizon.net> wrote:
>> I've never seen a GUI editor (other than gvim, which doesn't really count)
>> where I could do all (or even most) of the things I can do with vi commands.
>
> *cough*
>
> M-x all-hail-emacs

You're right, of course, emacs is a GUI with powerful commands, and I
forgot about it.
I once spent an entire year using it as my main editor, partly because
it was one of the few available on the platform I was using at the time,
and vi wasn't, but also to give myself a decent chance to get used to
it. I never did. I no longer remember the details, but I remember having
a great deal of trouble remembering the syntax for the emacs equivalent
of vi's global search-and-replace:

g/pattern/s/original/replacement/g

Whatever the actual syntax was, I found it counterintuitive (not that
I'd claim that the vi syntax is obvious - but I'm used to vi). What was
worse is that I remember having even more trouble locating help
explaining that syntax, and that's a problem with help system, not with
my memory.
--
James Kuyper

On Jun 18, 9:06*am, Rich Webb <bbew...@mapson.nozirev.ten> wrote:
> On Mon, 18 Jun 2012 08:18:02 -0400, James Kuyper
>
> <jameskuy...@verizon.net> wrote:
> >My favorite editor (vi) is fairly low tech, and available just about
> >everywhere I need it; you may be less lucky. I don't think anyone should
> >settle for using a editor on a modern (in this case, modern means post
> >1980's) system that's not capable of backwards search.
>
> >Note: I would not recommend vi for new users; the learning curve is
> >quite steep, GUI editors are much easier to use, particularly if built
> >into an IDE. However, I've already learned it, and once you've learned
> >them, the power of vi's commands can be quite addictive. I've never seen
> >a GUI editor (other than gvim, which doesn't really count) where I could
> >do all (or even most) of the things I can do with vi commands.
>
> As a long-time vi user (from 'way back in the dark ages) and current
> gvim-er, I agree of course. However, Notepad++ (aka npp) is FOSS and
> also worth having around. It's pretty decent, as editors go. The visual
> diff is quite handy. Windows only, though.http://notepad-plus-plus.org/

And thank the good people that created the vi plugin for Visual
Studio. It makes development in the IDE tolerable.

On 2012-06-17, BartC <> wrote:
>
> But what happens when the code defines a variable two pages into a function,
> but you happen to be reading some code using that same variable four pages
> into the function! Where do you go to find the definition? At the start of a
> function is usually a good place! You don't always know that a variable is
> only used once.
>
> And with blocks having their own scope (?) the same name can be used more
> than once with different definitions; even more confusing.

That's precisely the whole point: if you declare a variable inside
a block you DO KNOW that it is only used there and if the identifier
appears elsewhere it must be referring to something else. There
are many times you want a local variable for a short amount of time
and that's it. If you declare the variable in the appropriate
block you don't need to mentally keep track of the variable either
before or after that block. Fewer variables to keep track of
generally means fewer corner cases, fewer uninitialised or outdated
variables, and fewer dangling pointers, whether they are still
relevant or not.

One fairly common idiom that comes to mind would be along the lines of:

if (some_condition()) {
int retval = operation(object);
free(object);
return retval;
}

Why have an extra variable hanging around a whole function for
something so trivial? What is more, a variable like that is easily
identified by the compiler as being short lived and can be optimised
as such - put into a register or whatever. It knows that it doesn't
need to preserve its value because you happened to re-use the same
variable for something else later in the function.

--
Andrew Smallshaw