User talk:WP-Vikas Mishra

Page 2

WCF Document
Hi All

This is my second Doc file.

https://www.hallaminternet.com/assets/URL-tagging-image.png

Coding Standard Document Version 1.0
Introduction This document addresses some fundamental coding techniques and provides a collection of coding practices. The coding techniques are primarily those that improve the readability and maintainability of code, whereas the programming practices are mostly performance enhancements. Purpose The intention behind the documentation is to enforce the readability and maintainability of the codes with recommended standards to provide the followings.

1. Ease in understanding the codes by other developers. 2. Easiness in maintaining software systems, adding new features, modify existing features, fix bugs, or improve performance. Intended Audience All software developers and team leads. Coding Technique Coding techniques may have no impact on the functionality of the application rather they contribute to an improved comprehension of source code. The scope of coding standards and techniques is not just limited to .Net components but is also extended to mark up and db. query and procedures as well.

The coding techniques are divided into three sections: Names Comments Format Name It is recommended that the naming of different software elements are maintained in a uniform way across whole application. It should be meaningful as per the purpose and should be in sync with the type of the element. Variables Naming standards for variables are recommended as below.

1. Always use the meaningful name for the variables. 2. Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable name where appropriate. 3. Since most names are constructed by concatenating several words together, use mixed-case formatting to simplify reading them. In addition, to help distinguish between variables. use camel casing (documentFormatType) where the first letter of each word except the first is capitalized. 4. Boolean variable names should contain Is which implies Yes/No or True/False values, such as isFileFound. 5. Avoid using terms such as Flag when naming status variables, which differ from Boolean variables in that they may have more than two possible values. 6. For short-lived variables that may appear in only a few lines of code, still use a meaningful name. 7. For variable names, it is sometimes useful to include notation that indicates the scope of the variable, such as prefixing a g_ for global variables and m_ for module-level. 8. Constants should be all uppercase with underscores between words, such as NUM_DAYS_IN_WEEK. Also, begin groups of enumerated types with a common prefix, such as FONT_ARIAL and FONT_ROMAN. Methods/Routines 1. Avoid elusive names that are open to subjective interpretation, such as Analyze for routines. Such names contribute to ambiguity more than abstraction. 2. In object-oriented languages, it is redundant to include class names in the name of class properties, such as Book.BookTitle. Instead, use Book.Title. 3. Use the verb-noun method for naming routines that perform some operation on a given object, such as CalculateInvoiceTotal. 4. All overloads should perform a similar function. 5. Include a description of the value being returned, such as GetCurrentWindowName. SQL 1. When naming tables, express the name in the singular form. For example, use Employee instead of Employees. 2. When naming columns of tables, do not repeat the table name; for example, avoid having a field called EmployeeLastName in a table called Employee. 3. Do not incorporate the data type in the name of a column. This will reduce the amount of work needed should it become necessary to change the data type later. 4. Do not prefix stored procedures with sp_, because this prefix is reserved for identifying system-stored procedures. 5. In Transact-SQL, do not prefix variables with @@, which should be reserved for truly global variables such as @@IDENTITY. General guidelines 1. Avoid using typographical marks in naming, such as $, % etc. 2. Minimize the use of abbreviations. If abbreviations are used, be consistent in their use. An abbreviation should have only one meaning, each abbreviated word should have only one abbreviation. For example, if using min to abbreviate minimum, do so everywhere and do not later use it to abbreviate minute. 3. File and folder names, like procedure names, should accurately describe what purpose they serve. 4. Avoid reusing names for different elements, such as a routine called ProcessSales and a variable called iProcessSales. Comments Software documentation exists in two forms, external and internal. External documentation is maintained outside of the source code, such as specifications, help files, and design documents. Internal documentation is composed of comments that developers write within the source code at development time.

Following are recommended commenting techniques:

1. When modifying code, always keep the commenting around it up to date. 2. Comment as you code, because most likely there won't be time to do it later. Also, should you get a chance to revisit code you've written, that which is obvious today probably won't be obvious six weeks from now. 3. At the beginning of every routine, it is helpful to provide standard, boilerplate comments, indicating the routine's purpose, assumptions, and limitations. A boilerplate comment should be a brief introduction to understand why the routine exists and what it can do. 4. Avoid adding comments at the end of a line of code; end-line comments make code more difficult to read. 5. Avoid surrounding a block comment with a typographical frame. It may look attractive, but it is difficult to maintain. 6. Prior to check out or publishing the codes, remove all temporary or extraneous comments to avoid confusion during future maintenance work. 7. If you need comments to explain a complex section of code, examine the code to determine if you should rewrite it. If at all possible, do not document bad code—rewrite it. 8. Use complete sentences when writing comments. Comments should clarify the code, not add ambiguity. 9. Avoid the use of superfluous or inappropriate comments, such as humorous sidebar remarks. 10. Use comments to explain the intent of the code. They should not serve as inline translations of the code. 11. To prevent recurring problems, always use comments on bug fixes and work-around code, especially in a team environment. 12. Use comments on code that consists of loops and logic branches. These are key areas that will assist the reader when reading source code. 13. Separate comments from comment delimiters with white space. Doing so will make comments stand out and easier to locate when viewed without color clues. 14. Throughout the application, construct comments using a uniform style, with consistent punctuation and structure. 15. In case of bug fix or enhancement add the date and task details in the comments.

Coding Format Following are the standards to be followed for coding format standards across the work.

1. Always follow proper indentation across the codes, these indentation should be uniform in each module of the project/ 2. Except constants use mix case, recommended is camel case convention for the naming of variable, but for constant variable us all upper cases with underscores if required for multiple words (READ_LOG). 3. Always align opening and closing braces of loops and conditional blocks vertically. 4. Use the code lines and comments size as suitable to screen, scrolling should be avoided as much as possible. 5. When a line is broken across several lines, make it obvious that the line is incomplete without the following line. 6. When writing HTML, establish a standard format for tags and attributes, such as using all lowercase for tags and attributes. 7. Divide source code logically between physical files where as required. 8. Put each major SQL clause on a separate line so statements are easier to read and edit. 9. Do not use literal numbers or literal strings, such as For i = 1 To 7. Instead, use named constants, such as For i = 1 To NUM_DAYS_IN_WEEK, for ease of maintenance and understanding. 10. Break large, complex sections of code into smaller, comprehensible modules. Performance Codes All above were the recommendations for writing good codes with proper comments that makes it easier to maintain the code and helps the developer or team to understand and work even after at later stages. But apart from that there are certain guidelines which are specific to write the codes for gaining the optimum performance. Those guidelines are recommended as below.

1. Be selective in the choice of data type to ensure the size of a variable is not excessively large, size of the variable should be based on the anticipated memory requirement of the data. 2. Keep the lifetime of variables as short as possible when the variables represent a finite resource for which there may be contention, such as a database connection. 3. Keep the scope of variables as small as possible to avoid confusion and to ensure maintainability. 4. Use variables and routines for one and only one purpose. In addition, avoid creating multipurpose routines that perform a variety of unrelated functions. 5. When writing classes, avoid the use of public variables. Instead, use procedures to provide a layer of encapsulation and also to allow an opportunity to validate value changes. 6. Release the resources as soon as possible. As such, you should create objects as late as possible, and destroy them as early as possible to free resources. 7. Examine the expense of the object creation and the level of contention for resources to determine when resources should be acquired and released. 8. Try to use minimum transaction schemes, such as MTS or SQL Server, and minimize the scope and duration of transactions. 9. Be careful while using ASP Session variables in a Web farm environment. At a minimum, do not place objects in ASP Session variables because session state is stored on a single machine. Consider storing session state in a database instead. 10. Stateless components are preferred when scalability or performance are important. Design the components to accept all the needed values as input parameters instead of relying upon object properties when calling methods. Doing so eliminates the need to preserve object state between method calls. When it is necessary to maintain state, consider using alternative methods, such as maintaining state in a database. 11. Do not open data connections using a specific user's credentials. Connections that have been opened using such credentials cannot be pooled and reused, thus losing the benefits of connection pooling. 12. Develop and use error-handling routines. 13. Be specific when declaring objects, such as ADODB.Recordset instead of just Recordset, to avoid the risk of name collisions. 14. Require the use Option Explicit in Visual Basic and VBScript to encourage forethought in the use of variables and to minimize errors resulting from typographical errors. 15. Avoid the use of variables with application scope. 16. Use RETURN statements in stored procedures to help the calling program know whether the procedure worked properly. 17. Use Select Case or Switch statements in lieu of repetitive checking of a common variable using If…Then statements. 18. Never use SELECT *. Always be explicit in which columns to retrieve and retrieve only the columns that are required. 19. Refer to fields implicitly; do not reference fields by their ordinal placement in a recordsets or datatables. 20. Use stored procedures in lieu of SQL statements in source code to leverage the performance gains they provide. 21. Use a stored procedure with parameters instead of single line procedure call. 22. Verify the row count when performing DELETE operations. 23. Perform data validation at the client during data entry. Doing so avoids unnecessary round trips to the database with invalid data. 24. If possible, specify the primary key in the WHERE clause when updating a single row. 25. When using LIKE, do not begin the string with a wildcard character because SQL Server will not be able to use indexes to search for matching values. 26. Use WITH RECOMPILE in CREATE PROC when a wide variety of arguments are passed, because the plan stored for the procedure might not be optimal for a given set of parameters. 27. Use triggers only for data integrity enforcement and business rule processing and not to return information. 28. After each data modification statement inside a transaction, check for an error by testing the global variable @@ERROR. 29. Use forward-only/read-only recordsets. To update data, use SQL INSERT and UPDATE statements. 30. Never hold locks pending user input. 31. Use uncorrelated sub queries instead of correlated sub queries. 32. Tune the RecordSet.CacheSize property to what is needed. Using too small or too large a setting will adversely impact the performance of an application. 33. Bind columns to field objects when looping through recordsets. 34. For Command objects, describe the parameters manually instead of using Parameters.Refresh to obtain parameter information. 35. Explicitly close ADO Recordset and Connection objects to insure that connections are promptly returned to the connection pool for use by other processes. 36. Use adExecuteNoRecords for non-row-returning commands. Conclusion In real life with growing business complexities the softwares are becoming more and more complex and thus writing the codes becomes more complex too. We should have a focus on quality of codes which directly caters to the cost of maintenance of the piece of software. The above standards and procedures are the guidance which helps us in achieving these objectives by the way of implementing standards and regular review procedures.