Best Practices for Developing SharePoint Custom Web Parts

Overview of Custom Web Part:

A Web Part, also called a Web Widget, is an ASP.NET server control which is added to a Web Part Zone on Web Part Pages by users at run time. The controls enable end users to modify the content, appearance, and behavior of Web pages directly from a browser. It can be put into certain places in a web page by end users, after development by a programmer.Web Parts can be used as an add-on ASP.NET technology to Windows SharePoint Services.Web Parts are equivalent to Portlets, but don't necessarily require a web portal such as SharePoint to host them.

Web Parts are reusable components that display content on web pages in SharePoint 2013. Web Parts are a fundamental component in building SharePoint pages. A number of Web Parts ship right out of the box with the different editions of SharePoint, and you can also purchase third-party Web Parts.
Note: The Web Parts that you have available depend on which SharePoint 2013 edition you use as well as which features are activated. For example, the PerformancePoint Web Parts are available only with the Enterprise license and only when the PerformancePoint Services feature is activated.
Below Fig show Categories of webparts available in sharepoint 2013. You can add your own categories.

The following is a list of the common Web Part categories:

• Apps: Each app instance you have added to your site has an associated Web Part. The app Web Parts enable you to add a view into the data in your app to your web pages.
• Blog: Provides Web Parts for a blog site.
• Business Data: A group of Web Parts that display business information, such as status, indicators, and other business data. This group also includes Web Parts for embedding Excel and Visio documents and displaying data from Business Connectivity Services (BCS; a component of SharePoint that allows you to connect to data stored outside SharePoint).
• Community: A group of Web Parts for the community features of SharePoint, such as membership, joining a community, and information about the community. In addition, there are tools for community administrators.
• Content Rollup: Contains Web Parts that are used to roll up (aggregate) content, such as rolling up search results, providing project summaries, displaying timelines, and showing relevant documents from throughout the site.
• Document Sets: Web Parts specifically designed for working with sets of documents.
• Filters: Web Parts that can be used to filter information. These Web Parts are designed to be connected with other Web Parts in order to provide a useful filtering mechanism. For example, you might have a list of content and want users to be able to filter based on certain criteria. You could use these Web Parts to provide the filter mechanism.
• Forms: Web Parts that allow you to embed HTML or InfoPath forms in a page.
• Media and Content: Web Parts that display media, such as images, videos, and pages. In addition, there is also a Web Part for displaying Silverlight applications.
• PerformancePoint: Web Parts specifically designed for PerformancePoint services.
• Project Web App: Web Parts specifically designed for Project Server. These Web Parts include functionality for displaying information about a project, such as issues, tasks, timesheets, and status.
• Search: Provides Web Parts for search functionality, such as the search box for entering a query, search results, and refinement of results.
• Search-Driven Content: Provides Web Parts that display content based on search. For example, Web Parts that show items matching a certain tag, pages based on a search query, and recently changed items.
• Social Collaboration: Web Parts designed for the social components of SharePoint, such as user contact details, shared note board, tag clouds, and user tasks.

INFO :Web Part behaves like control which runs or works only when hosted on webpage
In SharePoint, web parts usually coexist with other web parts on a web part page. So,It's developers responsibility to ensure that you design your web part so that it will:

• Provide an intuitive user interface even when failing
• Work with other web parts running in the same environment
• Be upgradable
• Be safe and secure
• Provide optimal performance

Best Practices for Developing SharePoint Custom Web Parts 

It should go without saying that you should not stop implementing normal programming practices when programming web parts either using c# or vb.net. To this end you should still…

Handle All Exceptions.

It is quite likely that any exception generated by your web part will cause the entire web part page to stop responding and display your error. You should avoid such problems at all costs by wrapping all code likely to generate an exception in a Try/Catch/Finally block

SharePoint will direct any unhandled exceptions to a generic error page and render a message. To control the error message displayed, you need to implement the WebPartPageUserException class.

Validate All User Input.

Any information submitted via a web application is subject to both accidental misuse and deliberate attack. Therefore, you must validate all information submitted by the user, making sure it's in an appropriate form and contains acceptable values.

HTML- Encode All User Input

To help prevent a malicious user from attacking your application using cross-site scripting or other script-based attacks you should always encode input to safe HTML. This changes all extended and special characters into escape characters. To do this in SharePoint, use the SPEncode class's HTMLEncode method (you will need to import the Microsoft.SharePoint.Utilities namespace to use this class).

Linked Resources

In addition, if your web parts use external resources such as images, CSS files, or scripts, you will need to reference these from within your code. If you want to maintain the upgradability of your web part, use linked resources to ensure that the external files are not bound to your assembly. This will also help with performance if you share these scripts with multiple web parts, because they will be cached at browser level.

User Interface

If your web part performs actions within the SharePoint framework that require permissions, then you should check these permissions before rendering your interface. Although there's no real security hazard here—WSS 3.0 will not allow a user to perform an action unless they have appropriate permissions—by checking permissions before rendering, you can improve the look and feel of your web part by hiding or graying out options that are unavailable when a user does not have sufficient permissions.

Exported Web Parts

An instance of your web part on a page could potentially be exported by a user into a .dwp file. By default, this file will contain all the properties set on the web part. That's a security hazard, because if your web part contains properties that are sensitive or confidential in nature, you may not want those to be exported by a user. Examples might include personal information such as telephone numbers, postal codes, dates of birth, etc. To prevent a web part from exporting sensitive information, you need to perform two actions:

Set a WebPartStorage attribute on the property within your web part, and set ControlledExport to true:

// C#

[WebPartStorage (Storage.Personal, ControlledExport=true)]

‘VB.NET

<WebPartStorage(Storage.Personal, ControlledExport:=true)>

The WebPart class has a property called ExportControlledProperties, which is set to false by default. However, a user can set this to true to override the ControlledExport value set above. Therefore, you must ensure that users with appropriate access to alter web part properties are also those users with authority to see this controlled data.

Web Part Zone Properties

Each web part zone on a given page has AllowPersonalization and AllowCustomization properties that control whether a user should be allowed to save changes to any web parts in that zone. The properties dictate whether a user can save changes in shared view or personal view, respectively.

Another property, named LockLayout, controls whether users can save changes to the following web part properties:
AllowRemove
AllowZoneChange
Height
IsIncluded
IsVisible
PartOrder
Width
ZoneID
If your web part allows users to change any of these base class properties, you should always check the parent web part zone for theLockLayout property before saving the changes.

You can access the parent WebPartZone using the following code:

// C#

WebPartZone myZone = (this.Page.FindControl (this.ZoneID));

' VB.NET

Dim myZone as WebPartZone = Me.Page.FindControl (Me.Zone-id)

Final and Very Important Points

Although they don't fall neatly into a category, there are a couple of other topics that you should keep in mind when developing web parts.

Make Properties User Friendly

Your web part users will typically modify properties exposed by your web part from the tool pane. Therefore, you should set the following attributes on your properties when appropriate, so that they have friendly values when rendered in the tool pane.

WebDisplayName: The name for this property as shown in the tool pane.

WebDescription: The tooltip to display when the user hovers the mouse over this property in the tool pane.

Category: A category in which to display this particular property. If you don't specify a category, the tool pane displays it in the default "Miscellaneous" category.

Don’t

1. Use Inline Styles

Inline styles are styles applied directly to HTML content and look like the example below:

<div style="width:100px;color:green"></div>

Inline styles are the most specific and the highest priority of all other styles so it’s tempting to use them instead of fighting with the cascading style sheets of SharePoint. You don’t want to manage styling this way because inline styling mixes content and presentation (look and feel) together. This is a bad practice because styles aren’t managed in a central place, pages can become inconsistent and they are pesky little buggers to find and correct.

2. Apply a Fixed Width to a Collaboration Site

A fixed width layout has a set width around the main content area and doesn’t expand to fill the browser window. When you fix the width of a site meant for collaboration and document management, you have to potential of eliminating extra space for users to add content and collaborate.If you must fix the width on a collaboration site, fix the width of the content area using a percentage rather than a set pixel value. This ensures the maximum amount of space and focuses on function rather than form.

3. Use Too Many Master Pages

Multiple master page design for every design variation even if it something small such as a different logo or a background color. Over the course of a year, the differences between the master pages became significant. Consolidating these master pages was part of the upgrade path and it cost the client a fortune. Be wary as those master page numbers start climbing.

If you are using over four master pages to manage branding for any given site or site collection, you are probably doing it wrong. If you forced me at gunpoint to come up with an ideal number of master pages, I would say 1 master page per parent design and then I would probably wet my pants (because I’m at gunpoint).

If you are using multiple master pages that share the same parent design, try to consolidate them. First define how they are different. Determine if those variations can be managed using page layouts, custom controls, alternate CSS, or scripts. You can generally manage styling differences in a design such as colors, logos, and icons using CSS and page layouts. Variations in master content such as header and footer links can be managed with SharePoint lists and custom web parts or controls.

Conclusion: As you know that web part needs host so be careful while writing your own web-parts because they can ruin entire page functionality.So, better fallows best practices or checklist recommended by Microsoft