Pages

Categories

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.

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

All variables / identifiers that represent words or phrases must be English words or phrases.

Use small caps for single word identifier/variable

Capitalize the first letter of interior words in all multi-word identifiers.

Avoid using all upper case characters in an identifier. (unless it is a CONSTANT)

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.

All identifiers should be pronounceable (in English) without having to spell out more than one letter.

Use Spaces before and after (, ), ‘,’ , and commas.

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.

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

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.

Don’t put wrong comments i.e.

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

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.

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.

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.

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.

Write comments that describe blocks of statements rather than individual statements.

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.

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.

– Use Date in the document name. (Only for individual files, which are not linked like webpages). i.e. dosstationary-21-02-2001, dosstationary(21-02-2001).

– Keep file names bellow 27 characters.

– Use same text case (lower / upper) for the files in a same folder. Preferred to keep all the files in lower case.

– Don’t use underscores, spaces etc. in file names.

– If you need to break the rule, be consistent about it.

Folder Structure

– Keep names short

– Nest folders within folders

– Separate ongoing and completed work

– Store like with like. (same file type in a separate folder, like all images in one folder for a project)

You can follow couple of folder structure techniques

Creating a Parent Folder for each project (Folder Name: Project Title), create sub bolder of Archive, and put all the archived files in there (how to archive is described later in this document) Create a folder under the parent folder with CURRENT WORK, latest or something as you like with the current files which you are working on.

Create different folders with dates in the name, for taking backup of large files, like webpages and programs.

Create a single folder with multiple files (file names should have dates) incase if file to work on is single one, e.g. Single page design, or some document of scope for any project.

Making Archives and Taking Backups

For tacking backups and maintaining daily archives, WIN RAR is very handy tool.

– Select the folder you want to take backup of.

– Click on “Add to archive…”

– Give a name to you archive according to “FILE NAMES” section of this document, always put DATE in the file name

– Select “Time” tab in “Archive name and parameters” window of WIN RAR

– Select “Newer than” option from the drop down in the “Files to process” section

– Write 1 in “days” text input box.

– Click “OK”

This process will add all the files which are modified within last 24 hours into the archive, with complete folder structure and names, and leaving all the older files behind, making a complete update archive of newly worked files.

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.

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.