Tuesday, May 8, 2012

Visual Studio: Is it getting worse as time goes on?

I took a hiatus from Windows programming for a few years, working on Macs in the slowly improving but still infuriating Xcode.  I harked back to Visual Studio as so much better, a slick IDE that set the standard year after year.

What a jarring dose of reality when I dove into Visual Studio 2010 a couple years ago.  It's plagued by 20-year-old defects that were annoying then but unacceptable and ridiculous now.  Microsoft also introduced embarrassing UI regressions that cripple the app in new ways.

First, the good.  The UI's organization is pretty decent, much better than Xcode's:


I started taking notes about the bad.  Here they are.
  • The scroll wheel doesn't work in the pane that the cursor is hovering over.  You have to click everywhere to activate every pane on the screen.  Why should I have to click in the variables pane just to look at a variable?
  • A similar focus problem: The drop-down function list retains focus after you select a function, so if you try to scroll your document with the wheel, you're instead scrolling the values inside the (now collapsed) function drop-down.
  • Massive color problems make text invisible in many parts of the interface.

  • Project-property dialog is still not resizable, and yet it's full of typically long strings and settings.  This retardation plagued Visual C++ two decades ago.  Inexcusable.
  • The drop-down function list still doesn't list all functions in the file; it's limited to the object in which the insertion point is sitting .  Or you have to select an object scope from the left drop-down, going through them one at a time, if you don't know which one contains the function you're looking for.  Why isn't there an "entire file" scope offered?  And why does it continually pick "global scope" by default, when that scope is empty and there's only one scope defined in the file?
  • Doesn't do syntax completion on symbols.  You have to type out every class and variable name, every time.
  • Syntax completion doesn't work if you position the cursor after a period or arrow in member notation and start typing.  You have to erase the last character in the symbol and retype it to restart the syntax completion.
  • printf statements don't write to the Output window!  And the clumsy alternative, OutputDebugString, doesn't take printf-style formatting and insists on wide characters.  OutputDebugStringA doesn't require wide characters, but was essentially undocumented; someone in the comments claims it's now documented.
  • Paths are recorded as absolute, and not relative, when when you navigate to them to set project properties such as the working directory for debugging.  So of course the project is broken for anyone trying to use it on a different computer.
  • If you right-click on a file in the left pane and view its properties, you can't see its path.  You have to go two levels deep into the View menu to bring up a whole separate Properties window, which finally shows the path.
  • Matching braces or parentheses are only highlighted when you first type them, and then never again.  They aren't highlighted when the insertion point crosses them.
  • There's a "Go to header file" function, but no "Go to implementation file" counterpart.  Also, "Go to header" doesn't appear to work if the header's extension is "hpp".
  • There's no way to reveal the file you're editing in Explorer.  You can't see the path of the file anywhere either, even if you hunt through the view menu and show the obscure "Properties window".  The Properties window goes BLANK if you put the cursor in the editor.
  • Context menu won't let you search for definitions of symbols in that appear in comments.
  • Error lines aren't highlighted in code when you double-click an error in the output or error list.  Instead, a tiny blue sliver appears in the gutter next to the line, which you have to hunt for.  The color settings for "compiler error" are ignored, and you can't set the background color there anyway.
  • The drop-down function list in the editor will frequently behave as though the function is missing from the source file, and instead jump to the header file; despite the fact that the function IS implemented and compiles just fine.
  • The option to show line numbers is not in the View menu.  It's buried under Tools / Options / Text Editor.
  • When you disable a breakpoint, it simply disappears from the left gutter, and to re-enable it you have to pull up the list of all breakpoints and hunt for it.
  • If you have two vertical tab groups open and select "Close all but this" on one of the tabs in ONE of the groups, it closes the tabs in the other group too.
  • If you press F12 while debugging, it interrupts the program you're debugging, and there's no way to stop this.  F12 is not documented as being mapped anywhere in the VS UI.  So if your application uses F12 for something and you need to debug it, you're screwed. (documented: http://connect.microsoft.com/VisualStudio/feedback/details/106201/f12-stops-execution-while-debugging-and-sometimes-kills-windows)
  • The menu option "Stop outlining" only works on the current file, so you have to turn this annoying "feature" off again and again.  WTF.
  • Double-clicking on whitespace to select it doesn't work if the whitespace is only one character (like a tab).



2 comments:

  1. Your lack of understanding/experience with Windows:
    The scroll wheel works on the pane that has focus, I'd consider anything else a bug
    printf statements go to standard output. The Output window is for _debugging_ output, which is a 100% separate thing.
    OutputDebugStringA is actually the default unless you configure it otherwise, and it is just as documented as the wide version.
    Matching braces and parenthesis are highlighted when the cursor is to their right, and there is a key combination as well.
    To reveal the file path, right click the tab at the top with the filename and use either "copy file path" or "open containing folder".

    Comments:
    That's not the standard color scheme, but if it's a selectable default, then the invisible text is indeed inexcusable.
    I agree that absolute paths are irritating, but they can be replaced with relative paths manually.
    Go to Header was a problem, has been replaced in newer versions with "go to declaration" which works.
    Disabled breakpoints show as a hollow circle, it may be your color scheme again.

    ReplyDelete
    Replies
    1. Nice try, but to a professional Windows developer with decades of experience at several major firms your "lack of understanding with Windows" assertion is ludicrous. I started with VC when there were still separate 16- and 32-bit versions that didn't even have feature parity, in addition to being tech lead on the largest-ever VC project to date in 1993 (and that's according to Microsoft). And on through VS 6.

      Having to find some non-volatile area to click on within a pane before you can scroll it is cumbersome and pointless. And then I have to go back and click on the previous pane to resume what I was doing? Asinine.

      Funny how any other debugging system sends printf to the debugging console window. It's not that tough. And no, OutputDebugStringA wasn't documented at the time, or I wouldn't have said otherwise.

      Using a key combination to highlight matching parentheses and braces doesn't make sense, so why would you even scour the documentation or menus for one? When would you even use it? Talk about defeating the convenience purpose of the entire feature.

      Right-clicking on a tab to reveal a file's path is undiscoverable UI. Why would you do that? That's Apple-style obscurity. It would be fine as an auxiliary method, but as the primary method it's laughably bad.

      The Windows color preferences let you set up any scheme you want. You can go through every UI element and set its color, and the preview shows you the result. Obviously you're not going to set up a scheme in which text becomes invisible in the UI; that's the whole point of the preview. Microsoft is overriding SOME of the system-wide color choices the user has made here with hard-coded ones, which can and do conflict with the system-wide settings and result in invisible text. That failure represents a fundamental ignorance of how the Windows UI has worked for over two decades.

      Delete