A few months ago, some of you took a survey on C++ developer activities, the results of which will be used to hone in on which areas to improve for the next release of Visual Studio. I wanted to take some time to share with you the preliminary results of the survey.
Without further ado, out of the 47 tasks included on the survey, here's what we found out! "Aggregate Score" is the composite score from all respondents. "Normalized Score" is adjusted by the number of respondents for which the activity is meaningful for them.
Survey says, normalized or not, these tasks are the most often performed by C++ developers. Hopefully none of these tasks being here are a surprise!
It's no surprise that every refactoring topic offered in the survey made it to the top of the pain points list. It is well-known that the lack of support for C++ refactoring is widely felt.
AH, BUT WHAT'S THIS?! Many of you are probably wondering which task made it to the top of the normalized list, and you should! Take a look for yourself:
Of the 54 (likely graphics) developers that had the opportunity to voice concerns over writing and compiling shader code, a whopping one-fifth of them said it was a pain point. Most of you (77% of you, in fact =P) probably saw that task and said "What the heck is shader code, I don't do that." Well, your graphics-developing colleagues do that, and it's a pain point for them J.
For those who love reading some of the "verbatims" we receive, here are a few "pain point verbatims" reflecting common themes. Note that since we asked specifically for pain points, we did not receive positive statements as we often do with more general "what else would you like to share" feedback questions:
For everyone who took the time to take this survey, thank you so much! The median time to complete the survey was 18 minutes; it was a very involved survey!
It so happens that the Visual C++ Team is exploring new refactoring tools (have you seen the new rename/refactor extension?). You can be the judge on its relation to these results.
Since jumping between header and source is such a common activity, do you think the next release could do something to address the current problem of VC++ failing to recognize either the header or the function as soon as something is changed?
E.g. "int foo(int bar)". In the source, change "int bar" to "char bar", and then try to jump to the header to make the same change, and you can't because it's no longer recognized.
Thanks for the feedback, Jonathan. This is excellent feedback. Have you submitted this as a bug to our Connect feedback site, connect.microsoft.com/VisualStudio
How about a rolling release of visual studio where the compiler and IDE are continually updated with micro patches as opposed to these bloated major CTP releases every so often?
>It so happens that the Visual C++ Team plans to do significant work on refactoring for the next release.
How significant? You don't seem to want to add a usability fix to the refactor UI: connect.microsoft.com/.../refactor-preview-reference-changes-dialog-needs-to-remember-its-size-and-have-a-better-default-size
I have the same pain point as Jonathan Potter while refactoring functions declared in a .h, and defined in a CPP.
My solution differs. I would prefer that a right click on a function brings up a "Redefine function" menu option. It would present the function return value, name and parameters in a dialog as follows:
You could edit the types or parameters names, add or delete a parameter, and then the IDE would update BOTH the .h and the .cpp. For extra points, you could then navigate around to all the references of the previous function definition.
IF thatsa pain point you have got the easy life.
Do the sensible. Find the decl. Edit it. Compile. Fix. Uno auto-magicalizing this will fail some of the time and eventually most of the time.
I'd like to point out that the editor feature of "Toggle Header / Code File (Ctrl+K,Ctrl+O)" does not work if the .cpp and .h files are in different directories.
In our case, we have various \src directories and a \h dir and the toggle doesn't work.
I don't know if this has been added to VS2013, but in 2012, right clicking on a .CPP file brings the context menu up with a "Go To Header File" option. Why is there no "Go to Source File" option when you right click in headers ? This would be quite helpful to me.
Also I think AndrewDovers solution is quite complex and clunky, I would just fix Intellisense to present you with options for Goto Declaration if the params/return value have been changed. That way you can jump to the declaration quickly to change it.
Also I would make improvements to Intellisense in general. Quite often it spends minutes at a time just processing headers when it thinks something's changed but it hasn't. Its extremely inefficient and slow when you compare it to Visual Assist for example.
I've always wanted to be able to have a split screen H/CPP view. I've been able to sort of do this with two tab groups, one with all H files and the other with all CPP files, but it's difficult to manage and I eventually always give up. It'd be really nice if it were automatic like the XAML/designer view where you open one tab and you just get both views automatically, or the ability to switch between via a menu item. Extra nice if you could right-click a definition in one to move the cursor to the declaration in the other or vice versa.
@jschroedl: I confirm that this is a known limitation. We currently look for the related file in the same folder and then through the INCLUDE paths. The likelihood of finding the header even if it's not in the same folder is higher because of the second lookup, but a cpp files in a different folder will never be found. We're investigating addressing this limitation for files part of the same project in a future version of VS.
@ All: Thanks for the good suggestions on how to improve the header/cpp editing experience. Keep them coming!
Visual C++ Team