Points to practice while designing/Programming:

Planning:

                                i.            Before starting to work on any project, understand thoroughly the project concept, the purpose and the work to be done.

                              ii.            A database should be thoroughly understood before doing any change or using its constituents in the project.

                            iii.            Before starting any project, a through implementation of the database should be done and the database should be reviewed multiple times in relation to the flow of the project as for any difficulty or necessary change that has to be done before starting the development..

                            iv.            Any change in the database, once the project has been moved forward, leads to chaos.

Input Screens:

                                 i.            Should look spacious to eyes and also be soothing. Should speak up their motto.

                               ii.            Less numbers of boxes.

                              iii.            Self communicating.

                             iv.            Dates should be visible for administrators and wherever necessary.

                               v.            Use IE while testing design first and then any other browser.

                             vi.            All code should be browser compatible.

                            vii.            Controls should be uniform and disciplined.

                          viii.            Always remember that a user is a naïve user and he doesn’t understand any technical terms, and then design the screen communication accordingly.

Validations:

                                 i.            Use script validations and then server side validations.

                                ii.            Control names used in scripts and those defined in controls should match cases. (Browser Compatibility).

                              iii.            Make the scripts fail proof so that there is seldom any need for the server side validations to post back.

                              iv.            Use strict validations as

a.        Date formats should be uniform. (Most users prefer dd/MM/yyyy).

b.       Email validations.

c.        For mobile number validations use starts with 7 or more series and 10 characters long.

d.       The results of validations check should be user friendly, ex. The field should get highlighted or/and should get focus.

Formatting:

                                 i.            Be very consistent with the code formatting, it is very necessary for the other person to understand your code. Each inner sentence  should be given a tab to give proper indent.

                                ii.            IE has three default font sizes, your page structure should look consistent through intermediate with these sizes.

                              iii.            The font you are using should be standard and easily available.

                              iv.            Font sizes used should not be too large neither too small.

                               v.            Use less number of tables.

                              vi.            Never use css class having alignment justified in form fields - as a result it shows text vertically down while entry and scrolling

                            vii.            When reports are too big, use small images and put text in the title tag of that image.

                           viii.            Most of the JavaScript functionalities should be framed into a common function and should be placed into a single JavaScript library.

                               ix.            Similarly, all the style applications should be done using style classes and those should be placed into a single style sheet.

                                x.             

Reports:

                                 i.            Give all necessary fields with the context of the report. A report should not only display the fields of a table but should be made more descriptive with a unique amalgamation of necessary information to frame a more intuitive and descriptive report.

                               ii.            If the field text is too large, use a image and display it as tool tip, the image/color etc should match the purpose of the information to be displayed.

                              iii.            Give all necessary filters.

                             iv.            The current date should be visible at the top-right or a feasible location.

                               v.            Apply paginations.( includes fixed records and

                             vi.            Give exporting options PDF/Excel etc.  And the exports should have proper header/footer.

                            vii.            If possible, use Page non refreshing filters.(use scripts wherever possible)

 Coding:

1. Any variable name should be self descriptive and most important is be consistent with the variable names you use. Ex. AdminApproved, Admin_approved, admin_Approved all are ok, but once you adopt one, it should be followed throughout the coding.
2. Variables should be carefully used and unnecessary global variables should be kept to the minimum. (Seldom use global variables).
3. All the Database related code should be kept in a separate library and should be accessed using functions.
4. All Query’s and stored procedures should be checked neatly for their optimality. A query that gives the right result is not always the best query.
5. Put comment above every function which gives the description of the parameters and the purpose of the function the comment language could be your own language, the motto is that it should describe the context..
6. Try to make the maximum use of the common library functions, and so while framing the library functions frame with the view that they will be reusable.
7. Check return values of junctions for error conditions, a error is unpredictable and all possible places where an error could occur should be handled and a through methodology should be written to properly/gracefully compensate.
8. Strictly separate business logic from the program.

 Conclusion:

• No programmer can ever implement all of these suggestions 100% of the time. Not only does one reach a point of diminishing returns, but also there will always be areas that are open to interpretation, opinion, and individual style.
• But just because perfection isn't achievable doesn't mean you shouldn't strive for it. In fact, the most important thing you can do is to identify the area(s) listed above where your program is most lacking and take steps to fix it. For example, your program might have excellent database handling routines but your variable names may be completely unintuitive.
• Half the battle is figuring out (and admitting) where your program needs improvement; the other half of the battle is doing something about it.
•  
•  
• Well well well, this is it all for now.....will come up soon......