On Apr 29, 12:24pm, shargaur <guru1...@gmail.com> wrote:
> Hi
>
> I am working on designing coding standard or guidlines in unix for my
> comapany quality process.
>
> Can any one suggest me some docs or links...
>
> Really appreciate your .
>
> In case you want to forward any documents. please feel to drop mail :
> guru1...@gmail.com
>
> Thanks
>
> Guru

The question is a bit open-ended, but I'll give you my thoughts on
this. When coding, the development team should for any organization
(or the development manager) should come up with a set of standards
that they all agree to use in their coding. There is nothing worse for
a developer than to try and debug a piece of software that has been
created by one person using one standard, and then modified by another
person using different standards.

Here are some good tips to follow:

Use remarks in a useful manner.
========================
I know coders that use absolutely NO comments in the software, and
others that end up trying to put a comment for almost every line. The
ideal software has adequate remarks at the beginning to tell people
what the program is used for, and will give details on each function/
procedure call, or any calls to external modules or scripts. They will
document particularly clever or complex code, but don't bother
commenting stuff that is plain to see what it does.

Our coding standard lists the program name, usage, syntax, expected
permissions or ownerships,
and the author and date of creation at the beginning in a set of
comments.


Stick with one standard for variable names
===============================
In Korn Shell, you can use uppercase or lowercase letters to define a
variable. We try to always use the same standard for variables so that
it is readily apparent what the name is when looking at the code. We
use uppercase names, relatively short but descriptive, and use the ${}
standards. So we might have ${SUBTTL} or ${TMPFILE} or ${BKPDIR} as a
variable.


Arrange for system-wide reserved variables
================================
You may have the need to create an output logfile in many programs, or
want something that will show the version of the software or the name
of the program. This is common to many scripts or programs. By using
the same name in various programs (such as ${PGMVER}, ${PGMLOG}, or $
{PGMNAME}) you can make it simpler to document or know what the
variable is for.


Standard Flags
===============
Set up your scripts to use a standard flag that will display a
screen, whether it is "-h", "-", or "-?". This makes it easier for
users and administrators.


Debugger Tools
============
There are times when debugging a script or program that is not working
right on a particular server would be ful. However, many times
this involves going in and modifying the code, perhaps recompiling,
and then running it over again. You can set up a variable called
"DEBUG" that can be used to modify code behaviour. If set to "0", it
means do not do debugging, if set to 1 or higher, you can arrange to
do various levels of debugger, from simple logging of messages to a
debugger log, to the point of setting full debugging on and tracking
each command being issued.


These are just a few ideas that you should come up with and follow
religiously in your organization. But remember, these rules are only
good if everyone is on the same page. If you are doing it one way and
everyone else is doing it differently, that is a sure way to cause
delays in development and QA.