28

In Visual Basic (I've seen this in 2005 and 2008) when you hit a breakpoint or single step and the code on this line stretches past the end of the screen, the window automatically scrolls right so that as much of the line is visible as possible. I can see why this might be useful, but I find it a little distracting as the screen appears to jump around a lot while I'm trying to debug. Furthermore, the context of the code can be chopped off, so if there are a few nested loops, ifs etc then the rest of the code can be entirely off-screen which is frustrating.

Does anyone know how to disable this behavior?

Jaymin
  • 2,879
  • 3
  • 19
  • 35
Sean
  • 1,698
  • 2
  • 16
  • 22

3 Answers3

1

Not an exact solution, but you can bump the lines back over by clicking the thin vertical code-folding/outlining line next to the line numbers. Slightly better than going down to the scrollbar. This is in VS 2015.

blevotroid
  • 41
  • 5
0

You can hold the ctrl button and scroll down to zoom out to be able to see more of the document while you are in the code view. Doing this makes the font size smaller.

Nathaniel Ford
  • 20,545
  • 20
  • 91
  • 102
0

You should just extremely avoid writing code that goes off the edge of the screen.

Not only does this make debugging much harder, but when other people try and read your code it is very difficult and frustrating.

You shouldn't be nesting deep into any loops, but instead you should be negating your conditions and using breaks/returns/escapes.

So instead of this:

if (condition) {
   //stuff
   if (anotherCondition) {
      //more stuff
      if (yetanotherCondition) {
          //starting to get to the edge of the screen soon...
      }
    }
}

Instead you should do this:

if (!condition) return;
//do stuff

if (!anotherCondition) return;
//more stuff

if (!yetAnotherCondition) return;
//so much more room to work with!

Furthermore things like linq statements / expressions should be broken into chunks to be readable

rather then:

var foo = MyList.select(val => val.isThing() && val.isCorrect && val.hasConditions() && val.things.Any(thing => thing.isCorrect())).orderBy(val => val.property).First();

Which causes your problem, instead do it like this:

var foo = MyList.select(val => 
    val.isThing() 
    && val.isCorrect
    && val.hasConditions() 
    && val.things.Any(thing => 
        thing.isCorrect()
        )
    )
    .OrderBy(val => val.property)
    .First();
  • 2
    «You should just extremely avoid writing code that goes off the edge of the screen.» «Not only does this make debugging much harder, but when other people try and read your code it is very difficult and frustrating.» This is your personal opinion, not a rule, as valid and other different opinions. For example I find read your code very difficult to read and very frustrating the code splitted on more lines. This practice, my personal opinion, should be used in very few special cases. – Angelo Mascaro May 07 '19 at 12:59
  • 1
    So please, when it comes to personal opinion avoid using SHOULD, HAVE TO and MUST because this could be confusing and who begins programming could mistake it for a programming rule. – Angelo Mascaro May 07 '19 at 12:59
  • 1
    Using meaningful object names can result in long lines. Also it's often someone else's code that is being debugged. – Paul McCarthy Jun 21 '19 at 14:53
  • Say I want to split the window so that I can see multiple files in the same time. Screen real-estate is important and always limited. No matter how good you are at keeping the line length down this can happen. Just telling people to deal with unwanted behavior is not helpful. – Morgan Apr 22 '20 at 08:36