Related
Are there any best practices for enforcing a TFS check-in policy? Are there any good guides on how to implement various types of policies as well as their pros and cons?
Things I'd particularly like to do are ensure that code compiles (note that compilation can take up to five minutes) and that obvious bits of the coding standards are followed (summary tags must exist, naming conventions are followed, etc).
TFS 2010 (and 2008 but I have not used 2008) allows a gated checkin - which forces a build prior to the build being checked in.
Activating this is a (reasonably) straightforward process, see for example these guides:
http://blogs.msdn.com/b/patcarna/archive/2009/06/29/an-introduction-to-gated-check-in.aspx
http://intovsts.net/2010/04/18/the-gated-check-in-build-in-tfs2010/
There is a step before all this which is required to make all this happen. That is a TFS build server setup. That can be a complex process depending on infrastructure etc. Here is an MSDN guide:
http://msdn.microsoft.com/en-us/library/ms181712.aspx
The pros are that the code in the repository can be reasonably stable. For a large team this can save a LOT of time.
There are a lot of cons worth considering for this benefit. Firstly, the installation and maintenance of an extra build server. This include disk space allocation, patches etc.
Secondly is the extra time required for each person to check in a file. Waiting for a build to succeed before the code is checked in (and available for others to get) can be a while.
Thirdly, when (not if) the build server is not available, a contingency plan needs to be in place to allow developers to continue their work.
There is a lot of extra process required to reap the rewards of gated checkins. However is this process is governed properly it can lead to a much smoother development cycle.
Although we do not use gated checkins, we do use a TFS build server for continuous integration to do scheduled builds. This minimises the dependency minute-to-minute on the build server while ensuring (with reasonably effectiveness) that after a build has broken, we are notified and can rectify it ASAP. This method empowers the developers to have an understanding of integrating code, and how to avoid breaking the code in the repository.
I think the premise of this question is somewhat wrong. I think a good question of this nature should be something along the lines of; my team is having a problem with code stability, conflicting change-sets, developers not running tests, poor coverage, or other metric reporting to management and we'd like to use TFS to help solve that(those) issue(s). Yes, I do realize that the OP stated that ensuring compilation is considered a goal, but that comes part and parcel with having an automated build server.
I would question any feature that adds friction to a developer's work cycle without a clearly articulated purpose. Although I've never used them, gated check-ins sound like a feature in search of a problem. If the stability of your codebase is impacting developer productivity and you can't fix it by changing the componetization of your software, dev team structure, or a better branching strategy, then I guess it's a solution. I've worked in a large shop on a global project where ClearCase was the mandated tool and I've encountered that kind of corporate induced fail, but the team I worked on didn't go there quietly or willingly.
The ideal policy is not to have one. Let developers work uninhibited and with as little friction as possible. Code reviews do much more than a set of rules enforced by a soul-less server will ever do. A team that supports testing, and is properly structured will do more for stability than a gated check-in will ever achieve. Tools that support branching and local check-ins make it easier for developers to try new things without fear of breaking the build will help mitigate the kind of technical debt that kills large projects.
You should look at chapter 8 of "Patterns & practices: Team Development with Visual Studio Team Foundation Server"
http://tfsguide.codeplex.com/
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
The company I work for uses C++ Builder 6. We've been developing native code since conception. Our flagship product is written completely in native code.
Enters the .NET Framework with its bells and whistles. I fall, hook, line and sinker. I convince management that .NET should absolutely be our new framework for all new software development and that we should start migrating our existing codeline ASAP. With all the benefits it doesn't take much convincing. They accept my proposal as usual.
At this point I start developing my very first .NET application. It's all going as planned. The project is only one component of our product. And so I get to the point of creating an installer for this new component. As a company we pride ourselves in making things for the user as easy as possible. Even Microsoft with thousands of developers don't create installers like we do. When you install Microsoft CRM for instance, you will only get a list of failures and prerequisites that needs installing before you can continue. Not us. Never. If you need something, we will install it for you.
This makes our installations feel so easy. .NET Framework not installed? No problem! We'll do it for you. Need SQL Native client? Fine!
The issue is this, now that one single component of our solution is written in .NET, it complicates the installation process incredibly. Before I can even get to installing our product, I need to do the following:
Detect whether the prerequisite is installed
Install it if it isn't
Verify that it was installed successfully
Next prerequisite
To install .NET Framework, I need the Windows Installer 4.5 first. But there are different versions for the different OSes, so I add OS detection and launch the correct EXE. Oh, .NET framework is already packaged with 2k8 and the installer exe cannot run on it, you have to run OCSetup.exe with parameters to install it.
And so it carries on. Then SQL Express 2005 needs to be installed. The dependencies increase once again.
I argue with management that even Microsoft don't make it this easy for the user. Their response is that there is no reason for us to not be better than them in this way. I can't argue with that except that I feel that there are very good reasons they've gone with their approach.
Suddenly, our installer is massive. All the prerequisites for .NET, not even talking about 64 bit support which has a whole separate range of EXEs to install. So now it gets to the point where we want users to be able to download a "quick" evaluation. What a joke. You need to download 500MB to get a 30MB application running. The majority of the installation package is prerequisites.
Management feels that we have too many dependencies/prerequisites. I understand completely. They suggest we move away from the .NET framework, back into native land where things were still "easy" in terms of installation. This is where the one part of me wants to stand up for .NET explaining the benefits in the big picture, the improved development experience, easier maintenance and overall code quality. The other part of me agrees with them wholeheartedly! Developing in .NET simply requires you to install too many other prerequisites which complicates the installation.
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
We are now considering writing native code again and I know we're losing in terms of development speed and all the goodies of .NET. But we are gaining in this area, be it small if you look at the big picture or not. As we have native code development skills and .NET is actually new ground for us, it even makes sense to move back.
My question is this: what is your company's view on this issue if it even is an issue at all and what will the business case look like that I propose to management assuming I want to continue migrating all our products to .NET?
This is the reason to why many companies have switched to web installers that download all prerequisites on the fly from your homepage. Since in most of the cases, the OS have 99% of what's needed (if they have been updated using Windows Update).
I would not put everything for x64 and x32 in the same installer. Create two installers, one for each architecture.
Paint.NET wraps the installation of prerequisites up nicely without bundling the .NET framework with it by default. The end result is an unmanaged shim executable that checks for the .NET framework and some other stuff and holds your hand as it gets installed; all downloaded on the fly as they are needed. They then run a WinForms application that pInvokes into MSI to further wrap the installation up in cotton-wool.
Worth a Google.
Also likely is the fact that a lot of client machines will already have some version of the .NET Framework installed as it is part of Microsoft Update - making it more easily consumable in the business world.
Paint.NET blog posts about installing:
http://blog.getpaint.net/2008/08/24/the-paintnet-install-experience-part-1-version-3xx/
http://blog.getpaint.net/2008/08/25/the-paintnet-install-experience-part-2-version-40/ (thanks Rup!)
Reading into the story a little more, presumably management had to go through the pain of deployment with the C++ application at least once, but it is now done and classed as "easy". Put some time against the deployment and present this to management and, hiding the pain, show them how easy it is to install :)
Let's go back to why you wanted to switch from native code to .NET code in the first place: it's more efficient for you, as a programmer. Many things are easier in .NET than they are in C++ (or whatever native language you're using), and so you can develop your applications much more quickly.
Then, how does the time you spend developing the application compare to the time you spend developing the installer? Even if you have to spend a couple weeks nailing down the installer (specifically the framework setup portion), that should be more or less the only time you have to go through that.
For all future applications, you would be using an almost identical installer; you would still do all the prerequisite checks, but instead of copying files to C:\Foo, you're copying some different files to C:\bar.
In my opinion, this is a simple question of economics. Yes, it's more expensive to develop a (good/complete) installer for a .NET application, but if that's the step you need to take once to dramatically improve your development time, it's a no-brainer. Your return on investment would probably be in the order of weeks.
I feel I need to respond to this statement:
Yes, some of the .NET advocates will claim that everything should be installed on a patched and updated operating system. This is true, but not all customers have this, and simply saying "I'm sorry, update first" just won't cut it. Remember, we pride ourselves in the overall user experience.
If your user is insistent on shooting themselves in the foot by operating a system that the vendor has informed them is no longer fit for purpose, then there's nothing much you can do to 'help' them. I'm aware that this makes me look like something of an obnoxious activist, but I look at it in the same way that a manual tradesman might - it is up to the customer to ensure that the environment in which they want me to work is sound and appropriate for the product. If it isn't, I'll accept further renumeration to do that job as well, but it might still cause them extra work because they haven't had the foresight to make sure they understood what they were buying.
I believe software customers have been allowed to remain ignorant for long enough, and that they should now be required to understand what it is they are buying. Operating a corporate IT environment that isn't properly patched is the same as continuing to run a vehicle that has been subject to a manufacturer's recall - a Windows service pack is equivalent to a recall in many respects. You're not legally obliged to submit to a recall, but it's in your best interest as a business and you may be held responsible for damages caused by your shirking of responsibility.
Any Visual C++ app has prerequisites / external dependencies as well: runtime 6.0, 2003, 2005, 2008 or 2010? no SP, SP1 or SP2? x86 or x64? What version of Windows Installer does 2005 SP2 require? And what 2008 SP1? And so on, so on.
Thus that's far-fetched arguments! Like Joel's grumblings about .NET. And look what's now!
I don't see how there are significantly more pre-requisites for .net over C++ Builder. You complain about SQL Server, but you ignore the fact that you have to install some database with C++ builder as well. You complain about x64 vs x32, but .NET doesn't require any change.. the same exe runs on both (and compiles itself optimally for either environment). The same can't be said about C++ Builder. You may need seperate versions of SQL server, but again that would apply to C++ builder (unless you just install x32 on everything).
Yes, there are the new installer version issues, but those components aren't very big. And you really can get the installers to download and install only the aprts that are necessary.
C++ builder is probably easier for you because you've already invested the time in creating a good installer. You need to do the same for .NET, and then you can choose based on real issues.. and not this.
By the way, the reason Microsoft chooses to do things the way they do is that many users, especially corporate users, do not appreciate having things installed for them automatically (perhaps because they have an application that depends on a specific version of a library, and you come along and wipe it out with a new version that they can't easily uninstall).
What you view as "making it easier" for less knowledgable people is actually making things MUCH harder for those that know what they're doing.
Here's a good example. One thing I absolutely despise is when I install an app that needs SQL Server, and it installs its own instance of SQL Server, even though I may already have several instances already that it could use. Easy for the novice, a pain in the ass for me to try and get your app to work with my single instance.
If your app runs under Mono, then shipping your app with the Mono runtime might be less painful.
I have used Visual Studio Professional 2008, and have been testing the free C# Express 2010 version recently. In general I'm amazed at how good it is for free, and how many of the full VS features it has. I'm thinking of using it for a commercial program and I know the license allows for that, it's just the description of it being for "non-professional developers like hobbyists, students and novice developers" concerns me a bit.
What I'm interested in knowing is what is stopping it being 'professional', that is:
Have you evaluated the express edition, and found a specific useful feature lacking that stopped you from using it ? Or did you initially use the express versions, but upgraded to full VS because of a feature lacking ? If so, what was that feature ?
I've searched for similar questions and found lists of differences between the full VS and express versions, but I'm more interested in knowing peoples personal experiences with it. It seems like many of the extra features in VS target developers working in large teams, so I'm mainly interested in hearing from either solo or small team developers where it seems like there's less compelling reasons to upgrade.
The limitations I've personally encountered are:
Extensions not being supported, though I can still use DotTrace, NUnit and an obfuscator outside of the VS integration, albeit it's a bit less convenient.
Limited refactoring, although the "Rename" and "Extract Method" are still there and I think they're the most useful. Edit: Not having 'Encapsulate Field' in Express used to be annoying though, though the introduction of automatic getters and setters has pretty much canceled that out I think.
More limited debugging for multi-threaded apps.
Edit: Another is that you can't easily switch between targeting "Any CPU/x86/x64" in Express like you can in VS. It is possible, but needs manually editing your project file to do so.
But the pluses seem to outweigh the minuses so far. Is there anything you found was a deal-breaker for you ?
Update: To come back to this a couple of months later, and after releasing a product built with the Express version, it is indeed possible to program professionally with the Express versions. The limitations within the program itself are pretty minor and can be worked around, but I've increasingly come to realise it's really the "extensions not supported" one that's the (only) major drawback. No Resharper, CodeRush or the like, and no source control, profiling, database explorer or unit testing and the like within VS itself. It's more of a productivity drag than a deal breaker, but it is annoying to come across a cool looking VS extension only to see that "Not supported in Express versions" notice.
If anyone else is in the same situation, I'd evaluate the extensions you use (or might be planning to use) first and see how important they are to you. Express is fine if you don't use any extensions or could live without them without a significant drop in productivity, otherwise stick with the Professional version.
I've used express for 5 years, it has everything you need to produce professional projects. There's one important feature that's missing, which is the extensible Database Explorer, e.g. if you need to generate an Entity Framework model from a MySQL database. But for that I use Visual Studio Shell (also free). For other stuff such as unit testing and source control I use other tools. You really don't need Visual Studio to have everything you need to manage a software project.
No add-ins => No ReSharper => No dice.
The biggest problem with the Express version is you don't have any source control. You can't professionally work without it, even if you are a lone freelancer. Keeping a change history on a project is vital when you mess something up and want to go to a previous version or simply want to compare different revisions.
Also I think in Express you can't have web and desktop applications in the same solution, or do other types of combination of projects. I'm not really sure about this one, because I don't use Express (for the first reason :))
Other answers have covert the fact that it can very well be enough, but if you are more than a hobbyists, students or novices, just get enrolled into the Microsoft BizSpark program.
You get all the tools for free (Visual Studio Ultimate, Team Foundation Server, All Windows Versions etc.) and you don't even need to be a company. Enrollment is super easy and uncomplicated.
The only requirements are (taken from the homepage):
You develop software
Privately held
Less than 3 years in business
< 1mio $ per year
This is not an ad. We have been very happy with the program and got access to everything we needed. Just wanted to let people know it existed.
Additional info:
You can be member of this program for 3 years
When you leave the program you have to pay a 200$ fee, its made for startups afterall
I had been using VS Express for several years but I recently upgraded to VS Ultimate. There is nothing that you cannot do in Express, but the integration of features in the full product makes everything more convenient.
When you have source control, unit tests, performance/code analysis, installers all in the same solution, it saves a lot of time and hassle jumping between different programs. Also one big issue for me was not being able to mix features that are spread across the different Express editions, such as mixing ASP.NET with WinForms, or even VB.NET with C#.
I got a lot of use out of Express, it's a great product, but I was very happy the day I got to uninstall ten programs and replace them with one.
The pros:
Absolutely free
Has enought functinality for you to develop commercial products (you know the saying: you need 20% of anything to get 80% done). I developed and deployed a wp7 (windows phone 7) app with the express edition and it was a pleasant experience.
The cons:
No integration with source control. I use svn for my projects and i have to use tortoise svn outside of vs to manage the code. Its a minor annoyance, not a deal breaker.
Can't develop web/desktop/mobile in the same solution. Its easier to have them all in the same project when you have a common dll for your business logic. Unfortunately with express edition you will end up using copy/paste for moving dlls that are common between projects. Again it's a minor annoyance, not a deal breaker.
Professional is not the big step up here - Ultimate is. VS2010 Ultimate, for example, comes with bunches of profilers and that kind of thing. They give Professional away to any old student, for example.
There's only one plus: the cost. Every other difference is a minus (or at best reduces the cost of the minimum useful system). That means that, if the extra features are worth the money, buy the higher-end version.
The free lower-end version is great for (as they say) students, hobbyists, and novices. Students often don't have much money, and hobbyists and novices often don't want to spend all that much money on their hobbies and introductions.
However, a software professional is making money writing software, and presumably will make more money if he or she becomes more efficient. Assuming our professional is making decent money, the cost of an upper-end version of VS isn't large compared to revenues, and if it leads to even modest productivity increases it's worth it.
When you're doing something for money, don't try to do things too much on the cheap. Taking more time and inconvenience to do things will cost real money in that case, and avoiding it is worth real money.
Microsoft's marketing approach to these Express editions may be is to introduce Visual studio flavors to users (any user). Later, bring them on board with more powerful versions. Also, Express editions allows you to write code anywhere without getting worried about licensing part. You can use them to try out your test bed projects, community projects etc. I must re-iterate again that free licensing is the biggest draw towards Express editions
The only substantive differences I've found are the integration of code control and the ability to create heterogeneous projects. The first is not a major issue if you are the only developer. With the Express versions, You can use whatever code control mechanism you like, just not built in.
The second is only an issue if you want to develop using some combination of C++, C# or VB in the same project. You need at least VS2010 Professional to do that. Given the extensive features in C#, the absolute need to use C++ or VB with it in the same project is highly unlikely. However, those situations exist if you need C++ in a C# project for some low level API or have a legacy VB system and need some feature from C# or C++ that is just too difficult to manage in VB.
As a friend who built racing engines once observed: Speed costs money. How fast do you want to go? Express is free, the others can be pricey, although the price for VS2010 Professional just plummeted with the advent of VS2012.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Based upon your experience
If you was given the opportunity to set up the development processes for a small development team.
Please detail
The things you would implement, tools, documents, methodology.
And how you would implement these?
I wish to implement the following:
Source Control
Bug tracking database
Formal Spec templates
Code Reviews
Coffee cup meeting (simple quick informal meetings over coffee :) )
Strict Coding convention
Please keep in mind this would be for a C# .NET focused environment.
If you plan on purchasing, or already have purchased, MSDN subscriptions, there is a major change in licensing that plays out in your favor for Team Foundation Server 2010. Server licensing is now included with MSDN, and you are provided with one CAL per subscription. More licensing details are available here.
Team Foundation Server will cover almost all of your needs in one package. I am very preferential to using as few tools to complete a job as possible, which is one of the reasons I recommend that you look into using Team Foundation Server, as well.
Some notes into your specific requirements:
Source Control - One of the primary functions of Team Foundation Server. It works well and easily integrates with AD Groups. We have security groups set up by roles per project and also for roles across projects. A company developer will be a part of the "Developer" SG and the specific SGs that he/she are involved in. This allows us to give them full access to the projects that they are working on and read access to all projects. The system has the benefit of contractors not belonging to a generalist development group - effectively bucketing them into projects.
Bug Tracking Database - Integration with source control is a definite advantage. By using one package, you have an built in relationship between work items and changesets (which you can further enforce by requiring changesets are only created in the context of work items). Work item relationships are very nice - and vary, depending on your template choice. Both Microsoft's SCRUM and Agile templates are well thought out, and have served our needs quite well, to date.
Formal Specification Templates - There are a couple of ways to approach this. You could create a specific work item type for each template and prepopulate some of the content, or if you wanted a more traditional approach, you could store document templates within the project's Document tree (which is, effectively, a document library on the Team Project Portal site).
Code Reviews - Basic functionality like Annotate (or Blame, if you prefer) are built in. Diff Tools are provided, as well - plus you can switch out the diff tools for others if you do not like what ships with it. (Personally, I use DevArt's CodeCompare .) As for the actual review process, I am a fan of TeamReview.
Strict Coding Conventions - StyleCop is a must, in my opinion. As such, I also believe that ReSharper is a must, as well. Providing conventions is one thing, but being able to visibly put them in front of the user is another. Using something like StyleCop for ReSharper will provide real-time feedback on violations of policies. Anything that you want to add that isn't a part of StyeCop can be created via custom rules, and you can actually put the ReSharper configuration for SCFR in TFS, so that it is shared by the team.
Bonus items that you get that you did not explicitly mention:
Build Management - The build tools in Team Foundation Server 2010 are completely overhauled. Now, builds are defined as workflows using Workflow Foundation, but still can be manually manipulated for more complex build scenarios Gated check-ins, often referred to as "buddy builds" help keep bad code out of the trunk.
Test Management - Testers can benefit from the streamlined testing tools in Visual Studio 2010. Automation of CodedUI tests, and the Test Lab Management tools are major strides in the evolution of Visual Studio. Having a tester be able to capture the state of the machine and automatically insert it into a work item is brilliant, and long overdue. Plus, if you end up using the Test Lab tools, actually being able to capture a snapshot of the VM at the moment of the crash is just pure gravy.
Collaboration - Even if you don't plan on using it at first, the Team Project Portals that are created for each Team Project are ripe with opportunity for collaboration. Just for document management and project wikis alone, it is worth its weight in gold.
Reporting - The reports vary with the templates that you use, but most templates have the type of reports that management care about ready to go. Adding new reports is fairly simple, due to the way that the TFS team has presented data in the cube, as well. A little SSRS knowledge will have you creating detailed custom reports in no time, at all.
Planning - You do not mention what type of methodology you are using - but the Agile template has some really nice sprint planning tools built in. You literally launch a sprint planning worksheet from Visual Studio, which opens in Excel, and any changes you make are reflected in TFS. Really works great for a group planning session.
Support - This is one of the most important factors to me. Having all of the above in a single package also means that I only need to go to one vendor for support. It is invaluable to me to be able to have one phone number to call in the rare occasion that something does go wrong, and know that I have the support incidents to cover it already paid for, thanks to my MSDN subscription.
All that being said, TFS does have a bit of a learning curve. Installation and setup are actually quite simple, assuming that you follow the documentation. The learning curve comes from the fact that there is so much to do with TFS. You might not use all of the features, so the amount of time you actually need to spend learning might vary. The native integration with Visual Studio (and Office) do provide a seamless feel, though, that should translate well to the developers using the system.
Source Control: For a .NET environment, Team Server is good stuff. If you want a free solution, I like Mercurial.
Bug Tracking: FogBugz (of course :)
Spec Templates: I think defining these should be a collaborative process between the development team and business units. Start with a very light framework and let them evolve, don't prescribe a massive document that includes information no one ever uses.
Code Reviews: Peer programming time offers this in abundance. Call out good practices to the team- don't use it as a way to humiliate developers in public.
Meetings: I'm an Agile kind of guy, so meetings (standups) should be brief, to the point, and happen every day at the same time.
Coding Conventions: Again, if you have capable developers you shouldn't have to prescribe strict conventions. Agree as a team on basic conventions and address friction points as necessary.
If your team can foot the bill for Team Foundation Server, you'll have most of what you want in one convenient package.
Source Control: Changeset-based configuration control system with full branching support.
Bug tracking database: Work items - configurable, including bug tracking and reports.
Formal Spec templates: Work items - configurable, including requirements (CMMI), scenarios (Agile), custom types, etc.
Code reviews: Work items - track your reviews just like any other TFS piece of work. A review work item ships with the CMMI process template.
Strict coding convention - I've heard of people integrating StyleCop with their check-in policy.
As for coffee cup meetings, you won't need a tool for that. :)
Did a quick search but could not find anything about this.
I guess all of you know that the Visual Studio Code Analysis is quite nitpicking and gives warnings about a lot of things. Does anybody know how well Microsoft follow this themselves..? That is, if I were to run a code analysis on their assemblies, would the warnings be none or very few (perhaps surpress warning with a justification..?).
Most of the things that code analysis (or FXCop) check are closely based on the ".NET Framework Library Design Guidelines" (either the book, or on MSDN).
However those guidelines (especially in the book) have caveats, not all apply in all circumstances.
There are plenty of indications that MS do use these tools, but I assume they do have reasons to not apply all the rules all the time, as any other project does.
There are two core tools used widely at Microsoft for Code Analysis: FXCop for managed code and PreFast for native C++.
Historically, while not every team has thoroughly enforced the use of CA when building their products, there's been a significant upswing over the last 3-4 years in particular in the number of teams that now enforce pretty stringent CA requirements on their feature teams and on the product as a whole.
For example, in Vista, the Windows team essentially took 3 months off product development and SAL-annotated the vast majority of their key method and function declarations. in Win7, they mandated that all new code had to comply with a set of requirements for SAL-annotating key scenarios (primarily to reduce the likelihood of buffer overruns). In Win8 they're going further still and are incorporating new SAL annotations for a number of key scenarios. Combined with improved compilers and tools like PreFast (now build into VS 2010 Pro and up), they and you can find and eliminate potential issues before the product is released.
Note that the warnings issues by CA (whichever CA tool you choose to use) will always require overrides - sometimes, there's a really good reason as to why the code has to do what it does. But you should only override if you're ABSOLUTELY sure it's necessary and appropriate. NEVER turn off a warning because you don't understand it and never turn off a warning if you can't be bothered to fix it.