Programming Guidelines: How to program

Programming Guidelines

Define Programming Languages

First select a programming environment to work on, the coder must know the limitations, cons and pros of the language, and must know how to use the language. If he don’t know what can be done with this programming language it is useless to use the language.

Look for already done code / libraries / classes

Check the codebase for already created code / libraries / classes to use them in the new projects and to improve the project’s coding. If codebase don’t have the functions and classes which you are seeking for, create your own files and classes to store the functions or group of functions, as they will keep the specific code separate from the original code, and also can be re-used, in any other website for the same functionality.

Finalize the Design and CSS before you go for real coding.

For small projects or simple HTML pages, finalizing the design and CSS before development of the website will save time of development, and for large projects, although it is not possible in some cases that we get a design completed with all the CSS needed, as we may need new elements and CSS classes as we proceed developing the website. But it is wise to complete as much design and CSS elements as possible before starting the development, as this will save the time in future.

Keep URLs short

It is a good practice that while developing the websites, try keeping the URLs short, so they should be easy to remember by the users, and they are helpful in Search Engine Optimization.

For example http://mywebsite.com/users/profile/ compared with http://mywebsite.com/new_users/2009/user_profile_public.html

Thumbnails

Thumbnails are necessary in site performance and load time of the pages, always try to use thumbnails. If required create the thumbnails from Adobe Photoshop, or in case of large websites where users will be uploading the images by their own, creating thumbnails on the fly and saving them on the server is also a great practice.


Variable Names

  1. All variables / identifiers that represent words or phrases must be English words or phrases.
  2. Use small caps for single word identifier/variable
  3. Capitalize the first letter of interior words in all multi-word identifiers.
  4. Avoid using all upper case characters in an identifier. (unless it is a CONSTANT)
  5. Avoid all identifier abbreviations in your programs. When necessary, use standardized abbreviations or ask someone to review your abbreviations. Whenever you use abbreviations in your programs, create a “data dictionary” in the comments near the names’ definition that provides a full name and description for your abbreviation.
  6. All identifiers should be pronounceable (in English) without having to spell out more than one letter.
  7. Use Spaces before and after (, ), ‘,’ , and commas.
  8. Breaking code in to 80 Column lines. It will be easy to read by other programmers, and programmers don’t have to use the horizontal scrollbars to read the code.
  9. For statements that are too long to fit on one physical 80-column line, you should break the statement into two (or more) lines at points in the statement that will have the least impact on the readability of the statement. Best is to use breaks immediately after low-precedence operators or after commas.


Commenting

  1. Always put comments before a function or the part you have worked on describing the change done, and the reasons. Also use at least one line space between the real code and comments.
  2. Don’t put wrong comments i.e.

$a = 10; // setting the variable ‘a’ value to 12;

  1. Don’t put unnecessary comments (same like above) as this is very simple, and will waste the time of coder in future. Also it will be hard to maintain the comments on slight change in the code. E.g. changing value of $a to something else and then modifying the comments.
  2. If there are comments at the beginning of the file, describing the functionality covered, and who last worked on the file, should be updated on every change. Outdated comments are always creating problem.
  3. Comment as you go. Keep writing the comments along the programming. Leaving comments to be written on the end will consume a lot of time, and management will not allow the time line only for writing the comments for the whole project.
  4. Write comments with proper English and avoid telling jokes or using slang, sexy words in comments, as at some point others will surely be reading your code.
  5. Write comments that describe blocks of statements rather than individual statements.
  6. Use comments to prepare the reader for what is to follow. Someone reading the comments should be able to have a good idea of what the following code does without actually looking at the code. Note that this rule also suggests that comments should always precede the code to which they apply.
  7. Comments should describe a routine’s limitations, assumptions, and any side effects.


Keep Code Simple

Keep the code simple, so everyone can understand the code, these also include the variable names and commenting sections of this document. This will help editing the code later by any other programmer. i.e. ‘ternary operator’ (my_variable = (x > 10)?”foo”:”bar”;) is not understood by all the programmers who have shifted themselves from ASP to PHP or any other language which is not similar to C, so a simple if statement may increase couple of lines, but is far easy to read by large number of programmers. (It didn’t meant that I am not in favor of ternary operator, if it can be educated then that’s best)

Identify the true problem

Before start fixing any problem, make sure you have identified the real problem, as it happened many times when there is some problem; developers start fixing that without going to identify it first, thus wasting time.

There are number of ways to identify the problems. (i) Looking from the beginning of the process, and (ii) going back step by step from the problem out to start of the process.

(iii) One other way is to create a separate test case, just to check the solution you need to implement, as this will save the time and fuss of working in a thousand line of code. When you get stuck, stop, build the SMALLEST test case that proves the point, and then proceed ahead with the regularly scheduled programming.

Learn to prototype.

The two ends of error are to go spec out an extensive solution without a proof of concept. OR to build the entire technology feature complete before proving it out. Prototypes don’t do everything; they just show you are headed in the right direction before you get to the wrong location.

DRY

Don’t Repeat Yourself or DRY. Dry software doesn’t just copy/paste/edit when it can be encapsulated. Without getting ultra OO you can benefit from DRY software development. Reuse moves edits to one location, makes life-cycle support better and often starts to make short term development faster and more stable.

Errors Logs

Many servers and websites keep an ‘Error Log’. These logs tell the time and date and the file/line number in details including what was the error. Always look for the error logs on the server and local machine while developing any website, as they store important information, and they are helpful in identifying the error and fixing them.

Don’t consider a solution as a final procedure,

If you can create a simple solution then please do so, as there is always place for improvement in the code.

These are not the complete guidelines for programming, and there is a lot of space for improvement. This documents will keep evolving.

Web: Designing

NOTE: This information is gathered from different sources over internet few days back, and i dont remember the sources yet. Copyrighted material is belongs to the actual owner, and i don’t own this information.

Web Design Guidelines

–          Web Designs can be created in any designing application, as it is not necessary to use the vectors or the simple jpegs.

–          Best approach for creating web designs is to work on Adobe Photoshop, as it is easy to maintain the layers.

–          Important to note that we should aim for less download time for the all the pages.

–          Use the image format according to requirements in this order. JPEG, GIF, and PNG as last.

–          Gather the information for the website layout from the client.

Web Page Template

–          Select a design theme and pattern

–          All images and layouts should be 72 DPI and use the RGB colorspace.

–          Include a site color palette example with the layout. Below is an example of a color palette. When creating a webpage layout, knock up the design grid first in Illustrator, then a color palette on a hidden layer for fast color selection.

–          Keep site consistent throughout. Don’t have a different background color on every page, or a different navigation scheme. Try to have at least one small icon or logo on every page on your site, somewhere at the top preferably, so that people will know they are still at your site.

Index / Landing Page

–          Keep your home page / landing page below 100KB if possible, or reduce the content and images so it should load within 15 seconds.

–          If page have vertical scroll bar, it should not require more than four clicks on the scrollbar to get to the bottom of a page.

–          Keep main page as small as possible and include most important elements / services / products.

Web Page Navigation

–          Make navigation on your site easy. Have navigation links at the top, bottom, left or right side of the page.

–          Keep the number of clicks required to get from main page to any other page, down to three or four.

Web Page Fonts

–          When placing text within web page, always be consistent with fonts. Don’t use different fonts throughout pages. The standard fonts used on the Internet are Arial and Verdana. The standard text size is 2.

–          Headlines require a larger font size, are a bit different. A popular headline font used is Georgia.

Web Page Background and Text Colors

–          Busy backgrounds make text difficult to read and draw the attention away from the text. In addition, always be consistent with background theme on each page of your site.

–          Select your colors very carefully, as colors affect your mood and will have an affect on your visitors as well.

–          Get client geographical location, it is very necessary to identify the desired layout and color theme for the website layout.

This color chart is solely based on my own experiences.

Colors names are taken from http://oreilly.com/catalog/wdnut/excerpt/color_names.html

Region

Colors

Indo / Pak

Lightseagreen, limegreen, silver, white, honeydew,

China

Crimson, firebrick, saddlebrown, tomato, white, navy

Middle East

Dodgerblue, lightsteelblue, azure, honeydew,

Germany

Darkorange, orange, yellowgreen, black, orangered,

Africa

Navy, teal, darkolivegreen, purple, limegreen,

U.S.A.

Gray, linen, peru, whitesmoke

These colors are not what everyone from the region will accept but it is for the majority. If client already told about the colors or already have a website, we must consider the colors wisely.

Screen Sizes & Layout

Create a layout from one of the screen sizes below and use “safe dimensions” if it is required not to have any scrollbars on the website.

Screen Size

Safe Dimension

800px X 600px

768px X 410px

1024px X 768px

1000px X 575px

Print Material

NOTE: This information is gathered from different sources over internet few days back, and i dont remember the sources yet. Copyrighted material is belongs to the actual owner, and i dont own this information.

Design Guidelines

–          What Formats to Work on

  • Artwork designed in Corel Draw 12 with fonts converted to curves or InDesign CS3 with fonts converted are preferred. Be aware though that jpegs and tiffs are images vs. vectors which are used in drawing programs such as InDesign and Corel Draw.

–          Page Size & Layout

  • When designing your artwork, create a single file in your layout program for all your pages (do not create a new file for each page). While designing, make your page size that of the final trim size, do not insert “crop marks” or “printer’s marks”.
  • Prepare vector art, such as a company logo, in a Draw program like Illustrator, CorelDraw or Freehand. Save these images as EPS files and import them into the page layout.
  • If you want graphic objects or backgrounds to print to the edge of the page, these should be made to extend 3mm beyond the edge of the page in the layout. This is called bleed. The overlapping 3mm will be trimmed off, but if it’s not there in the first place, slight inaccuracies in cutting could leave a thin white border along one or more edges of the page.
  • Keep all the text and pictures that do not bleed at least 5mm away from your trim size or fold lines on each side (in business cards bookmarks and Greeting Cards, this can be reduced to 2mm).
  • The table below sets out some of our products with their trim size (finished size) bleed size and text frame (text margin). For any layouts not included in this table, just use the guidelines above or send us a mail and we will help you set up the margins.

Product

Size

Finished Size

Bleed Size

Text Frame

Business Cards

Standard

90mm x 50mm

96mm x 56mm

86mm x 46mm

Credit Card

85mm x 55mm

91mm x 61mm

81mm x 51mm

Flyers

A4

297m x 210mm

303mm x 216mm

287mm x 200mm

A5

210mm x 148mm

216mm x 154mm

200mm x 138mm

A6

148mm x 105mm

154mm x 111mm

138mm x 95mm

DL

210mm x 99mm

216mm x 105mm

200mm x 89mm

Posters

A0

1189mm x 840mm

1195mm x 846mm

1179mm x 830mm

A1

840mm x 594mm

846mm x 600mm

830mm x 584mm

A2

594mm x 420mm

600mm x 426mm

584mm x 410mm

A3

420mm x 297mm

426mm x 303mm

410mm x 287mm

Bookmarks

Standard

180mm x 50mm

186mm x 56mm

176mm x 46mm

Greeting Cards

Medium

158mm x 90mm

164mm x 96mm

154mm x 86mm

Large

184mm x 104mm

190mm x 110mm

180mm x 100mm