Skip to content

How should be a code written

August 5, 2009
tags:

Definition:

The code is a version of computer program that it will be compiled before it runs in a computer.
This code is also called source code. The source code consists of programming statements and these are
created in a text editor and saved as a file with certain name.

Some other definitions for Code:

1. A systematically arranged and comprehensive collection of laws.

2. A systematic collection of regulations and rules of procedure or conduct: a traffic code.

3. A system of signals used to represent letters or numbers in transmitting messages.

4. A system of symbols, letters, or words given certain arbitrary meanings, used for b transmitting messages requiring secrecy or brevity.

5. A system of symbols and rules used to represent instructions to a computer; a computer
program.

How should be a code written:

A good code should work perfectly and there should not be any bug. To write a code perfectly the code should contain certain properties. They are

* Simplicity
* Readability
* Modularity
* Layering
* Design
* Efficiency
* Elegance
* Clarity

Simplicity :

The code should be simple in the sense that the code should be written in 5 lines rather writing it in 10 lines. It does not meant that the code should not only minimized but efficient too.
The simplicity should be implemented in all the organization, Implementation and Design.

Readability :

The code should be easy to read by others that in the way that they can continue the flow what we have coded before. The best ways for making our code readable are writing proper comments for the function, following coding conventions, naming the functions and variables in the way that they should give a clear picture for what they are used and to be used

Modularity :

The modularity in the sense the code should built of several small modules and the integration of the entire module should provide the ultimate output. And at the same times the modules should be reusable. For example if you written a module for performing ￯﾿ᄁ￯ᄒタ￯ᄒワAdd￯﾿ᄁ￯ᄒタ? operation and at the same time another project need the same ￯﾿ᄁ￯ᄒタ￯ᄒワAdd￯﾿ᄁ￯ᄒタ? functionalities then we can re use the code by invoking it into the project rather than typing it again .

Layering :

The code should be layered. The layers can be view, model, controller, data base. The purpose of layering the code is to partition in the basis functionality or purpose will help us to easily identify the areas with it. Simply the code should be loosely coupled. To achieve this ￯﾿ᄁ￯ᄒタ￯ᄒワLayering￯﾿ᄁ￯ᄒタ? there are certain techniques called Framework and Patterns. The following diagram shows us the idea about Layering

Design :

The design is too important than coding. The coding will be easier when we holds a clear design. It is of no use in debugging with out a designed coding practice. Design in the sense that if we need to execute functionality we should first design the work flow of that functionality, then we have to look-in for a suitable coding language and resources. If everything is in a smooth way then the coding will be easy and effective.

Efficiency :

The performance of the code should be fast and economical. Economical in the sense the code should not occupy unwanted memory space. The memory management is very important. The loading time of the program should be quick At the function level, we can optimize the code even at the time of testing. But at high level, we must plan for performance.

Elegance :

Elegance means beauty. It is hard to describe but easy to recognize. Elegance combines simplicity, efficiency, and brilliance, and produces a feeling of pride. Elegance is when you replace a procedure with a table, or realize that you can use recursion￯﾿ᄁ￯ᄒタ￯ᄒヤwhich is almost always elegant.

Clarity :

The fundamental challenge of programming is managing complexity. Simplicity, readability, modularity, layering, design, efficiency, and elegance are all the ways to achieve clarity. Clarity of code, Clarity of design. Clarity of purpose these are the most important things to be taken in to picture while coding. Bad programs are less often a failure of coding skill than of having a clear goal. If the code is not clear we cannot explain it to others and in the same way a new person cannot understand the code until it is clear.

Reliability :

The results of the program must be correct, which not only includes a correct code implementation but also reduction of error such as resulting from data conversion and prevention of typical errors like overflow, underflow or zero division.

Robustness :

A program must written in a way that it can predict situations of data type conflict and all other incompatibilities which result in run time errors and stop the program. The focus of this aspect is the interaction with the user and the handling of error messages.

Portability:

An efficient program should work in any software and hardware environment, or at least without relevant reprogramming. Java is the best example.

Coding Conventions:

There should be certain convention or principles in the way to name their classes, structs, Variables, Macros, enumeration and constants.

Class Names :

Most class names are formed with a prefix letter C, T, R, or M. Briefly, the meaning of these is as follows:
￯﾿ツ￯ᄒᄋ C: heap-allocated classes, that are derived from a base class CBase
￯﾿ツ￯ᄒᄋ T: value classes, that do not own any external object
￯﾿ツ￯ᄒᄋ R: resource classes, that contain handles to a real resource which is maintained elsewhere
￯﾿ツ￯ᄒᄋ M: interface classes, that define abstract protocol definitions that are implemented by derived classes
Struct :
Structure types are considered as similar to T classes, as they should not have external objects, and are normally given names beginning with T.

Variable Name :

Member variables￯﾿ᄁ￯ᄒタ￯ᄒル names begin with i, e.g. iMember. This makes it easy to check that certain cleanup-related rules are being obeyed. Arguments￯﾿ᄁ￯ᄒタ￯ᄒル names begin with a, e.g. aControl or aIndex. Local variables￯﾿ᄁ￯ᄒタ￯ᄒル names have no initial letter. Global variables are usually avoided, but when used, their names begin with a capital letter.

Function Names:

Functions ￯﾿ᄁ￯ᄒタ￯ᄒル names indicate what they do. They are usually verbs. One exception is ￯﾿ᄁ￯ᄒタ￯ᄒワgetter￯﾿ᄁ￯ᄒタ? functions: for a function which returns the value of a member variable, the function name is usually the name of the variable, without the leading i:

Why Code Convention:

Code conventions are important to programmers for a number of reasons:
￯﾿ツ￯ᄒᄋ 80% of the lifetime cost of a piece of software goes to maintenance.
￯﾿ツ￯ᄒᄋ Hardly any software is maintained for its whole life by the original author.
￯﾿ツ￯ᄒᄋ Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.
￯﾿ツ￯ᄒᄋ If you ship your source code as a product, you need to make sure it is as well packaged and clean as any other product you create.

Beginning Comments:
All source files should begin with a c-style comment that lists the class name, version information, date, and copyright notice:

/*

* Classname

*

* Version information

*

* Date

*

* Copyright notice

*/

Package and Import Statements
The first non-comment line of most source files is a package statement. After that, import statements can follow. For example:

package java.awt;

import java.awt.peer.CanvasPeer;

Indentation:

Line Length:

Avoid lines longer than 80 characters. Hence they are not handled well by many terminals and tools.

Wrapping Lines:
When an expression will not fit on a single line, break it according to these general principles:
Break after a comma.
Break before an operator.
Prefer higher-level breaks to lower-level breaks.
Align the new line with the beginning of the expression at the same level on the previous line.
If the above rules lead to confusing code or to code that’s squished up against the right margin, just indent 8 spaces instead.
Here is an example of breaking method calls:

someMethod(longExpression1, longExpression2, longExpression3,

longExpression4, longExpression5);

var = someMethod1(longExpression1,

someMethod2(longExpression2,

longExpression3));

Comments:

Implementation Comments Format:

Block Comments:
Block comments are used to provide descriptions of files, methods, data structures and algorithms. Block comments may be used at the beginning of each file and before each method. They can also be used in other places, such as within methods. Block comments inside a function or method should be indented to the same level as the code they describe.
A block comment should be preceded by a blank line to set it apart from the rest of the code.

/*

* Here is a block comment.

*/

Single Line Comments;

Short comments can appear on a single line indented to the level of the code that follows. If a comment can’t be written in a single line, it should follow the block comment format

if (condition) {

/* Handle the condition. */

}

Trailing Comments:

Very short comments can appear on the same line as the code they describe, but should be shifted far enough to separate them from the statements. If more than one short comment appears in a chunk of code, they should all be indented to the same tab setting.
Here’s an example of a trailing comment in Java code:

if (a == 2) {

return TRUE; /* special case */

} else {

return isPrime(a); /* works only for odd a */

}

End-Of-Line Comments:

The // comment delimiter can comment out a complete line or only a partial line. It shouldn’t be used on consecutive multiple lines for text comments; however, it can be used in consecutive multiple lines for commenting out sections of code. Examples of all three styles follow:

if (foo > 1) {

// Do a double-flip.

}

else {

return false; // Explain why here.

}

//if (bar > 1) {

//

// // Do a triple-flip.

// …

//}

//else {

// return false;

//}

Seven Practical Steps to Delivering More Secured Software:

Software Security is more serious problem and it needs more and more attention. Here are the seven steps to deliver a software more secured.

1. Quickly evaluate the current state of software security and create a plan for dealing with it throughout the development life-cycle.

2. Specify the risks and threats to the software so they can be eliminated before they are introduced.

3. Review the code for security vulnerabilities introduced during development.

4. Test and verify the code for vulnerabilities.

5. Build a gate to prevent applications with vulnerabilities from going into production.

6. Measure the success of the security plan so that the process can be continually improved.

7. Educate stakeholders about security so they can implement the security plan.

Advertisements
No comments yet

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: