Course vb.net: Coding Standards
Course vb.net: Coding Standards
Course vb.net: Coding Standards
Table of Contents
1.
Introduction
1.1 Purpose
1.2 Scope
1.3 Document Conventions
1.4 Feedback
2. VB.NET Golden Rules
3. Formatting
3.1 Class Layout
3.2 Indicating Scope
3.3 Indentation & Braces
3.4 White space
3.5 Long lines of code
4. Commenting
4.1 End-Of-Line Comments
4.2 Single Line Comments
4.3 ‘ TODO: Comments
5. Capitalization & Naming
5.1 Capitalization
5.2 Naming
6. Programming
6.1 Namespaces
6.2 Classes & Structures
6.3 Interfaces
6.4 Constants
6.5 Enumerations
6.6 Variables, Fields & Parameters
6.7 Properties
6.8 Methods
6.9 Event Handlers
6.10 Error Handling
Appendix A. Naming Parts & Pairs
A.1
Common Adjective Pairs A.2 Common Property Prefixes
A.3 Common Verb Pairs
A.4 Common Qualifiers Suffixes
Appendix B. References
Revision History
****************
Sample of the pdf document
1. Introduction
1.1 Purpose
The purpose of this document is to provide
coding style standards for the development source code written in VB.NET. Adhering
to a coding style standard is an industry proven best-practice for making team
development more efficient and application maintenance more cost-effective. While
not comprehensive, these guidelines represent the minimum level of standardization
expected in the source code of projects written in VB.NET.
1.2 Scope
This document provides guidance on the formatting,
commenting, naming, and programming style of VB.NET source code and is
applicable to component libraries, web services, web sites, and rich client
applications.
1.3 Document Conventions
Example code is shown using the Code font and shows syntax as it would be color coded in Visual Studio’s
code editor.
1.4 Feedback
Feedback on these guidelines is highly encouraged.
Please send any questions or comments to your application architect.
2. VB.NET Golden Rules
The following guidelines are applicable
to all aspects VB.NET development:
o Follow the style of existing code. Strive to maintain consistency
within the code base of an application. If further guidance is needed, look to these
guidelines and the .NET framework for clarification and examples.
o Make code as simple and readable as possible. Assume that someone
else will be reading your code.
o Prefer small cohesive classes and methods to large monolithic ones.
o Use a separate file for each class, struct, interface, enumeration,
and del egate
with the exception of those nested within another class.
o Turn Option Explicit and Option Strict on for every project under Project | Properties | Common Properties
| Build. These can be made the default options for all new projects by going to
Tools | Options | Projects | VB Defaults.
o Don’t use the On Error Goto or On Error Next statements. Use
structured exception handling via Try/Catch blocks instead. They are the preferred method of performing error
handling in .NET.
o Write the comments first. When writing a new method, write the
comments for each step the method will perform before coding a single
statement. These comments will become the headings for each block of code that
gets implemented.
o Use liberal, meaningful comments within each class, method, and block
of code to document the purpose of
the code.
o Mark incomplete code with ‘ TODO: comments. When working with many classes at once, it can be very
easy to lose a train of thought.
o Never hard code “magic” values into code (strings or numbers).
Instead, define constants, static read-only variables, and enumerations or read
the values from configuration or resource files.
o Use the StringBuilder class and it’s Append(), AppendFormat(), and
ToString() methods instead of the string concatenation operator (+=) for large
strings. It is much more memory efficient.
o Be sure Dispose() gets called on IDisposable objects that you create locally within a method. This is most
commonly done in the Finally clause of a Try block. It’s done automatically when a Using statement[1] is
used.
o Nev er present debug information to yourself or the end user via the UI
(e.g. MessageBox). Use tracing and logging facilities to output debug
information.
o Gaps and exceptions to these guidelines should be discussed and
resolved with your application architect.....
0 commentaires: