On Tue, 18 Jun 2002 09:54:54 +0200, Guillermo Rodriguez Garcia wrote:
>This may be a dumb question, but is there something like an official
>coding style guide or so?
>
>I mean, conventions on how to name variables, labels, etc.
>(mixed uppercase, all lowercase with underscores, etc etc)
There's not any one single standard. Coding style is often a hotly
debated topic among programmers, maybe as much or more as which
programming language to use!
Jack Ganssle has an article on his web site regarding programming
conventions. I'm not saying it's perfect but it's an example of how
some people do things.
> > This may be a dumb question, but is there something like an
> > official coding style guide or so?
It depends. If you are writing a PIC application for a large company and
you will be sending your source around, then the company itself may have
certain standards. If you are writing in C and compiling to PIC, then you
should just follow C guidelines, which I'm sure there are scores of. If
you're writing code for yourself and your own private projects, I wouldn't
think it matters at all.
At 07:27 18/06/2002 -0500, Tim McDonough wrote:
>On Tue, 18 Jun 2002 09:54:54 +0200, Guillermo Rodriguez Garcia wrote:
>
> >This may be a dumb question, but is there something like an official
> >coding style guide or so?
> >
> >I mean, conventions on how to name variables, labels, etc.
> >(mixed uppercase, all lowercase with underscores, etc etc)
>
>There's not any one single standard. Coding style is often a hotly
>debated topic among programmers, maybe as much or more as which
>programming language to use!
>
>Jack Ganssle has an article on his web site regarding programming
>conventions. I'm not saying it's perfect but it's an example of how
>some people do things.
>
>http://www.ganssle.com/articles.htm
That looks interesting (I guess you refer to fsm.doc) but it
doesn't cover PIC assembler, which is what I was after.
Thanks anyway,
G.
>The best advice is probably to develop a style that is understandable
>to you and stick with it.
>
>Tim
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways. See http://www.piclist.com/#archives for details.
At 08:40 18/06/2002 -0400, Erik Jacobs wrote:
> > > This may be a dumb question, but is there something like an
> > > official coding style guide or so?
>
>It depends. If you are writing a PIC application for a large company and
>you will be sending your source around, then the company itself may have
>certain standards.
I'm writing PIC assembler for a small company (for which I work) but
we don't still have a coding standard for assembler. We do have one
for Java, and another one for C[/C++], but none for PIC assembler yet :)
Thanks anyway,
G.
> If you are writing in C and compiling to PIC, then you
>should just follow C guidelines, which I'm sure there are scores of. If
>you're writing code for yourself and your own private projects, I wouldn't
>think it matters at all.
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways. See http://www.piclist.com/#archives for details.
part 1 1227 bytes content-type:text/plain; (decoded 7bit)
There IS an absolute, final authoritative style guide, written by one of the
most highly recognized, authoritative, obfuscatory and prevaricative experts
in the field, myself (emphasis on the prevaricative title) ;-) It's
small enough to attach.
Seriously, a few searches should turn up a lot of opinions, mostly
conflicting, on C style.
--Lawrence
{Original Message removed} part 2 3818 bytes content-type:application/x-zip-compressed; (decode)
I printed it out the last time it was on the list.
Been pinned to my office wall ever since.
Although words like "obfusticated" tend to "obfusticate" the lecture, it
is still a good guide!
>
> There IS an absolute, final authoritative style guide, written by one of the
> most highly recognized, authoritative, obfuscatory and prevaricative experts
> in the field, myself (emphasis on the prevaricative title) ;-) It's
> small enough to attach.
>
> Seriously, a few searches should turn up a lot of opinions, mostly
> conflicting, on C style.
>
> --Lawrence
>
At 05:07 18/06/2002 +0200, wouter van ooijen & floortje hanneman wrote:
> > This may be a dumb question, but is there something like an
> > official coding style guide or so?
>
>Of course there are such guides, which one do you want?
Insufficient specification. Helps in which direction? Obfusciation,
readability, compilation speed, readability for non-cumpter geeks (try
cobol!), small source files, ....
The wonderful thing about standards is that there are so many to choose
from... <GRIN>
I personally try to use all lower case for keywords, Underscores in
variables, All uppercase for defines or constants.
Type of variable as first part of variable name, Since labels are variable
of type "address" I try to use "at" or "a" as the first letter of labels,
but they also denote the start of functions or procedures so sometimes I use
"f" or "p" or even "s" or "sub."
Actually, when I'm writing code for someone else, I try to find out what
language standards they follow. If the boss knows asm I try to get a look at
his code, If he or she knows Pascal I use that style, if it's BASIC
(shudder) I use that style. I even define macros to make some of the more
obvious commands match the "language" I'm trying to look like. Macros are
great for making code easy to understand.... if the macros make sense.
And as Olin will probably say, comments are the best coding style. I don't
comment every single line, but I write the program in pseudo code comments
first and then "compile" each comment line into the ASM code that does what
the comment says. No more than a few lines of ASM per line of comments. The
tricky part is not changing the ASM code without updating the comments. I
also keep a log of the design decisions at the start of the file with the
date and what we were thinking at that point.
At 07:07 18/06/2002 +0200, wouter van ooijen & floortje hanneman wrote:
> > One that helps ? :)
>
>Insufficient specification. Helps in which direction? Obfusciation,
>readability, compilation speed, readability for non-cumpter geeks (try
>cobol!), small source files, ....
Readability and maintainability, anti-obfuscation, don't care about
compilation speed or size source files.
Thanks a lot! This is the kind of advice I was after :)
At 11:05 18/06/2002 -0700, James Newton. Admin 3 wrote:
>The wonderful thing about standards is that there are so many to choose
>from... <GRIN>
:))
>I personally try to use all lower case for keywords, Underscores in
>variables, All uppercase for defines or constants.
>
>Type of variable as first part of variable name, Since labels are variable
>of type "address" I try to use "at" or "a" as the first letter of labels,
>but they also denote the start of functions or procedures so sometimes I use
>"f" or "p" or even "s" or "sub."
At the end I think I'm going to adopt the following:
- only tabs, no spaces. 4-spaces per indentation level.
- one-character extra indentation for "bit-skip"-like operations.
- C-style all-lowercase names for variables, with underscores separating
words:
>Actually, when I'm writing code for someone else, I try to find out what
>language standards they follow. If the boss knows asm I try to get a look at
>his code, If he or she knows Pascal I use that style, if it's BASIC
>(shudder) I use that style. I even define macros to make some of the more
>obvious commands match the "language" I'm trying to look like. Macros are
>great for making code easy to understand.... if the macros make sense.
>
>And as Olin will probably say, comments are the best coding style. I don't
>comment every single line, but I write the program in pseudo code comments
>first and then "compile" each comment line into the ASM code that does what
>the comment says. No more than a few lines of ASM per line of comments. The
>tricky part is not changing the ASM code without updating the comments. I
>also keep a log of the design decisions at the start of the file with the
>date and what we were thinking at that point.
Here's a small addition to this (finally) serious list:
The first line of my C or ASM file is a title, with the name of the file.
Then the author, date, and purpose of the code
Next (as James Mentioned) is a series of comments identifying each revision
level and why the revision was made and by whom, for instance:
1 LL 1 Jun 2002 New Program
2 LL 2 Jun 2002 Found bug in rs232() function
3. RW 3 jun 2002 Fixed bug introduce in fixing the last bug
4. LL 4 jun 2002 Found another bug that was introduced in fixing
the second bug which fixed the first bug etc. etc.
Each revision is saved in a separate file, in case I need to refer to it
later. I save a revision each morning first thing before I work on any
code, and then every time I do anything that either 1. works or 2. took a
long time to code.
Then I always clearly identify all I/O points near the top of the file, and
keep this list up to date
// PORTB
#byte PORTB = 0x06
#define Relay 0 // Relay on RB0 etc. etc.
ASM files are usually commented with Pseudocode as well as clear
descrtiptions of what is trying to be accomplished
C files are more readable, so I just try to de-obfuscate the code a little.
On Wed, 19 Jun 2002, Guillermo Rodriguez Garcia wrote:
<snip>
> At the end I think I'm going to adopt the following:
And now I think you'll see the opinions come spewing in from all angles...
> - only tabs, no spaces. 4-spaces per indentation level.
I personally prefer spaces and no tabs. Why? because there is no standard
tab spacing, but 8 is the most common. However, if you display your
4-space tabs as 8-space tabs, the document will look very messy. (Not to
mention, the piclist archive of your tabbed files will look horrible).
OTOH, If I know your files are formatted with tab equal to 8 spaces, I can
run expand/unexpand (unix utilities) to fix it.
> I always clearly identify all I/O points near the top of the file,
> and keep this list up to date
>
> // PORTB
> #byte PORTB = 0x06
> #define Relay 0 // Relay on RB0 etc. etc.
... and then, later in your code, you mistakenly write:
BSF PORTA,Relay ;Turn on the relay
or
PORTA.Relay = 1; // Turn on the relay.
You can eliminate this common source of errors by including the
port name in your #define:
#define Relay PORTB,0
or
#define Relay PORTB.0
then:
BSF Relay ;Turn on the relay in assembly.
or
Relay = 1; // Turn on the relay in C.
-Andy
=== Andrew Warren -- aiwKILLspamcypress.com
=== Principal Design Engineer
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation
> -----Original Message-----
> From: Scott Dattalo [SMTP:.....scottKILLspam.....DATTALO.COM]
> Sent: Wednesday, June 19, 2002 12:07 AM
> To: EraseMEPICLISTspam_OUTTakeThisOuTMITVMA.MIT.EDU
> Subject: Re: [PIC]: coding style
>
> On Wed, 19 Jun 2002, Guillermo Rodriguez Garcia wrote:
>
> <snip>
>
> > At the end I think I'm going to adopt the following:
>
> And now I think you'll see the opinions come spewing in from all angles...
>
> > - only tabs, no spaces. 4-spaces per indentation level.
>
> I personally prefer spaces and no tabs. Why? because there is no standard
> tab spacing, but 8 is the most common. However, if you display your
> 4-space tabs as 8-space tabs, the document will look very messy. (Not to
> mention, the piclist archive of your tabbed files will look horrible).
>
> OTOH, If I know your files are formatted with tab equal to 8 spaces, I can
> run expand/unexpand (unix utilities) to fix it.
>
> Scott
>
Another one of those things that has arguments for and against I guess, but
I prefer tabs simply because it's so much faster to tidy up any indenting
and generaly moving the cursor around. Any decent editor should let you set
the number of "spaces" per tab, although I would have to agree about the
archive problem. 8 space tabs are way too large IMO and make the program
messier rather than neater and easier to follow, 3 or 4 spaces seems a good
compromise.
At 17:52 18/06/2002 -0500, Lawrence Lile wrote:
>Here's a small addition to this (finally) serious list:
>
>The first line of my C or ASM file is a title, with the name of the file.
>
>Then the author, date, and purpose of the code
>
>Next (as James Mentioned) is a series of comments identifying each revision
>level and why the revision was made and by whom, for instance:
>
>1 LL 1 Jun 2002 New Program
>2 LL 2 Jun 2002 Found bug in rs232() function
>3. RW 3 jun 2002 Fixed bug introduce in fixing the last bug
>4. LL 4 jun 2002 Found another bug that was introduced in fixing
>the second bug which fixed the first bug etc. etc.
>
>Each revision is saved in a separate file, in case I need to refer to it
>later. I save a revision each morning first thing before I work on any
>code, and then every time I do anything that either 1. works or 2. took a
>long time to code.
Well, all of the above is nicely managed by CVS automatically:
author, date, version history, etc. plus you can check out any
version from any date, etc.
If you don't already use CVS (or any other version control system)
I recommend to have a look, even if it is only to keep track of
changes in source code in a single machine.
>Then I always clearly identify all I/O points near the top of the file, and
>keep this list up to date
>
>// PORTB
>#byte PORTB = 0x06
>#define Relay 0 // Relay on RB0 etc. etc.
>
>ASM files are usually commented with Pseudocode as well as clear
>descrtiptions of what is trying to be accomplished
>
>C files are more readable, so I just try to de-obfuscate the code a little.
>
>--Lawrence
>
At 16:07 18/06/2002 -0700, Scott Dattalo wrote:
>On Wed, 19 Jun 2002, Guillermo Rodriguez Garcia wrote:
>
><snip>
>
> > At the end I think I'm going to adopt the following:
>
>And now I think you'll see the opinions come spewing in from all angles...
That's what I wanted :))
> > - only tabs, no spaces. 4-spaces per indentation level.
>
>I personally prefer spaces and no tabs. Why? because there is no standard
In fact I made a mistake above. What I actually meant is only
spaces, no tabs. Tabs may look different according to the settings
everyone has and I don't want to depend on that.
>tab spacing, but 8 is the most common. However, if you display your
>4-space tabs as 8-space tabs, the document will look very messy. (Not to
>mention, the piclist archive of your tabbed files will look horrible).
:)
Thanks!
G.
>OTOH, If I know your files are formatted with tab equal to 8 spaces, I can
>run expand/unexpand (unix utilities) to fix it.
>
>Scott
>
>--
>http://www.piclist.com hint: The PICList is archived three different
>ways. See http://www.piclist.com/#archives for details.
At 09:39 19/06/2002 +0100, Michael Rigby-Jones wrote: {Quote hidden}
> > -----Original Message-----
> > From: Scott Dattalo [SMTP:spamBeGonescottspamBeGoneDATTALO.COM]
> > Sent: Wednesday, June 19, 2002 12:07 AM
> > To: TakeThisOuTPICLISTEraseMEspam_OUTMITVMA.MIT.EDU
> > Subject: Re: [PIC]: coding style
> >
> > On Wed, 19 Jun 2002, Guillermo Rodriguez Garcia wrote:
> >
> > <snip>
> >
> > > At the end I think I'm going to adopt the following:
> >
> > And now I think you'll see the opinions come spewing in from all angles...
> >
> > > - only tabs, no spaces. 4-spaces per indentation level.
> >
> > I personally prefer spaces and no tabs. Why? because there is no standard
> > tab spacing, but 8 is the most common. However, if you display your
> > 4-space tabs as 8-space tabs, the document will look very messy. (Not to
> > mention, the piclist archive of your tabbed files will look horrible).
> >
> > OTOH, If I know your files are formatted with tab equal to 8 spaces, I can
> > run expand/unexpand (unix utilities) to fix it.
> >
> > Scott
> >
>Another one of those things that has arguments for and against I guess, but
>I prefer tabs simply because it's so much faster to tidy up any indenting
>and generaly moving the cursor around. Any decent editor should let you set
>the number of "spaces" per tab,
Uhm.. any decent editor also provides facilities to tidy up indenting
_even if you don't use tabs_. EditPlus can indent or de-intent blocks
of data with a single keypress, regardless of whether you use tabs or
spaces, also allows you to do vertical selection, etc. :)
> although I would have to agree about the
>archive problem. 8 space tabs are way too large IMO and make the program
>messier rather than neater and easier to follow, 3 or 4 spaces seems a good
>compromise.
>
>Regards
>
>Mike
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email RemoveMElistservTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body
> Here's a small addition to this (finally) serious list:
>
> The first line of my C or ASM file is a title, with the name of the file.
Yes - when printed, it's good to know exactly which file it is.
> Then the author, date, and purpose of the code
The date should be handled as the first revision, below. Putting it here
is just redundant.
> Next (as James Mentioned) is a series of comments identifying each revision
> level and why the revision was made and by whom, for instance:
>
> 1 LL 1 Jun 2002 New Program
> 2 LL 2 Jun 2002 Found bug in rs232() function
> 3. RW 3 jun 2002 Fixed bug introduce in fixing the last bug
> 4. LL 4 jun 2002 Found another bug that was introduced in fixing
> the second bug which fixed the first bug etc. etc.
Yes, except put the newest line first, as it's generally the most important
one.
> Each revision is saved in a separate file, in case I need to refer to it
> later. I save a revision each morning first thing before I work on any
> code, and then every time I do anything that either 1. works or 2. took a
> long time to code.
This quickly gets out of hand. Once you get to this level, you should be
using a revision-control system such as RCS, CVS, etc.
Such tools also enforce the creation of revision dates/comments (above),
but to be honest, I still tend to put them in the file as well, because I
can edit them there at the same time that I'm making the actual changes.
The RCS comments get put in only at the end, when checking in new versions,
and I tend to be in a hurry at that time, and produce very short and cryptic
descriptions.
I have to second the comment about hard tabs with nonstandard widths.
Just use spaces, then no one will have to guess what your tab width is.
I've seen 2, 3, 4, and 8, and it's a real pain when you try to edit someone
else's code.
> - only tabs, no spaces. 4-spaces per indentation level.
Bad idea. You have no way of knowing how other people's tab stops are set,
so this will pretty much guarantee your code will look like crap when other
people view it.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
> ... and then, later in your code, you mistakenly write:
>
> BSF PORTA,Relay ;Turn on the relay
> or
> PORTA.Relay = 1; // Turn on the relay.
>
> You can eliminate this common source of errors by including the
> port name in your #define:
>
> #define Relay PORTB,0
> or
> #define Relay PORTB.0
>
> then:
>
> BSF Relay ;Turn on the relay in assembly.
> or
> Relay = 1; // Turn on the relay in C.
This works fine for addressing the individual port bit, but does not help
you if you need to access the whole register containing the bit, or need to
use the bit number other than with the port register.
A better way it to use my /INBIT and /OUTBIT preprocessor directives. The
project include file would contain:
/outbit relay porta 0 0 ;relay on when 1, off when 0
This automatically causes a bunch of assembler constants to be defined.
Here are some example instructions that could be found in a module using the
include file. These are just code snippets not meant to be useful code:
dbankif relay_reg ;set banks for access to RELAY port reg
bsf relay_pin ;turn on the relay
.
.
bsf shadow, relay_bit ;enable relay in the shadow copy
.
.
dbankif relay_tris
bsf relay_tris, relay_bit ;float the relay output pin
There is a lot more to the preprocessor. All the details can be found at http://www.embedinc.com/pic/. You can follow the links to download your own
copy of all the PIC development tools.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
At 04:32 19/06/2002 -0700, Dave Tweed wrote: {Quote hidden}
>Lawrence Lile <RemoveMEllileKILLspamTOASTMASTER.COM> wrote:
>
> > Here's a small addition to this (finally) serious list:
> >
> > The first line of my C or ASM file is a title, with the name of the file.
>
>Yes - when printed, it's good to know exactly which file it is.
>
> > Then the author, date, and purpose of the code
>
>The date should be handled as the first revision, below. Putting it here
>is just redundant.
>
> > Next (as James Mentioned) is a series of comments identifying each revision
> > level and why the revision was made and by whom, for instance:
> >
> > 1 LL 1 Jun 2002 New Program
> > 2 LL 2 Jun 2002 Found bug in rs232() function
> > 3. RW 3 jun 2002 Fixed bug introduce in fixing the last bug
> > 4. LL 4 jun 2002 Found another bug that was introduced in
> fixing
> > the second bug which fixed the first bug etc. etc.
>
>Yes, except put the newest line first, as it's generally the most important
>one.
>
> > Each revision is saved in a separate file, in case I need to refer to it
> > later. I save a revision each morning first thing before I work on any
> > code, and then every time I do anything that either 1. works or 2. took a
> > long time to code.
>
>This quickly gets out of hand. Once you get to this level, you should be
>using a revision-control system such as RCS, CVS, etc.
And before getting to that level as well :) CVS can make your
life so much easier..
>Such tools also enforce the creation of revision dates/comments (above),
>but to be honest, I still tend to put them in the file as well, because I
>can edit them there at the same time that I'm making the actual changes.
>The RCS comments get put in only at the end, when checking in new versions,
>and I tend to be in a hurry at that time, and produce very short and cryptic
>descriptions.
>
>"Guillermo Rodriguez Garcia" <guilleSTOPspamspam_OUTIIES.ES> wrote:
> > - only tabs, no spaces. 4-spaces per indentation level.
>
>I have to second the comment about hard tabs with nonstandard widths.
Yes, I also second that comment :) My original text was wrong,
my bad. I never use tabs.
G.
>Just use spaces, then no one will have to guess what your tab width is.
>I've seen 2, 3, 4, and 8, and it's a real pain when you try to edit someone
>else's code.
>
>-- Dave Tweed
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email spamBeGonelistservSTOPspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body
> At 04:32 19/06/2002 -0700, Dave Tweed wrote:
> >Lawrence Lile <spamBeGonellileKILLspamTOASTMASTER.COM> wrote:
> >
> > > Here's a small addition to this (finally) serious list:
> > >
> > > The first line of my C or ASM file is a title, with the name of the
file.
> >
> >Yes - when printed, it's good to know exactly which file it is.
> >
> > > Then the author, date, and purpose of the code
> >
> >The date should be handled as the first revision, below. Putting it here
> >is just redundant.
> >
> > > Next (as James Mentioned) is a series of comments identifying each
revision
> > > level and why the revision was made and by whom, for instance:
> > >
> > > 1 LL 1 Jun 2002 New Program
> > > 2 LL 2 Jun 2002 Found bug in rs232() function
> > > 3. RW 3 jun 2002 Fixed bug introduce in fixing the last bug
> > > 4. LL 4 jun 2002 Found another bug that was introduced in
> > fixing
> > > the second bug which fixed the first bug etc. etc.
> >
> >Yes, except put the newest line first, as it's generally the most
important
> >one.
> >
> > > Each revision is saved in a separate file, in case I need to refer to
it
> > > later. I save a revision each morning first thing before I work on
any
> > > code, and then every time I do anything that either 1. works or 2.
took a {Quote hidden}
> > > long time to code.
> >
> >This quickly gets out of hand. Once you get to this level, you should be
> >using a revision-control system such as RCS, CVS, etc.
>
> And before getting to that level as well :) CVS can make your
> life so much easier..
>
> >Such tools also enforce the creation of revision dates/comments (above),
> >but to be honest, I still tend to put them in the file as well, because I
> >can edit them there at the same time that I'm making the actual changes.
> >The RCS comments get put in only at the end, when checking in new
versions,
> >and I tend to be in a hurry at that time, and produce very short and
cryptic {Quote hidden}
> >descriptions.
> >
> >"Guillermo Rodriguez Garcia" <.....guillespam_OUTIIES.ES> wrote:
> > > - only tabs, no spaces. 4-spaces per indentation level.
> >
> >I have to second the comment about hard tabs with nonstandard widths.
>
> Yes, I also second that comment :) My original text was wrong,
> my bad. I never use tabs.
>
> G.
>
> >Just use spaces, then no one will have to guess what your tab width is.
> >I've seen 2, 3, 4, and 8, and it's a real pain when you try to edit
Yow! - CVS looks complex and smells like it has security issues. Do I
understand correctly that it stores your project documents on somebody
else's server? This gives me the shivers. If I was doing a far-flung GNU
project with a bunch of volunteer programmers this might be a good system to
use.
I think I'll stick to revision notes at the beginning of my C source file,
that's pretty simple.
"Individual developers who want the safety net of a version control system can run one on their local machines. Development teams, however, need a central server all members can access to serve as the repository for their code. In an office, that's no problem -- just stick the repository on a server on the local network. For open-source projects...well, it's still no problem, thanks to the Internet. CVS has built-in client-server access methods so that any developer who can connect to the Internet can access files on a CVS server."
Eoin
>>> RemoveMEllilespamBeGoneTOASTMASTER.COM 06/19/02 01:23PM >>>
Yow! - CVS looks complex and smells like it has security issues. Do I
understand correctly that it stores your project documents on somebody
else's server? This gives me the shivers. If I was doing a far-flung GNU
project with a bunch of volunteer programmers this might be a good system to
use.
I think I'll stick to revision notes at the beginning of my C source file,
that's pretty simple.
> Yow! - CVS looks complex and smells like it has security issues. Do I
> understand correctly that it stores your project documents on somebody
> else's server? This gives me the shivers. If I was doing a far-flung GNU
> project with a bunch of volunteer programmers this might be a good system to
> use.
Though it can be very complex in full blown use, it can also be pretty
simple. I have CVS set up on my own local Linux system and only I use it
for my own projects. It's been a godsend... you can produce a complete
history of changes, revert back to the last working version, all kinds of
things you wish you could do when you accidentally step on something. It
takes a little while to learn (couple hours or so), and I still have not
been able to make heads or tails of the Winows CVS client, though I'm sure
it's simpler than I'm making it.
If you have a UNIX system of some sort around, I highly recommend it -
even for a single person.
Unfortunately, with programming teams of a few or more,
it becomes very difficult to maintain control of the code,
and without a system such as this, there will usually be
lost code due to 2 or more people modifying a piece of
code at the same time, and not coordinating properly. CVS
et al handle this coordination for you really well.
There are 2 general flavors of SCCSes (Source Code Control
Systems) that I've run into ... the library system (such as
CVS) and the versioning system (such as Envy). The first
let's one person check out a file at a time while others can
only have it read-only. The other lets multiple people have
write access, but will put a separate version ID on each in a
special format, so that it is evident at build/compile time
that multiple changes had been made and need to be
merged". Each has its pros & cons.
In any programming team, the server is usually local to the
group, so it's not a big security issue. And one DB for all
code makes backups sooooo much easier and transparent.
This is sort of like Hungarian notation. The S,F and B symbols appear
grouped in any symbol listing and are easy to read. It also reduces
confusions (is it a file? is it a constant?).
> On Wed, 19 Jun 2002, Lawrence Lile wrote:
>
> > Yow! - CVS looks complex and smells like it has security issues. Do I
> > understand correctly that it stores your project documents on somebody
> > else's server? This gives me the shivers. If I was doing a far-flung
GNU
> > project with a bunch of volunteer programmers this might be a good
system to {Quote hidden}
> > use.
>
> Though it can be very complex in full blown use, it can also be pretty
> simple. I have CVS set up on my own local Linux system and only I use it
> for my own projects. It's been a godsend... you can produce a complete
> history of changes, revert back to the last working version, all kinds of
> things you wish you could do when you accidentally step on something. It
> takes a little while to learn (couple hours or so), and I still have not
> been able to make heads or tails of the Winows CVS client, though I'm sure
> it's simpler than I'm making it.
>
> If you have a UNIX system of some sort around, I highly recommend it -
> even for a single person.
>
> Dale
>
> --
> http://www.piclist.com#nomail Going offline? Don't AutoReply us!
> email EraseMElistserv@spam@mitvma.mit.edu with SET PICList DIGEST in the body
>
>
I had about the same reaction to CVS when I was looking to implement better
revision control.
Someone else on the list recommended QVCS a while back. I tried it, bought
it, and now can't imagine developing software without it. Go to http://www.qumasoft.com/ and check it out.
Dale
--
"Curiosity is the very basis of education and if you tell me that
curiosity killed the cat, I say only the cat died nobly."
- Arnold Edinborough
On Wed, 19 Jun 2002, Lawrence Lile wrote:
> I notice it is GNU - is it free or do you have to pay for it?
At 12:23 19/06/2002 -0500, Lawrence Lile wrote:
>Yow! - CVS looks complex
It's not _that_ complex.
> and smells like it has security issues.
Like?
> Do I
>understand correctly that it stores your project documents on somebody
>else's server?
Not necessarily. It can be your corporate server, or it can
be your own local machine. It is more powerful when it is a central
server shared by several developers, but of course it can also be
installed locally on YOUR machine and then nobody needs to access
it at all.
G.
> This gives me the shivers. If I was doing a far-flung GNU
>project with a bunch of volunteer programmers this might be a good system to
>use.
>
>I think I'll stick to revision notes at the beginning of my C source file,
>that's pretty simple.
>
>--Lawrence
>
>{Original Message removed}
At 13:11 19/06/2002 -0500, Lawrence Lile wrote:
>I notice it is GNU - is it free or do you have to pay for it?
>
>--Lawrence
>
>{Original Message removed}
At 21:09 19/06/2002 +0300, Peter L. Peres wrote: {Quote hidden}
> > This may be a dumb question, but is there something like an
> > official coding style guide or so?
>
>No, but you can make up your own conventions and stick to them. Mine are:
>
>Sub_routine
>la_bel
>Ffile_register
>Bbit_in_same
>CONSTANT
>
>This is sort of like Hungarian notation. The S,F and B symbols appear
>grouped in any symbol listing and are easy to read. It also reduces
>confusions (is it a file? is it a constant?).
>
>Peter
>
>--
>http://www.piclist.com#nomail Going offline? Don't AutoReply us!
>email listservspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body
>Yow! - CVS looks complex and smells like it has security issues. Do I
>understand correctly that it stores your project documents on somebody
>else's server? This gives me the shivers. If I was doing a far-flung GNU
>project with a bunch of volunteer programmers this might be a good system to
>use.
>
>I think I'll stick to revision notes at the beginning of my C source file,
>that's pretty simple.
RCS is the network-less version of CVS. You can use that in case of
paranoia. The CVS server can run ON YOUR OWN machine of course. You don't
need to run it on someone else's machine. In a normal environment it would
run on a server that serves all the developers on a project, on an
intranet. And it would be guarded like the proverbial crown jewels.
> I personally prefer spaces and no tabs. Why? because there is
> no standard tab spacing, but 8 is the most common. However,
> if you display your 4-space tabs as 8-space tabs, the document
> will look very messy. (Not to mention, the piclist archive of your
> tabbed files will look horrible)
Nothing more tedious than removing all the tabs from a piece of
someone's code so you can do a half-decent printout or fit the
routine into your own screen format
Uri Sabadosh <.....uriSTOPspam@spam@LUXTRON.COM> wrote:
> Use the Brief editor. It has a global (file scope) replace that accepts the
> tab key as a character to replace. Replace with four space chars.
Most editors have that capability. Works fine as long as all tabs start at
the left edge. If you have any right-side comments, etc., lined up with
tabs, though, you'll still end up doing a lot of fixing-up by hand.
Uri Sabadosh wrote:
>
> Use the Brief editor. It has a global (file scope) replace that accepts the
> tab key as a character to replace. Replace with four space chars.
>
> Uri
You can do that with MPLAB or any editor with search and replace.
To select a tab, move the cursor to the start of a line where the first
character is a tab. Press shift and right arrow once to select the tab
character. Press CTRL Insert to capture the tab to the clipboard. In
MPLAB, press ALT E R. Then SHIFT Insert to paste the TAB character into
the Find What field. (It looks like a solid "I") Type as many spaces as
you need into the Replace With field. Press "Replace All".
At 04:34 PM 6/20/02 -0700, you wrote:
>Use the Brief editor. It has a global (file scope) replace that accepts the
>tab key as a character to replace. Replace with four space chars.
That would make a royal mess of things in some cases.
I suggest using a nice editor such as the shareware Ultraedit.
Spehro Pefhany wrote:
>
> At 04:34 PM 6/20/02 -0700, you wrote:
> >Use the Brief editor. It has a global (file scope) replace that accepts the
> >tab key as a character to replace. Replace with four space chars.
I wrote a small utillity that tries to re-format ASM files.
It parses the text file, deletes all TABs and if it finds more than 1
consecutive space on a line, deletes them as well. It tags where each of
these conditions existed on the line and inserts spaces to pad the line
out to the column widths (max 4 allowed) which are user set from 4 edit
boxes on the screen.
I don't know how well it will work for every file though.
Yeah, just what I need, one more editor. Why not just use spaces in the
first place?
Dale
--
"Curiosity is the very basis of education and if you tell me that
curiosity killed the cat, I say only the cat died nobly."
- Arnold Edinborough
On Thu, 20 Jun 2002, Uri Sabadosh wrote:
> Use the Brief editor. It has a global (file scope) replace that accepts the
> tab key as a character to replace. Replace with four space chars.
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
At 11:17 21/06/2002 +1200, Jinx wrote:
> > I personally prefer spaces and no tabs. Why? because there is
> > no standard tab spacing, but 8 is the most common. However,
> > if you display your 4-space tabs as 8-space tabs, the document
> > will look very messy. (Not to mention, the piclist archive of your
> > tabbed files will look horrible)
>
>Nothing more tedious than removing all the tabs from a piece of
>someone's code so you can do a half-decent printout or fit the
>routine into your own screen format
Nobody really uses decent editors? Any half-decent one should
have a function to replace tabs with [the selected number of]
spaces...
G.
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
Mine even lets me use the TAB key, but puts spaces in the text file. I
find that works even better than trying to clean it up later.
Dale
--
"Curiosity is the very basis of education and if you tell me that
curiosity killed the cat, I say only the cat died nobly."
- Arnold Edinborough
On Fri, 21 Jun 2002, Guillermo Rodriguez Garcia wrote:
> Nobody really uses decent editors? Any half-decent one should
> have a function to replace tabs with [the selected number of]
> spaces...
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>Nobody really uses decent editors? Any half-decent one should
>have a function to replace tabs with [the selected number of]
>spaces...
This DOES NOT work to preserve formatting- the tabs are usually
in FIXED evenly-spaced positions across the line (in word-
processing programs you can usually make them non-evenly-spaced.
The tab character means to go to the next fixed position, which
may be one space or many. Replacing the tab character with a
fixed number of spaces will destroy the formatting in almost
every case (including PIC assembler code)
But, yes, a good editor should have commands for dealing with
that as well as *nix/PC issues etc. Vanilla IDE editors tend
not to, so you keep one good editor around, no big deal.
At 07:17 21/06/2002 -0400, Spehro Pefhany wrote:
>>Nobody really uses decent editors? Any half-decent one should
>>have a function to replace tabs with [the selected number of]
>>spaces...
>
>This DOES NOT work to preserve formatting- the tabs are usually
>in FIXED evenly-spaced positions across the line (in word-
>processing programs you can usually make them non-evenly-spaced.
>
>The tab character means to go to the next fixed position, which
>may be one space or many. Replacing the tab character with a
>fixed number of spaces will destroy the formatting in almost
>every case (including PIC assembler code)
>But, yes, a good editor should have commands for dealing with
>that as well as *nix/PC issues etc. Vanilla IDE editors tend
>not to, so you keep one good editor around, no big deal.
>
>Best regards,
>
>Spehro Pefhany --"it's the network..." "The Journey is the reward"
>.....speffRemoveMEinterlog.com Info for manufacturers: http://www.trexon.com
>Embedded software/hardware/analog Info for designers: http://www.speff.com
>9/11 United we Stand
>
>--
>http://www.piclist.com hint: PICList Posts must start with ONE topic:
>[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>> I personally prefer spaces and no tabs. Why? because there is
>> no standard tab spacing, but 8 is the most common. However,
>> if you display your 4-space tabs as 8-space tabs, the document
>> will look very messy. (Not to mention, the piclist archive of your
>> tabbed files will look horrible)
>
>Nothing more tedious than removing all the tabs from a piece of
>someone's code so you can do a half-decent printout or fit the
>routine into your own screen format
You should *really* get a copy of the GNU textutils compiled for
DOS/Win32. You want the programs expand and unexpand as Scott Dattalo has
said. Try to type 'unexpand.exe' into Google. Maybe it is floating
somewhere outside its original archive (which is large but worth your
while ...).
Peter
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> Nothing more tedious than removing all the tabs from a piece of
> someone's code so you can do a half-decent printout or fit the
> routine into your own screen format
I use my COPYA program, which can be set to arbitrary tab stops and use them
to substitute spaces for tabs. The COPYA tool is included in the "PIC
development tools" download at http://www.embedinc.com/pic/dload.htm.
*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
>Uri Sabadosh <uri@spam@LUXTRON.COM> wrote:
>> Use the Brief editor. It has a global (file scope) replace that accepts the
>> tab key as a character to replace. Replace with four space chars.
>
>Most editors have that capability. Works fine as long as all tabs start at
>the left edge. If you have any right-side comments, etc., lined up with
>tabs, though, you'll still end up doing a lot of fixing-up by hand.
Or use an editor with regular expression capability where you can tell it
not to touch lines that are comments. Or use awk which can do the same.
Or use BAWK.ZIP which is awk for DOS/W32. Or run the file through the
assembler and then process the .lst file to extract rewritten source
lines. (I do not remember if MPASM rewrites the source lines - other
assemblers do at least align to the leading printable character in each
source line). In C use indent (also a GNU program). Some artifices may be
necessary to deal with non-ANSI microprocessor C constructs. indent is
excellent to turn spaghetti C into readable files imho.
Peter
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
After having been bitten over the years (using a range of processors and
assemblers) by using a constant name as a variable "address" I now prefix
all constant names with "K". This makes obvious the presence of (stupid)
errors such as writing
mov a, upper_limit
when you meant to use
mov a, #upper_limit
Both do something but the wrong version is rather unuseful and VERY hard to
spot once you have done it due to "mental blinkers" which tend to stop you
seeing the obvious once you have approved of it once.
Writing
mov a,Kupper_limit
can be immediately seen to be wrong by inspection subsequently despite the
brains inbuilt error-protecting mechanisms.
The value of this depends on processor and mnemonics - some systems have
specific load-immediate mnemonics which tend to prevent this error.
One can extend this to using V prefix for variables, B for bit patterns etc
but use of K for constants shows the best return for me at least.
Russell McMahon
> >I personally try to use all lower case for keywords, Underscores in
> >variables, All uppercase for defines or constants.
> >
> >Type of variable as first part of variable name, Since labels are
variable
> >of type "address" I try to use "at" or "a" as the first letter of labels,
> >but they also denote the start of functions or procedures so sometimes I
use
> >"f" or "p" or even "s" or "sub."
piclist.com 1-619-652-0593 phone
