Programmer

SQL SERVER – Good, Better and Best Programming Techniques

2011-08-21T01:58:00.000-07:00

April 28, 2007 by pinaldave

A week ago, I was invited to meeting of programmers. Subject of meeting was “Good, Better and Best Programming Techniques”. I had made small note before I went to meeting, so if I have to talk about or discuss SQL Server it can come handy. Well, I did not get chance to talk on that as it was very causal and just meeting and greetings. Everybody just talked about what they think about their job. I talked very briefly about SQL Server, my current job and some funny incident at work.

Everybody laughed big when I talked about funny bug ticket I received which was about – Client does not receive Email sent by system. Well, at the end it was resolved without any programming as client did not have email address and needed to open one.

Well, here is my note which I prepared to discuss in meeting. This is not complete and is not in very details. This note contains what I think is best programming technique in SQL. There are lots to add here and many opinion are very generic to SQL and other programming languages.

Notes prepared for “Good, Better and Best Programming Techniques” meeting

Do not prefix stored procedure with SP_ prefix. As they are first searched in master database, before it is searched in any other database.

Always install latest server packs and security packs.

Make sure your SQL Server runs on optimal hardware. If your operating system supports 64 bit SQL Server, install 64 bit SQL Server on it. Raid 10 Array.

Reduce Network Traffic by using Stored Procedure. Return only required result set from database. If application needs paging it should have done in SQL Server instead of at application level.

After running query check Actual Execution Plan for cost of the query. Query can be analyzed in Database Engine Tuning Advisor.

Use User Defined Functions sparsely, use Stored Procedures instead.

Stored Procedure can achieve all the tasks UDF can do. SP provides much more features than UDFs.

Test system with realistic data rather than sample data. Realistic data provides better scenario for testing and reveals problems with real system before it goes to production.

Do not use SELECT *, use proper column names to decrease network traffic and fewer locks on table.

Avoid Cursors as it results in performance degradation. Sub Query, derived tables, CTE can perform same operation.

Reduces the use of nullable columns.

NULL columns consumes an extra byte on each column used as well as adds overhead in queries. Also NULL is not good for logic development for programmers.

Reduce deadlocks using query hints and proper logic of order in columns.

Normalized database always increases scalability and stability of the system. Do not go over 3rd normal form as it will adversely affect performance.

Use WHERE clauses to compare assertive logic. Use IN rather than NOT IN even though IN will require more value to specify in clause.

BLOBS must be stored filesystem and database should have path to them only. If path is common stored them in application variable and append with filename from the BLOBColumnName.

Always perform referential integrity checks and data validations using constraints such as the foreign key and check constraints.

SQL Server optimizer will use an index scan if the ORDER BY clause is on an indexed column.

Stored Procedure should return same numbers of resultset and same columns in any input parameters. Result Set of Stored Procedure should be deterministic.

Index should be created on highly selective columns, which are used in JOINS, WHERE and ORDER BY clause.

Format SQL Code. Make it readable. Wrap it.

Use Column name in ORDER BY clause instead of numbers.

Do not use TEXT or NTEXT if possible. In SQL Server 2005 use VARCHAR(MAX) or NVARCHAR(MAX).

Join tables in order that they always perform the most restrictive search first to filter out the maximum number of rows in the early phases of a multiple table join.

Remember to SET NOCOUNT ON at the beginning of your SQL bataches, stored procedures, triggers to avoid network traffic. This will also reduct the chances of error on linked server.

Do not use temp tables use CTE or Derived tables instead.

Always take backup of all the data.

Never ever work on production server.

Ask someone for help if you need it. We all need to learn.

http://blog.sqlauthority.com/2007/04/28/sql-server-good-better-and-best-programming-techniques/

8 Deffensive Best Programming Practice

2011-08-21T01:56:00.000-07:00

Author: Manuel Lemos

Handle unexpected conditions
Process external systems data properly
Test your code
Monitor your site errors and act upon them
Do not disclose errors to the users
Damage control
Backup
Do what you can as you can never get defensive enough

http://www.phpclasses.org/blog/post/65-8-defensive-programming-best-practices-to-prevent-breaking-your-sites.html

Coding Techniques and Programming Practices in Visual Studio 6.0

2011-08-21T01:53:00.000-07:00

By:
Rob Caron
Microsoft Corporation

February 2000

Summary: This article provides coding techniques and programming practices for improving the quality of source code. (12 printed pages)
Introduction

Superior coding techniques and programming practices are hallmarks of a professional programmer. The bulk of programming consists of making a large number of small choices while attempting to solve a larger set of problems. How wisely those choices are made depends largely upon the programmer's skill and expertise.

This document addresses some fundamental coding techniques and provides a collection of coding practices from which to learn. The coding techniques are primarily those that improve the readability and maintainability of code, whereas the programming practices are mostly performance enhancements.

The readability of source code has a direct impact on how well a developer comprehends a software system. Code maintainability refers to how easily that software system can be changed to add new features, modify existing features, fix bugs, or improve performance. Although readability and maintainability are the result of many factors, one particular facet of software development upon which all developers have an influence is coding technique. The easiest method to ensure that a team of developers will yield quality code is to establish a coding standard, which is then enforced at routine code reviews.

Coding Standards and Code Reviews
Coding Techniques
Best Practices
Conclusion
Suggested Reading

Coding Standards and Code Reviews

A comprehensive coding standard encompasses all aspects of code construction and, while developers should exercise prudence in its implementation, it should be closely followed. Completed source code should reflect a harmonized style, as if a single developer wrote the code in one session. At the inception of a software project, establish a coding standard to ensure that all developers on the project are working in concert. When the software project will incorporate existing source code, or when performing maintenance upon an existing software system, the coding standard should state how to deal with the existing code base.

Although the primary purpose for conducting code reviews throughout the development life cycle is to identify defects in the code, the reviews can also be used to enforce coding standards in a uniform manner. Adherence to a coding standard can only be feasible when followed throughout the software project from inception to completion. It is not practical, nor is it prudent, to impose a coding standard after the fact.
Coding Techniques

Coding techniques incorporate many facets of software development and, although they usually have no impact on the functionality of the application, they contribute to an improved comprehension of source code. For the purpose of this document, all forms of source code are considered, including programming, scripting, markup, and query languages.

The coding techniques defined here are not proposed to form an inflexible set of coding standards. Rather, they are meant to serve as a guide for developing a coding standard for a specific software project.

The coding techniques are divided into three sections:

Names
Comments
Format

Names

Perhaps one of the most influential aids to understanding the logical flow of an application is how the various elements of the application are named. A name should tell "what" rather than "how." By avoiding names that expose the underlying implementation, which can change, you preserve a layer of abstraction that simplifies the complexity. For example, you could use GetNextStudent() instead of GetNextArrayElement().

A tenet of naming is that difficulty in selecting a proper name may indicate that you need to further analyze or define the purpose of an item. Make names long enough to be meaningful but short enough to avoid being wordy. Programmatically, a unique name serves only to differentiate one item from another. Expressive names function as an aid to the human reader; therefore, it makes sense to provide a name that the human reader can comprehend. However, be certain that the names chosen are in compliance with the applicable language's rules and standards.

Following are recommended naming techniques:
Routines

Avoid elusive names that are open to subjective interpretation, such as Analyze() for a routine, or xxK8 for a variable. Such names contribute to ambiguity more than abstraction.
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.
Use the verb-noun method for naming routines that perform some operation on a given object, such as CalculateInvoiceTotal().
In languages that permit function overloading, all overloads should perform a similar function. For those languages that do not permit function overloading, establish a naming standard that relates similar functions.

Variables

Append computation qualifiers (Avg, Sum, Min, Max, Index) to the end of a variable name where appropriate.
Use customary opposite pairs in variable names, such as min/max, begin/end, and open/close.
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 and routines, use Pascal casing (CalculateInvoiceTotal) for routine names where the first letter of each word is capitalized. For variable names, use camel casing (documentFormatType) where the first letter of each word except the first is capitalized.
Boolean variable names should contain Is which implies Yes/No or True/False values, such as fileIsFound.
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. Instead of documentFlag, use a more descriptive name such as documentFormatType.
Even for a short-lived variable that may appear in only a few lines of code, still use a meaningful name. Use single-letter variable names, such as i, or j, for short-loop indexes only.
If using Charles Simonyi's Hungarian Naming Convention, or some derivative thereof, develop a list of standard prefixes for the project to help developers consistently name variables. For more information, see "Hungarian Notation."
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 variables in Microsoft Visual Basic®.
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.

Tables

When naming tables, express the name in the singular form. For example, use Employee instead of Employees.
When naming columns of tables, do not repeat the table name; for example, avoid having a field called EmployeeLastName in a table called Employee.
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.

Microsoft SQL Server

Do not prefix stored procedures with sp_, because this prefix is reserved for identifying system-stored procedures.
In Transact-SQL, do not prefix variables with @@, which should be reserved for truly global variables such as @@IDENTITY.

Miscellaneous

Minimize the use of abbreviations. If abbreviations are used, be consistent in their use. An abbreviation should have only one meaning and likewise, 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.
When naming functions, include a description of the value being returned, such as GetCurrentWindowName().
File and folder names, like procedure names, should accurately describe what purpose they serve.
Avoid reusing names for different elements, such as a routine called ProcessSales() and a variable called iProcessSales.
Avoid homonyms when naming elements to prevent confusion during code reviews, such as write and right.
When naming elements, avoid using commonly misspelled words. Also, be aware of differences that exist between American and British English, such as color/colour and check/cheque.
Avoid using typographical marks to identify data types, such as $ for strings or % for integers.

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.

One of the challenges of software documentation is ensuring that the comments are maintained and updated in parallel with the source code. Although properly commenting source code serves no purpose at run time, it is invaluable to a developer who must maintain a particularly intricate or cumbersome piece of software.

Following are recommended commenting techniques:

When modifying code, always keep the commenting around it up to date.
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.
Avoid adding comments at the end of a line of code; end-line comments make code more difficult to read. However, end-line comments are appropriate when annotating variable declarations. In this case, align all end-line comments at a common tab stop.
Avoid using clutter comments, such as an entire line of asterisks. Instead, use white space to separate comments from code.
Avoid surrounding a block comment with a typographical frame. It may look attractive, but it is difficult to maintain.
Prior to deployment, remove all temporary or extraneous comments to avoid confusion during future maintenance work.
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. Although performance should not typically be sacrificed to make the code simpler for human consumption, a balance must be maintained between performance and maintainability.
Use complete sentences when writing comments. Comments should clarify the code, not add ambiguity.
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.
Avoid the use of superfluous or inappropriate comments, such as humorous sidebar remarks.
Use comments to explain the intent of the code. They should not serve as inline translations of the code.
Comment anything that is not readily obvious in the code.
To prevent recurring problems, always use comments on bug fixes and work-around code, especially in a team environment.
Use comments on code that consists of loops and logic branches. These are key areas that will assist the reader when reading source code.
Separate comments from comment delimiters with white space. Doing so will make comments stand out and easier to locate when viewed without color clues.
Throughout the application, construct comments using a uniform style, with consistent punctuation and structure.

Notes Despite the availability of external documentation, source code listings should be able to stand on their own because hard-copy documentation can be misplaced.

External documentation should consist of specifications, design documents, change requests, bug history, and the coding standard that was used.

Format

Formatting makes the logical organization of the code stand out. Taking the time to ensure that the source code is formatted in a consistent, logical manner is helpful to yourself and to other developers who must decipher the source code.

Following are recommended formatting techniques:

Establish a standard size for an indent, such as four spaces, and use it consistently. Align sections of code using the prescribed indentation.
Use a monospace font when publishing hard-copy versions of the source code.
Except for constants, which are best expressed in all uppercase characters with underscores, use mixed case instead of underscores to make names easier to read.
Align open and close braces vertically where brace pairs align, such as:

for (i = 0; i < 100; i++)
{
…
}

You can also use a slanting style, where open braces appear at the end of the line and close braces appear at the beginning of the line, such as:

for (i = 0; i < 100; i++){
…
}

Whichever style is chosen, use that style throughout the source code.
Indent code along the lines of logical construction. Without indenting, code becomes difficult to follow, such as:

If … Then
If … Then
…
Else
…
End If
Else
…
End If

Indenting the code yields easier-to-read code, such as:

If … Then
If … Then
…
Else
…
End If
Else
…
End If

Establish a maximum line length for comments and code to avoid having to scroll the source code window and to allow for clean hard-copy presentation.
Use spaces before and after most operators when doing so does not alter the intent of the code. For example, an exception is the pointer notation used in C++.
Put a space after each comma in comma-delimited lists, such as array values and arguments, when doing so does not alter the intent of the code. For example, an exception is an ActiveX® Data Object (ADO) Connection argument.
Use white space to provide organizational clues to source code. Doing so creates "paragraphs" of code, which aid the reader in comprehending the logical segmenting of the software.
When a line is broken across several lines, make it obvious that the line is incomplete without the following line.
Where appropriate, avoid placing more than one statement per line. An exception is a loop in C, C++, Visual J++®, or JScript®, such as for (i = 0; i < 100; i++).
When writing HTML, establish a standard format for tags and attributes, such as using all uppercase for tags and all lowercase for attributes. As an alternative, adhere to the XHTML specification to ensure all HTML documents are valid. Although there are file size trade-offs to consider when creating Web pages, use quoted attribute values and closing tags to ease maintainability.
When writing SQL statements, use all uppercase for keywords and mixed case for database elements, such as tables, columns, and views.
Divide source code logically between physical files.
In ASP, use script delimiters around blocks of script rather than around each line of script or interspersing small HTML fragments with server-side scripting. Using script delimiters around each line or interspersing HTML fragments with server-side scripting increases the frequency of context switching on the server side, which hampers performance and degrades code readability.
Put each major SQL clause on a separate line so statements are easier to read and edit, for example:

SELECT FirstName, LastName
FROM Customers
WHERE State = 'WA'

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.
Break large, complex sections of code into smaller, comprehensible modules.

Programming Practices

Experienced developers follow numerous programming practices or rules of thumb, which typically derived from hard-learned lessons. The practices listed below are not all-inclusive, and should not be used without due consideration. Veteran programmers deviate from these practices on occasion, but not without careful consideration of the potential repercussions. Using the best programming practice in the wrong context can cause more harm than good.

To conserve resources, be selective in the choice of data type to ensure the size of a variable is not excessively large.
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.
Keep the scope of variables as small as possible to avoid confusion and to ensure maintainability. Also, when maintaining legacy source code, the potential for inadvertently breaking other parts of the code can be minimized if variable scope is limited.
Use variables and routines for one and only one purpose. In addition, avoid creating multipurpose routines that perform a variety of unrelated functions.
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.
When using objects pooled by MTS, acquire resources as late as possible and release them as soon as possible. As such, you should create objects as late as possible, and destroy them as early as possible to free resources.
When using objects that are not being pooled by MTS, it is necessary to examine the expense of the object creation and the level of contention for resources to determine when resources should be acquired and released.
Use only one transaction scheme, such as MTS or SQL Server™, and minimize the scope and duration of transactions.
Be wary of 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.
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.
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.
Avoid the use of forced data conversion, sometimes referred to as variable coercion or casting, which may yield unanticipated results. This occurs when two or more variables of different data types are involved in the same expression. When it is necessary to perform a cast for other than a trivial reason, that reason should be provided in an accompanying comment.
Develop and use error-handling routines. For more information on error handling in Visual Basic, see the "Error Handling and Debugging" chapter of the Microsoft Office 2000/Visual Basic Programmer's Guide, available in the MSDN Library. For more information on error handling and COM, see "Error Handling" in the Platform SDK. For more information on error handling for Web pages, see http://msdn.microsoft.com/workshop/author/script/weberrors.asp.
Be specific when declaring objects, such as ADODB.Recordset instead of just Recordset, to avoid the risk of name collisions.
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.
Avoid the use of variables with application scope.
Use RETURN statements in stored procedures to help the calling program know whether the procedure worked properly.
Use early binding techniques whenever possible.
Use Select Case or Switch statements in lieu of repetitive checking of a common variable using If…Then statements.
Explicitly release object references.

Data-Specific

Never use SELECT *. Always be explicit in which columns to retrieve and retrieve only the columns that are required.
Refer to fields implicitly; do not reference fields by their ordinal placement in a Recordset.
Use stored procedures in lieu of SQL statements in source code to leverage the performance gains they provide.
Use a stored procedure with output parameters instead of single-record SELECT statements when retrieving one row of data.
Verify the row count when performing DELETE operations.
Perform data validation at the client during data entry. Doing so avoids unnecessary round trips to the database with invalid data.
Avoid using functions in WHERE clauses.
If possible, specify the primary key in the WHERE clause when updating a single row.
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.
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.
Stored procedure execution is faster when you pass parameters by position (the order in which the parameters are declared in the stored procedure) rather than by name.
Use triggers only for data integrity enforcement and business rule processing and not to return information.
After each data modification statement inside a transaction, check for an error by testing the global variable @@ERROR.
Use forward-only/read-only recordsets. To update data, use SQL INSERT and UPDATE statements.
Never hold locks pending user input.
Use uncorrelated subqueries instead of correlated subqueries. Uncorrelated subqueries are those where the inner SELECT statement does not rely on the outer SELECT statement for information. In uncorrelated subqueries, the inner query is run once instead of being run for each row returned by the outer query.

ADO-Specific

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.
Bind columns to field objects when looping through recordsets.
For Command objects, describe the parameters manually instead of using Parameters.Refresh to obtain parameter information.
Explicitly close ADO Recordset and Connection objects to insure that connections are promptly returned to the connection pool for use by other processes.
Use adExecuteNoRecords for non-row-returning commands.

Conclusion

Using solid coding techniques and good programming practices to create high quality code plays an important role in software quality and performance. In addition, by consistently applying a well-defined coding standard and proper coding techniques, and holding routine code reviews, a team of programmers working on a software project is more likely to yield a software system that is easier to comprehend and maintain.
Suggested Reading

Books:

McConnell, Steve. Code Complete. Redmond, WA: Microsoft Press, 1993.
McConnell, Steve. Software Project Survival Guide. Redmond, WA: Microsoft Press, 1998.
Maguire, Steve. Writing Solid Code. Redmond, WA: Microsoft Press, 1993.
Ranade and Nash. The Elements of C Programming Style. New York: McGraw-Hill, 1992.
Kernighan and Plauger. The Elements of Programming Style. New York: McGraw-Hill, 1982.
Caner, Cem, et al. Testing Computer Software, Second Edition. New York: Wiley Computer Publishing, 1999.
Hunt, Andrew, et al. The Pragmatic Programmer. Reading, MA: Addison-Wesley, 2000.
Holub, Allen. Enough Rope to Shoot Yourself in the Foot: Rules for C and C++ Programming. New York: McGraw-Hill, 1995.

MSDN Library Articles:

The Basics of Programming Model Design
Programming Best Practices with Microsoft Message Queuing Services (MSMQ)
Improving MDAC Application Performance, available from the Platform SDK.

MSDN Library Articles:

ASP Conventions: http://msdn.microsoft.com/workshop/server/asp/aspconv.asp
25+ ASP Tips to Improve Performance and Style: http://msdn.microsoft.com/workshop/server/asp/ASPtips.asp
ASP Guidelines: http://msdn.microsoft.com/workshop/server/asp/server122799.asp

http://msdn.microsoft.com/en-us/library/aa260844%28v=vs.60%29.aspx

Good Programming Tips

2011-08-21T01:48:00.000-07:00

These tips are meant to help our students with thier own programs. They are not mandatory but, if followed consistantly, will help them.
Tips:

DO NOT COPY FROM OTHER PEOPLE. When you do this you do not learn what you are supposed to learn by doing the assignment. You then cannot solve the same kinds of problems later. More information.
Keep up with your assigned readings and/or homework assignments. In many classes the lab assignments illustrate or extend what you are supposed to be learning in the class. Once you understand the concepts in use the programs become much easier. If you do not understand what you are meant to be coding how can you do it correctly? Click More information.
Use good programming style. This will help to make your code more readable. This greatly helps when you need to go back and debug your own program or need to change the code from one assignment to another. Poorly written code is hard to follow and leads to stupid errors in logic. It is also not easily portable from one program to another. More information.
Put good comments into the code, including algorithm description and comments for input and output for each function. This is done for the same reason as the previous suggestion. It makes your code more readable when you understand what the code is meant to do and what is input and output from each function. More information.
Break up your code into well-named and useable functions.By doing this you can easily port code from one assignment to another. You may not even need to change any code in many areas to move from one assignment to the next saving yourself a lot of time and effort better spent on the rest of the assignment. More information.
Design what your program needs to do ( break it down into algorithms and steps ) before you start coding. You will save yourself a lot of time by having a clear path for programming development. It also makes defining functions easier if they are defined first. Start with the complete program's defined task, break it down into course steps. These are your big functions. Then break these down again into helper functions and continue until you have small, easy to code blocks. More Information.
Use good descriptive variables in your functions. By doing this you make your code more easier to read and thus easier to debug. When naming the function's variables, give good names for what the variables do in the function, not the functionality of the variable in the complete program. This will make it more transportable. More Information.
Make backups of your work often. As much as we try to make computers as stable as possible, they still are prone to errors. So, if you backup your programs and any data that you cannot easily re-build to a subdirectory or to another storage location before you start to work, and every so often even while you are working, when something goes wrong you at least have something to go back to. More Information.
K.I.S.S. = Keep It Simple Stupid. This is an old programmer's adage. It reminds us not to do too much at one time. Break it down into steps and handle each problem in turn. If you try too much at once you cannot be sure which step failed. You then take more time going back and testing each thing than if you had proceeded more cautously.

http://lucas.cis.temple.edu/docs/labs/general/GoodProgramming.html

Good Programming Practices

2011-08-21T01:45:00.000-07:00

Start with a good design. Update the design documents regularly. Create additional design documents before adding major new features or functionality.
The program under development should be at all times functioning. The development process consists of adding new functionality without breaking existing functionality.
Work has to be divided into small incremental steps that can be typically accomplished and code-reviewed in one day. Even large-scale rewrites should be made incremental.
Every line of code written or modified undergoes peer review. The smallest team must contain at least two programmers so that they can code-review each other's changes.
Always attempt to work top-down in:

Design—start with high level objects.
Implementation—create top-level objects using low-level stubs.
Modification—change the top-level objects and the overall flow of control first. If necessary, use stubs, or fake new functionality using old implementation.

By:
http://www.relisoft.com/resource/resmain.html

Being a Good Programmer

2007-10-05T22:18:00.001-07:00

By: Robert L Read

To be a good programmer is difficult and noble. The hardest part of making real a collective vision of a software project is dealing with one's coworkers and customers. Writing computer programs is important and takes great intelligence and skill. But it is really child's play compared to everything else that a good programmer must do to make a software system that succeeds for both the customer and myriad colleagues for whom she is partially responsible. In this essay I attempt to summarize as concisely as possible those things that I wish someone had explained to me when I was twenty-one.

This is very subjective and, therefore, this essay is doomed to be personal and somewhat opinionated. I confine myself to problems that a programmer is very likely to have to face in her work. Many of these problems and their solutions are so general to the human condition that I will probably seem preachy. I hope in spite of this that this essay will be useful.

Computer programming is taught in courses. The excellent books: The Pragmatic ProgrammerPrag99], Code Complete [CodeC93], Rapid Development [RDev96], and Extreme Programming Explained [XP99] all teach computer programming and the larger issues of being a good programmer. The essays of Paul Graham[PGSite] and Eric Raymond[Hacker] should certainly be read before or along with this article. This essay differs from those excellent works by emphasizing social problems and comprehensively summarizing the entire set of necessary skills as I see them. [

In this essay the term boss to refer to whomever gives you projects to do. I use the words business, company, and tribe, synonymously except that business connotes moneymaking, company connotes the modern workplace and tribe is generally the people you share loyalty with.

Nature of Programming

2007-10-05T22:10:00.000-07:00

Computer programmers write, test, and maintain the detailed instructions, called programs, that computers must follow to perform their functions. Programmers also conceive, design, and test logical structures for solving problems by computer. Many technical innovations in programming—advanced computing technologies and sophisticated new languages and programming tools—have redefined the role of a programmer and elevated much of the programming work done today. Job titles and descriptions may vary, depending on the organization. In this occupational statement, computer programmers are individuals whose main job function is programming; this group has a wide range of responsibilities and educational backgrounds.

Computer programs tell the computer what to do—which information to identify and access, how to process it, and what equipment to use. Programs vary widely depending on the type of information to be accessed or generated. For example, the instructions involved in updating financial records are very different from those required to duplicate conditions on an aircraft for pilots training in a flight simulator. Although simple programs can be written in a few hours, programs that use complex mathematical formulas whose solutions can only be approximated or that draw data from many existing systems may require more than a year of work. In most cases, several programmers work together as a team under a senior programmer’s supervision.

Programmers write programs according to the specifications determined primarily by computer software engineers and systems analysts. (Separate statements on computer software engineers computer systems analysts appear elsewhere in the Handbook.) After the design process is complete, it is the job of the programmer to convert that design into a logical series of instructions that the computer can follow. The programmer codes these instructions in a conventional programming language such as COBOL; an artificial intelligence language such as Prolog; or one of the most advanced object-oriented languages, such as Java, C++, or ACTOR. Different programming languages are used depending on the purpose of the program. COBOL, for example, is commonly used for business applications, whereas Fortran (short for “formula translation”) is used in science and engineering. C++ is widely used for both scientific and business applications. Extensible Markup Language (XML) has become a popular programming tool for Web programmers, along with J2EE (Java 2 Platform). Programmers generally know more than one programming language and, because many languages are similar, they often can learn new languages relatively easily. In practice, programmers often are referred to by the language they know, such as Java programmers, or by the type of function they perform or environment in which they work—for example, database programmers, mainframe programmers, or Web programmers. and on

Many programmers update, repair, modify, and expand existing programs. When making changes to a section of code, called a routine, programmers need to make other users aware of the task that the routine is to perform. They do this by inserting comments in the coded instructions so that others can understand the program. Many programmers use computer-assisted software engineering (CASE) tools to automate much of the coding process. These tools enable a programmer to concentrate on writing the unique parts of the program, because the tools automate various pieces of the program being built. CASE tools generate whole sections of code automatically, rather than line by line. Programmers also use libraries of basic code that can be modified or customized for a specific application. This approach yields more reliable and consistent programs and increases programmers’ productivity by eliminating some routine steps.

Programmers test a program by running it to ensure that the instructions are correct and that the program produces the desired outcome. If errors do occur, the programmer must make the appropriate change and recheck the program until it produces the correct results. This process is called testing and debugging. Programmers may continue to fix these problems throughout the life of a program. Programmers working in a mainframe environment, which involves a large centralized computer, may prepare instructions for a computer operator who will run the program. (A separate statement on computer operators appears elsewhere in the Handbook.) Programmers also may contribute to a manual for persons who will be using the program.

Computer programmers often are grouped into two broad types—applications programmers and systems programmers. Applications programmers write programs to handle a specific job, such as a program to track inventory within an organization. They also may revise existing packaged software or customize generic applications which are frequently purchased from vendors. Systems programmers, in contrast, write programs to maintain and control computer systems software, such as operating systems, networked systems, and database systems. These workers make changes in the instructions that determine how the network, workstations, and central processing unit of the system handle the various jobs they have been given and how they communicate with peripheral equipment such as terminals, printers, and disk drives. Because of their knowledge of the entire computer system, systems programmers often help applications programmers determine the source of problems that may occur with their programs.

Programmers in software development companies may work directly with experts from various fields to create software—either programs designed for specific clients or packaged software for general use—ranging from games and educational software to programs for desktop publishing and financial planning. Programming of packaged software constitutes one of the most rapidly growing segments of the computer services industry.

In some organizations, particularly small ones, workers commonly known as programmer-analystscomputer systems analysts elsewhere in the Handbook.) Advanced programming languages and new object-oriented programming capabilities are increasing the efficiency and productivity of both programmers and users. The transition from a mainframe environment to one that is based primarily on personal computers (PCs) has blurred the once rigid distinction between the programmer and the user. Increasingly, adept end users are taking over many of the tasks previously performed by programmers. For example, the growing use of packaged software, such as spreadsheet and database management software packages, allows users to write simple programs to access data and perform calculations. are responsible for both the systems analysis and the actual programming work. (A more detailed description of the work of programmer-analysts is presented in the statement on

Significant Points of Programming

2007-10-05T22:08:00.000-07:00

Sixty-seven percent of computer programmers held a college or higher degree in 2004; nearly half held a bachelor’s degree, and about 1 in 5 held a graduate degree.
Employment is expected to grow much more slowly than that for other computer specialists.
Prospects likely will be best for college graduates with knowledge of a variety of programming languages and tools; those with less formal education or its equivalent in work experience are apt to face strong competition for programming jobs.

Web Links

2005-12-22T17:35:00.000-08:00

Listen to Cool Musics
Get Along with your Friends
Get Involve
Google AdSense
Inside AdSense

Getting Started

2005-12-20T03:21:00.000-08:00

Just want to have my own website, with the use of my
little knowledge about HTML coding....