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 :
guru1309@gmail.com

Thanks

Guru

shargaur wrote:
> Hi
>
> I am working on designing coding standard or guidlines in unix for my
> comapany quality process.

What do you mean by "guidelines in unix"? For what programming
language(s)? Since this is a shell newsgroup; just for a shell?
And, if so, for which shell? POSIX shell?

Janis

>
> 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 :
> guru1309@gmail.com
>
> Thanks
>
> Guru

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.

shargaur <guru1...@gmail.com> wrote:
> I am working on designing coding standard or guidlines in unix for my
> company quality process.
> Can any one suggest me some docs or links...

I'm wondering if it's not too late to contribute insofar as this was
probably a time dependant company task....

I have throught the years thought about and collected the relatively
few nontrivial links and resources pertainent to this very issue. As
everyone knows that scripting is so trivial such as never having
needed
to be developed the usual programmers' tools, including a debugger,
profiler, etcetera, I suppose that coding standards are not perceived
to be of importance either.... (yes, I'm being sarcastic

Probably the most relevant for you is:

"Bourne/Korn Shell Coding Conventions" by "Mike Shapiro"
<mike.shapiro@sun.com>
http://opensolaris.org/os/community/on/shellstyle/

Also, there are:

"Korn Shell Programming Advice From David Korn":
http://blogs.sun.com/chrisg/entry/ko...ng_advice_from

"Bash Style Guide and Coding Standard" by "Fritz Mehner" <mehner@fh-
swf.de>
http://lug.fh-swf.de/vim/vim-bash/St...deShell.en.pdf

There are many others, but none that I have found yet that are of
satisfactory quality.

You should be aware that I have disagreements with all of the above
resources -- but I suppose that following any one of them or selection
of rules is sufficient if it creates an internal standard for the
company.

=Brian