Code Neatness

[Andrew Drummond]

Try looking up Scope and Span in 'Code Complete'. Having a lot of distance between the variable declaration and its last usage technically increases the complexity of the code. It also decreases the readability. Having a large span/scope increases the chances of misuse of a variable, and therefore bugs. Keeping a variables scope down to a mimimum also relates to good practises like information hiding. You were wrong. It may seem more readable to you because that is what you are used to. Try programming with reduced span/scope for a few days, you will soon switch over. regards, Andrew

[T Mac Oz]

Mark Salsbery wrote:

I'm referring to taking advantage of the scoping of variables within functions in C++.

I think Ri addresses this (italics added by me):

Ri Qen-Sin wrote:

my style is to declare it as close to the beginning as possible while keeping all the local variables deifnitions in the most local scope.

So, if I'm interpreting this correctly, Ri groups the declaration of (new) variables used within a block at the beginning of that block, taking advantage of block scoping. On the other hand, Ri's orginal advice:

Ri Qen-Sin wrote:

start by consolidating some of his variable declarations to the beginning of the program

in isolation sounds like a very simplistic/outdated approach but might well make sense in the context of the code he was commenting on in the first place:

Ri Qen-Sin wrote:

which was consisted of only a main(…) function/method/entry point and a lot of improperly formatted code

Ri, I think this should be a valuable lesson for you: By all means, recommend that scrappy looking code be cleaned up & formatted but never give coding style advice in a public forum! Leave that up to the individual or you open yourself up for a world of pain...X| At the very least, if you must give code style advice, be certain to qualify it with "it's my personal preference to..." :)

T-Mac-Oz

[Arun Philip]

T-Mac-Oz wrote:

The original concept of Hungarian Notation was actually quite different from M$s butchery of it. I forget the actual words used to define the concept but the prefix was really meant to indicate the usage of the variable, not its data-type. E.g.

I recall reading an example that used a prefix 'c' to signify a count rather than 'i' for integer. So, the way it was intended to be used was: Int32 cRows; But people started using it as: Int32 iRows; // the count of rows is an integer, so, ah, I'll prefix it with i Although the more readable way would be to declare it as: Int32 rowCount; ~ Arun

[Paul Watson]

I used to do that (all huddled at the top) but now I declare as close to first-use as possible. Functions/methods shouldn't be so large/complicated that you need to huddle all variables at the top to make it readable.

regards, Paul Watson Ireland & South Africa

Fernando A. Gomez F. wrote:

At least he achieved immortality for a few years.

[Michael Haines]

I used to be "top of the block" declarer, that is, until I started to do more code review/maintenance. Now I wish the declares were all JIT. The REAL messy code problem is: Long code lines requiring horizontal scrolling. MH

[Mike Devenney]

On topic: Declare them as you need them. Off topic: Christian, that's possibly the funniest signature I've ever seen! :laugh:

Mike Devenney

[Ed Poore]

Wider monitor :rolleyes:

[Rick Shaub]

According to Scott Meyers, author of "Effective C++: 55 Specific Ways to Improve Your Programs and Designs" you should "Postpone variable definitions as long as possible" (p 113) He actually dedicates a complete chapter to the subject. The reasoning for posponing declarations is to avoid incurring unnecessary construction overhead. This mostly applies to functions that have branching that may prevent all code segments from being executed. I personally don't think that declaring variables in the code body contributes to or against readability.

[Michael Haines]

I am already using two monitors, so I am talking about REALLY long lines! :-D

[Frank W Wu]

The good practice is “Lazy Evaluation” – declaring as late as possible, and keep it within the scope only (hide it from outside). If you declare everything in the beginning of a function, you probably will forget to clean up the residual data before using it.

[Mike Dimmick]

Ravi Bhavnani wrote:

can't imagine I'd use one that didn't do that as part of standard optimization! Code hoisting has been around for decades and is pretty mature technology.

If the object has a constructor or destructor, the C++ standard requires that it is destroyed and a new object created on every iteration of the loop. But the compiler will construct the object in the same space each time.

DoEvents: Generating unexpected recursion since 1991

[z974647]

Here's a free site for cleaning up your SQL...just paste your code in it and hit the Prettify! button.... www.simple-talk.com/prettifier/

[Mike Dimmick]

Larry Osterman and others have documented that Hungarian Notation originated with Charles Simonyi in the apps group at Microsoft. It was the systems group that bastardized it to the form we see in Windows where the syntactic type, which can be checked by the compiler, is encoded in the name. (Someone from the systems group, who was blamed by Larry for the error, here[^] claims that it was the people who authored the documentation that screwed it up!) I think true Hungarian would have called your variables iOuter and iInner, where the i prefix indicates an index into an array, but of course the problem is that i has been overloaded in "Systems Hungarian" (or "Anti-Hungarian" as Rick Schaut calls it[^]) to mean 'int'.

DoEvents: Generating unexpected recursion since 1991

[Mike Dimmick]

Funnily enough I was looking at JIT output last night! How do I see what the JIT compiled, anyway?[^]

DoEvents: Generating unexpected recursion since 1991

[Lowell Boggs]

Declaring variables at the top of a function or program is bad idea. Consider the following:

void function()
{
int i;

  // use 'i' for purpose 1
  ...
  // use 'i' for purpose 2
  ...
  // use 'i' for purpose 3
  ...

  if(i == 14)
  {
    // crash the program
  }

}

At the bottom of the function, 'i' is the accidental work product of the last place that it was used. Suppose this function is 200 lines long? Is the user supposed to hand examine every single place a variable is modified in order to understand what its value is currently being used for? Instead, declare variables as close to the point that they are actually used and make sure that they go out of scope as quickly after that as possible to reduce confusion to later maintainers. Confusion is the root of all evil in s/w. Lowell used.

[El Corazon]

mhaines@1amadeus.com wrote:

I am already using two monitors, so I am talking about REALLY long lines!

so use two 30" monitors.... come on, use it as an excuse... you know you want them!

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

[El Corazon]

Ri Qen-Sin wrote:

I'm trying to seek agreement… so was I right when I said so?

yes, and no. If your code loops or branches, it matters where you declare your variables. For instance declaring all your variables up front pulls a lot of space off the stack or heap, creates overhead, and if you branch or exit early, you have created unnecessary overhead. If your code branches with an if or a switch, you never want to incur the overhead associated with unused branches. on the other side, declaring a variable inside of a loop means that this variable will be allocated and deallocated often. By moving the declaration outside of the loop, your cost is significantly less performance wise. BUT! The rule above still applies. You do not have to move it to the front of the function, though you can if you don't branch or exit early.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

[El Corazon]

Steve Echols wrote:

but if you try that in C++ you get a duplicate definition error on i.

That was just MS. Other compilers don't have that problem, though as mentioned MS can fix it with an option.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

[El Corazon]

Shog9 wrote:

Good grief. Do people not know how to generate assembler output from their compilers anymore?

No, most do not.... :sigh: :sigh:

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

[Ravi Bhavnani]

Code hoisting applies to code that can be hoisted. :) /ravi

My new year resolution: 2048 x 1536 Home | Music | Articles | Freeware ravib(at)ravib(dot)com