Are there any tools for VS that allow developers to view code according to their style desires?
For instance, some developers like K&R style brackets while others like ANSI style.
The backing code file can be in whatever format it wants, but the viewed source needs to be in the developer style.
It can be done. You just have to set the indentation options in the Visual Studio options. Then when a developer loads a file, he can just select "Reformat File" from the Edit menu (I think it's in one of the advanced sub-menus) or go to the bottom of the file, remove the ending brace, and re-add it. The file will automatically be reformatted.
That said, this is a really bad idea. If you're using source control, then every time a developer checks out a file that was previously checked in by somebody who used a different formatting convention, that file is going to show as modified. So you'll have the potential for a lot of spurious checkins, and even if you somehow avoid the spurious checkins you have the problem that a developer might change one line of code, but a diff is going to show LOTS of changes because of all the formatting changes.
That's not the only problem. Let's say that a tester reports an error and a stack trace that says an exception occurred on line 263 of some module. You have to be sure to get the latest code from the source repository and keep it in the format that it was last compiled in. Otherwise, line 263 where the error was probably won't be line 263 in your editor.
Tell your developers to decide on ONE indentation style. Anything else is going to cause you no end of grief.
By the way, I gave this some serious thought a few years back and even wrote about it in Source Control and Formatting Standards. I thought it was a good idea provided I could build the tools to do the automatic conversion to canonical format. At the time, I didn't take into account the "where is line 263" problem. That one's a killer, and the tools to do the automatic conversion are no picnic, either. All in all, I decided that it's much easier and more reliable to just settle on a single style. It takes only a few days to get accustomed to an unfamiliar style.
Related
Ok, I'm experiencing a truly random bug and I cannot find any reason why this would happen. I have an application that I update that was first developed MANY years ago. I work on a sizable dev team whose sole responsibility is to manage this application and we've come to accept that the project is a bit of a "franken-code" project. We are but humble developers in a line of many generations of developers who've inherited this project. (This will be important to know later.)
There is a portion of our application that deep within the initialization process calls the following code:
string strPath = System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().CodeBase);
string strFile = strPath.Substring(6) + "\\" + FILE_NAME;
Here's the deal. My fellow team members, and myself, have been able to modify and build higher-level, UI and DB related sections of our solution for an eternity. I, nor anyone else, has modified the above code, or any code in the same code file (or project within the solution, for that matter.)
However, today while working in a completely different section of my application I began to get some really odd "Out of Memory" exception errors. I'm not sure if that relates to my problem but I felt it was worth mentioning that after rebooting my machine and reloading the VS solution, I'm now consistently getting the following exception when I attempt to run a debugger test, when the initialization process attempts to execute the above mentioned snippet of code:
Exception: A first chance exception of type 'System.ArgumentException' occurred in mscorlib.dll
Message: URI formats are not supported.
I've googled this error message and it looks like the original dev was simply doing this wrong. This seems to be a common error, but what baffles me is that this has never been a problem until, randomly, today.
I know this is an odd question, but is there a way to fix this without modifying this code. As I mentioned, this is a really complex application that often feels a bit cobbled together. Our team is attempting to clean up, or replace, much of the applications functionality but there are portions we simply do not touch because we have no solid clue how the application will work once it is deployed to our production environment. This is a highly-critical application and it cannot be broken.
Might anyone have any clue what may cause this to "magically" start happening? Especially since I have been working in UI-related code, and no where near the low-level, configuration resolution section of code where this came from.
ADDITIONAL NOTES
We use source control. If I download, build an run an older revision of the application, it works.
We use AnkhSVN and when I inspect my changed files, again, there is nothing that has been changed that relates to the code that is now failing.
No one else in my team has ever seen this.
To my knowledge, I've not tweaked any setting associated with my project. I've taken a look at my project properties and everything looks normal. I guess there is a chance that I've hit some odd key-combo and enabled/disabled something through shortcut-keys, but I have no clue what that might be.
Any help is appreciated. Sorry for the novel. I'm just stumped and I'd rather not use a different method for acquiring this path string if there is ANY chance that altering this process could behave differently in different user environments.
I can only assume some working file within the Visual Studio that is associated with the project/solution had become corrupt. I searched through the text of my project files, and all of my code, and I didn't see anything out of place.
As I mentioned, we use source control. To attempt a fix, I pulled down the same source revision that I initially pulled for my current task. I compiled and ran the application. Everything worked properly in its "vanilla" state.
Next, I copied in all of the files I knew I had modified. I hadn't added any new project references or resources, so I just copied over the modified .cs files. I built and ran the application and I've had no trouble since the pull from my branch.
This does not answer the question of why this occurred, but this method can provide a solution to the problem.
I can confirm this change in Path.GetDirectoryName occured to me after installing VS 2015 and rebuilding our project in it so it seams to be .NET 4.6 feature.
Rebuilding the project again in VS 2013 returns the previous behaviour where Assembly.CodeBase with "file:" prefix is acceptable by Path.GetDirectoryName without any exception.
But rereading the MSDN documentation, there is a statement that "file:" paths are not supported, but this is not mentioned in ArgumentException thrown in VS 2015 code.
First of all, find out how many versions ago this started occuring: start with the current version, and work back changeset by changeset until it no longer fails.
It sounds like, for whatever reason, System.Reflection.Assembly.GetExecutingAssembly().CodeBase now returns a string that GetDirectoryName doesn't like. So, check the project files, the .sln, the repo config, anything that could cause a file to be in a different location.
If you can't find anything there, check the other files from that same commit, even if they appear that they shouldn't be related.
First Chance Exceptions generally happen when you've got multiple threads happening, so check for new threads that weren't in the previous version. I've also had situations where First Chance exceptions would only get caught under certain situations, and are silently ignored otherwise, so look changes in Debug settings: it's possible that this problem has always existed, you just haven't had the right settings to catch it until now.
Remember that under a source control, other people can change things that are "yours", even if only by accident.
I have Resharper 9 installed and StyleCop as I'm trialling then to see if my work should get the tools installed for all developers (So I'm very new to using both tools).
StyleCop has a number of rules that affect line formatting, such as: SA1116. Resharper then picks up when these rules are violated and it offers the option to have it automatically fixed (as you can see below).
The only problem is when I actually hit enter nothing happens. Well nothing happens 80% of the time for this rule violation as well as for a bunch of the other formatting issues such as a space between a cast and a variable (e.g. (double) myDouble;)
It seems so erratic, does anybody know how to improve this or is it simply credit to StyleCop not completely integrating with Resharper? (In which case should I stop looking at recharper/stylecop combo as a "press button to fix" tool and more like "here's a warning, your welcome. Now if there's a button, press it you're lucky")
Cheers,
It might be worth raising this as an issue with the StyleCop project on CodePlex. However, the CodePlex project seems to be a bit abandoned - the current ReSharper 9 plugin is provided by a community member. There's a GitHub repo (although it doesn't have source) that you could use to try and file an issue.
Currently, the developers of my team format their source code (C++, C+, stored in MS's TFS 2012) manually. We are now considering to use Visual Studio's auto formatting option (probably with Uncrustify as the pretty print engine). The idea would be to make sure that nobody has any outgoing changes, and then to format the whole code base and to commit the result. From then on, we would integrate automatic formatting into our workflow.
However, our fear is that we will afterwards not be able to easily find out who has done the last changes on a particular line of code using Source Control/Annotate (that information is often quite useful, e.g. for asking the according developer about that code).
So here are my two questions:
a) Does anybody have experience with introducing auto-formatting into a team's workflow (given an already existing and quite large code base)? Are there any best practices for this?
b) In particular: Is there any way to format our complete code base without loosing the history information? I could e.g. imagine a tool which would keep track of where each line has gone after formatting, and to adjust TFS's history such that that information is preserved. However, I haven't found anything like that by now.
Annotation will indeed be 'screwed up' by pretty-printing the whole project. There are no tools that I know of that can work around that.
A way to get the least amount of history issues is to have each developer prettify a method when he is making changes to it to add functionality or solve a bug, this will take time to propagate the whole code base, but it's the only way I know of.
I'm making a refactoring tool that automates a few of the more trivial code styling things dealing with StyleCop. One of the things I'd like my add-in to be able to do (as an optional feature the developer can turn on/off) is automatically call the "Organize Usings -> Remove and Sort" functionality. This is a simple macro call.
However, my problem is that as I go through and recursively call the macro on every .cs non-designer file in the solution this particular macro checks for errors before execution. If there's a syntax error and my add-in starts calling that functionality, it throws up a dialog for each and every file.
What I'd like to do, is use the same method that function uses for checking for errors on the fly and then if there's an error that would cause the dialog to pop up, simply pop up a one-time notification and skip the calls on each file.
I know my add-in could check the error list, however I've found many times that errors that trigger problems in "Remove and Sort" don't always appear in the list. I've had the list be empty, then I try "Remove and Sort" and it tells me there's build problems. I then build the solution and sure enough it fails and the errors are populated. The only solution I'm seeing is to use the same functionality as "Remove and Sort" to check beforehand.
Does anybody know how I can detect compiler errors before building in the same manner as "Remove and Sort Usings"?
I'm not exactly sure what kind of errors you are talking about, I'll assume they are the ones that the IntelliSense parser generates. Yes, that parser isn't very reliable. It is not meant to be a full-blown C# parser, it was optimized to do a very different kind of job: providing context-sensitive help even if the code is incomplete and cannot compile. There isn't anything you can do to make it more reliable, other than waiting for the next VS release perhaps.
But it strikes me that you might be trying to fix the wrong problem. The key issue is that your add-in appears to be removing using directives that should not be removed. A real fix is to improve your code analysis engine so it reliably detects true namespace dependencies. Trying to guess which ones matter from hoping that IntelliSense is going to complain is only going to frustrate your customer.
It seems hacky, but unless somebody can come up with a better solution I'm gonna use a check on the errors list because it's better than nothing.
Additionally I think I may experiment with putting a timer around the call to "Edit.RemoveAndSort" and if it takes over a certain amount of time, pop up a one-time dialog mentioning that it looks like RemoveAndSort is having problems and asking if the user wants to cancel, or at least not call remove and sort.
Visual Studio is kind enough to generate a lot of code for us when we create and design Windows.Forms controls. It also surrounds most of it with a #region statement.
In newer versions it also uses a partial class to separate generated from manually created code.
Developers are supposed to edit code only in certain areas.
But nothing prevents us from violating this in whatever way we please.
I'm fine with manual edits that could just as well have been made from the designer, or manual edits in areas the designer doesn't touch. But I'd like to flag any other kind of edit.
Does anyone know a utility that can do this? StyleCop rules perhaps?
I mostly need it for the combination of C#, Windows.Forms, and Visual Studio 2003, 2005, and 2008.
These days, designer code should end up in a .Designer.cs file. It should be very rare that developers need to touch that. Unfortunately, I don't know any way of verifying that the code was genuinely generated by the designer. It would be handy if it included some sort of hash, but it doesn't as far as I'm aware...
Given how easy it is now to just say "don't edit designer files" do you really need another system though? It's not like you need to stay away from specific regions - it's the whole file which is out of bounds.
Why should developers not be allowed to change this code? If they are able to write code that works, they should be allowed to do it. If they are not able to write code that works, lets say they should be trained or fired.
You just have to extend the meaning of "it works" to "it works at runtime as well as in the designer". So what's wrong about that?
Todays gui designers are not very restrictive and are doing a good job in "understanding" code that had been written by a human.
There is also real generated code around, for instance code generated by some xml specification, resources etc. This code is generated when building, so when it had been changed, these changes are undone whenever the application is built.
Designers are not real code generators of this kind. They are a kind of "coding helpers", helping the developer to write code faster then by typing it in. But it should actually be possible to write the same kind of code manually although limiting one self to the designers capabilities is a reasonable maintainability decision.