Join Declaration and Assignment or not to join...That is the question

There are 2 school of thoughts on debugging. One says declare your variable first, then assign...for easier debugging.

int myInt;
myInt = GetSomething();

or there is a school of thought that says that's just not clean, just do this:

int myInt = GetSomething();

I don't understand how the first helps. Because if I put a debug point over myInt in either case, it's going to give me a value that I can check anyway.

So can someone tell me in detail when debugging, how the first approach is worth putting 2 lines in? I know some people swear by it.

Obviously there are times you must do the first, because you may need to do more than just a one-time set such as set an object's properties.开发者_开发问答 But outside that, a one-time call to set a variable is what I'm specifically talking about here.

---

The 2 lines, to me, only makes sense to inspect return values, i.e.

int myInt = GetSomething();
return myInt; <===== breakpoint here

(instead of return GetSomething();)

Other than that, a breakpoint / watch should work fine. In a release build you should find that the extra variable has been eliminated by the compiler. Until it is assigned, the value is meaningless, so what purpose having an additional line to look at? Just use inline initialization (this also allows var if you so choose):

int myInt = GetSomething();

---

I have never heard of that school of that. More lines of code equals more lines to debug, more lines to maintain and more lines to step through.

This is my guiding principle always: Make it correct, make it clear, make it concise, make it fast. In that order.

int myInt;
myInt = GetSomething();

is certainly correct and clear. But

int myInt = GetSomething();

is more concise. Fastness is irrelevant here. Therefore, I favor the latter over the former. And it's not close.

There is one place where breaking a line into components can make debugging easier.

int myInt = GetSomething();
return myInt;

is better when walking through a debugger than

return GetSomething();

because in the latter I can not easily inspect the return value whereas with the former I can.

---

I've never heard that before. If you set a breakpoint on the first line, the debugger will automatically move it to the next line when you execute since there is nothing to debug on the first.

If people are claiming what you say, I suspect they're thinking of scenarios like this:

int i = SomeProperty.GetSomeValue().DoSomething();

Here it's "harder" to debug because more than one thing is called on the one line.

---

Late to the conversation but I have heard of that school of thought. Doesn't make sense for a single var but it does as exposition to a big function.

BIG_FUNCTION = function () {
    // variables
    var isThis = true,        // let me tell you about isThis
        thatThing = 'that',   // thatThing does that thing
        anotherVariable = 0;  // pretend it's specifically named

    // functions
    var doTheThing, // here's where I tell you what to expect
        doFooBar,   // and I'll explain each one
        doBlargo;   // so that you can get a feel for the big function 

    /* Function Definitions */
    doTheThing = function(the) {
       // ... etc
    };
})();