SKILL coding style

Dear ALL,

as I'm going to write my first application in SKILL I would like to
ask the community for coding style. Is there any common document or
agreement how to name e.g ids , objects ...
I know it is usually up to the editor, but sticking to some common
rules may be helpfull to all of us.

Any input / comment is welcome

Rolf

 

Hi Rolf,

My attempt is :

1. There are basically 2 skill writing styles: the lisp-like and the C-
like
Please give a look at this post :
http://groups.google.com/group/comp...3495ce177365?lnk=gst&q=defun#f2e63495ce177365

Personally, I use the C-like when I create my own script from scratch
or either C/Lisp when it comes for me to maintain an existing code.
I'm trying to fellow what has been by the originator. It's really a
matter of background and feeling. I know JimK is a big fun of the
Lisp, maybe Andrew ...

Cadence functions are following the Hungarian Notation (That's the
name I think ) : dbOpenCellViewByType(), dbCreateRect ... but there
are few exceptions : get_filename ... For the variables, what you
often see in the cds docs are prefixes :
l_list for lists
t_string for strings
and so on ...
Once again, It's up to you ...

CDS features a skill development environment with some tool that tels
you how good is your skill code: Lint, Profiler and Surveyor.
Skill lint analyzes your code for many common errors and inefficient
techniques. A score of 100% would be great, even though less does not
mean your code is bad. There are some global variables (forms, cdf)
that prevents you from hitting the 100%. The skill Profiler tells you
where you code is taking the most time and memory. The surveyor tells
you how to upgrade your skill to meet the compatibility with your
current version version of the skill interpreter.
You launch The skill development environment from CIW-> tools. I'm
using Lint for all my scripts ...

For me, a good program is :
1. A nice program (tabulated, ...)
2. Commented
3. That I can read and understand the year after I've written it
4. that my colleagues can read, understand and maintain ...

That said, I'm a microelectronics engineer myself and it's worth
having the viewpoint of a computer scientist. Anybody here .... ?

Cheers,
Riad.

 

Rolf,

you can get the best info on coding style from John Gianni or Andrew
Beckett.

As Riad mentionned, usual coding practices ( identing, commenting,
coding for readability rather than performance/compactness except as
necessary...) apply. You will rather code in procedural style if the
maintenance is to be done by non-lisp people, and you code in lisp style
otherwise. If you do not code within cadence, you need a capitalised
prefix for your globals (funcs and global vars). So use true CamelCase
for these, _not_ the hungarianStyle.

My opinion is also, keep a little flesh in your procedures. It is too
easy to write 30 procedures per file, each with only a few lines. I
would say that you can better use lambdas when the function is a
one-shot that is defined for readability more than reuse. That is enough
to avoid over-nesting of parenthesis, while keeping the number of
defined functions at bay too. Also, remember to do all the assertion and
type-check you need, and the data reduction/conversion if you want to
accept multiple types : the language will not help much and you may have
some ungraceful failures if you do not take care of that using all the
isFoo() or barp() predicates .

have a nice skill ride.