Searching \ for '[AD] Looking for work (style guide)' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=looking+work+style
Search entire site for: 'Looking for work (style guide)'.

Exact match. Not showing close matches.
PICList Thread
'[AD] Looking for work (style guide)'
2004\10\16@112027 by Charles Craft

picon face
Ahhhh - programming style.
Many beers or cups of coffee discussion.

I always pointed people to K&R - for better or worse it was hard to argue with the creators.

I don't suppose there is info from your style guide that can be made public?
(and I guess that depends on where the other "public" thread is going)

{Original Message removed}

2004\10\16@134659 by William Chops Westfield

face picon face
On Oct 16, 2004, at 8:20 AM, Charles Craft wrote:

> I don't suppose there is info from your style guide that can be made
> public?

Hmm.  I dunno.  Most of "style" is by definition arbitrary.  So we have
stuff like "each indentation level is 4 spaces."  "lines should not
80 columns in width."
/*
 * multiline comments look like this
 */
else if is "cuddled":
    if (foo) {
        bar();
    } else {
        baz();
    }
"Indentifiers should not have mixed case names."
typedef struct iptype_ {
       int a,b,c;
} iptype;

BillW

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\18@094530 by Lawrence Lile

flavicon
face
part 1 1867 bytes content-type:text/plain; (decoded quoted-printable)

It is time for me to make my annual post of my style guide. Here are the Ten Commandments of C Style

I am sure anyone here can add a few more, and some of them will be more useful than mine, too.

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com

> {Original Message removed}
part 2 3818 bytes content-type:application/x-zip-compressed; (decode)

part 3 194 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\18@142834 by James Newtons Massmind

face picon face
www.piclist.com/techref/language/ccpp/10CStyle.htm

I hope you don't mind, but I liked how it explained the reasons.

---
James.



> {Original Message removed}

2004\10\18@160342 by Lawrence Lile

flavicon
face
Wonderful!  Thanks for posting it!

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com
573-443-7100 ext 221

> {Original Message removed}

2004\10\18@165057 by Wouter van Ooijen

face picon face
> http://www.piclist.com/techref/language/ccpp/10CStyle.htm

Nicely worded, but IMHO otherwise just a list of crap.

First: such rules are never absolute, everything is relative to the
intended audience. For instance: in a freshmen C course a comment like
  i++;  // Add one to i  
might actually be a good idea. A comment should explain something beyond
the code, but what the code explains is audience-dependent. Hence
meaningfull comments are too. And note that // is not a comment in C,
only in C99, which is not exactly the current mainstream of C.

Then: "Thou shalt properly indent programs, each subservient function
being indented one level more than its master." What is a subservient
fucntion? If it is lower in the (inverted) call tree, how do I indent
mutually recursive functions? Or are they forbidden?

I'll leave bashing the other ones as an excercise to the readers :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



____________________________________________

2004\10\18@173941 by James Newtons Massmind

face picon face
I've added a link from that page to this thread in the archive so feel free
to add your own bashing... Either here on one the page itself. Like the
checklist for beginners, I assumed it would be something that would grow
with many different opinions over time.

I do get a kick out of LL's wording...

---
James.



> {Original Message removed}

2004\10\18@183454 by Lawrence Lile

flavicon
face



> > www.piclist.com/techref/language/ccpp/10CStyle.htm
>
> Nicely worded, but IMHO otherwise just a list of crap.

Originally I made this up when I was trying to learn C.  Having been spoilt by non-caps sensitive languages like AUTOLISP, CCS C, TestPoint, and various versions of Basic and Visual Basic, as well as non-caps sensitive environments like DOS, I could not understand why anyone would want to design a caps sensitive language.  Still can't understand this (analogy: Would you design a modern car with motorized seats, automatic electric windows, electronic ignition, automatic moisture-sensing windshield wipers, and a hand cranked starter?)  However it helped me learn the stuff and have fun doing it.  


>> a list of crap.
As far as the scatological comment goes (your honest opinion, I realize) the intended audience is a basic one which actually needs this information.  Obviously expert coders like yourself, Wouter, are far beyond such drivel.  <yes this is a compliment, no sarcasm implied>  

Feel free to add some similarly worded, but advanced, concepts of C style!
--Lawrence

>
> First: such rules are never absolute, everything is relative to the
> intended audience.
>

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004


____________________________________________

2004\10\18@203719 by William Chops Westfield

face picon face
On Oct 18, 2004, at 11:28 AM, James Newtons Massmind wrote:
>>
>> It is time for me to make my annual post of my style guide.
>> Here are the Ten Commandments of C Style
>>
Blasphemous heathen!

The only thing there that I have objections to is the idea that
indentifiers should be unique in the first 6 to 8 characters.  In
particular, it can frequently be a good idea to have structure name
members include the structure:
    struct udptype_ {
        unsigned short udp_sport;
        unsigned short udp_dport;
        unsigned short udp_length;
        unsigned short udp_cksum;
    } udp;

This can help considerable when searching, since things like "length"
by themselves are distressingly common.  once you use up 4+ characters
on structure prefix, you don't have much left if you want things unique
in 6 characters.  (of course, the above example IS...)

BillW

       

____________________________________________

2004\10\19@025852 by Wouter van Ooijen

face picon face
> As far as the scatological

sorry, non-english background, what the ^&*&^ does that word mean?

> Feel free to add some similarly worded, but advanced,
> concepts of C style!

sorry, I can't (or rather: I can't without specifying the audience much
better), reason below :)

> >
> > First: such rules are never absolute, everything is relative to the
> > intended audience.

I do give some guidelines in my C classes, but they are always just
guidelines, along the lines of 'try to find out what works for you, be
aware that that will change over the years, and be prepared to accept
whatever rules the corporate guru has drafted, unless you are of the Don
Quichote type'.

But note that the fact that you have drafted such rules *for yourself*
is perfectly within the above advice. It is the guys who try to give
such rules absolute power that I am up against.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\19@030909 by William Chops Westfield

face picon face
On Oct 16, 2004, at 8:20 AM, Charles Craft wrote:

> I don't suppose there is info from your style guide that can be made
> public?

Hmm.  I went ahead and posted a good part of our style guide with
a [PIC:] tag, for better or worse (much of it not being applicable
to PICs, but none of it being [AD:]!)

Just in case anyone is ONLY reading the AD threads and might want
to look.

 :-)
BillW

____________________________________________

2004\10\19@031721 by Jinx
face picon face

> > As far as the scatological
>
> sorry, non-english background, what the ^&*&^ does that word mean?

http://encyclopedia.thefreedictionary.com/Scatalogical

A proper word, from the Greek skatos, "dung"

For bonus **points, figure this one out -

After the cat drops a whoopsie on the carpet behind the curtains,
you tell it to "Scat !"

Is this

a) none of the below
b) a command to do it again
c) an exclamation of the obvious
d) the short-form of "Scat outside next time !"


** points are imaginary and will not be awarded

____________________________________________

2004\10\19@040854 by No Religion

flavicon
face
At 17.37 2004.10.18 -0700, you wrote:
{Quote hidden}

Agreed.

BTW: what's the whole issue of the following styles (one vs the other)?

if (blabla)
{
  do_this();
}
else
{
  do_that();
}

or

if (blabla) {
  do_this();
} else {
  do_that();
}

I'm *much* in favour of the latter.. why are there some people who
prefer the former? :D (IIRC even K&R).

Any valid argument? ;)



>BillW
>
>        
>
>_____________________________________________

2004\10\19@051918 by Ake Hedman

flavicon
face
Lawrence Lile wrote:

>
>  
>
>>>www.piclist.com/techref/language/ccpp/10CStyle.htm
>>>      
>>>
>>Nicely worded, but IMHO otherwise just a list of crap.
>>    
>>
>
>Originally I made this up when I was trying to learn C.  Having been spoilt by non-caps sensitive languages like AUTOLISP, CCS C, TestPoint, and various versions of Basic and Visual Basic, as well as non-caps sensitive environments like DOS, I could not understand why anyone would want to design a caps sensitive language.  Still can't understand this (analogy: Would you design a modern car with motorized seats, automatic electric windows, electronic ignition, automatic moisture-sensing windshield wipers, and a hand cranked starter?)  However it helped me learn the stuff and have fun doing it.  
>  
>
This is a mystery for me to. What is the benefit of a caps sensitive languages and and/or OS?  I have never (and thats for +20 years) found a reason for this. And yes I am a Unix/Linux  user since a long time back and like that environment. But caps sensitivity in a HMI interface is (still) very non user friendly to me.

And for "The Ten Commandments"  I think its fun and entertaining. Thanks Lawrence.

I don't know what has append to the list latly. Its a lot of complaining about this and that and sometimes I feel there a more post with complaints of different sorts then about actual technical issues.  I even prefer Olins's baring like an old dog (You know that dog will bark until you shoot him and you still like him to much to do so)  instead of this "general fault finding pick on people attitude" that many have now.  I want the old usefully *friendly* PICLIST back!!! Thanks!

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\19@053615 by Ake Hedman

flavicon
face
No Religion wrote:

{Quote hidden}

If have use the former for most of my professional life as a programmer but have changed to the latter a year or two ago. Is either of them more easy to understand? Is either of them easier to understand for a programmer that use the opposite style? It's just a matter of taste. Use the one you like!

The same goes for optimization of C-code. If you are concern with how the generated code looks like you either are a compiler constructor or have chosen the wrong tool for your job or possibly hunting for a compiler bug or knowledge about how the compiler works. IMHO code that are critical and for which you must know the actual machine instructions executed *must* be coded in low Assembler. Everything else is plain stupid!

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\19@083214 by Lawrence Lile

flavicon
face
This 6-8 character thing may be a legacy style from a very old compiler.  It certainly harks back to the days of 8.3 filenames and other such limitations.   Now I wonder if it is really true, that some C compilers might not distinguish two variables with the first 8 letters identical?  

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com

> {Original Message removed}

2004\10\19@083603 by Lawrence Lile

flavicon
face
"scatological" means literally the science of ..ah.. animal waste, to put it politely.  The word is often used to describe jokes or comments referring to this smelly subject in a polite way.

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com


> {Original Message removed}

2004\10\19@085246 by Bob Ammerman

picon face
IIRC, there were quite a few compilers with very short identifier uniqueness
length.

It was even worse for external symbols in some cases, how about 5
characters!

What I thought was ridiculous is that the language permitted identifiers
longer than the max length for uniqueness, usually without any warning. So
things like this could really get you:

static int aprefixbefore_globalvar;

int f()
{
   int aprefixbefore_localvar;
   aprefixbefore_globalvar = 123;
   return aprefixbefore_globalvar;
}

Bob Ammerman
RAm Systems

----- Original Message -----
From: "Lawrence Lile" <spam_OUTllileTakeThisOuTspamprojsolco.com>
To: "Microcontroller discussion list - Public." <.....piclistKILLspamspam@spam@mit.edu>
Sent: Tuesday, October 19, 2004 8:27 AM
Subject: RE: [AD] Looking for work (style guide)


> This 6-8 character thing may be a legacy style from a very old compiler.
> It certainly harks back to the days of 8.3 filenames and other such
> limitations.   Now I wonder if it is really true, that some C compilers
> might not distinguish two variables with the first 8 letters identical?
>
> -- Lawrence Lile, P.E.
> Electrical and Electronic Solutions
> Project Solutions Companies
> http://www.projsolco.com
>
>> {Original Message removed}

2004\10\19@102734 by Peter L. Peres

picon face


On Tue, 19 Oct 2004, Lawrence Lile wrote:

> This 6-8 character thing may be a legacy style from a very old compiler.
> It certainly harks back to the days of 8.3 filenames and other such
> limitations.  Now I wonder if it is really true, that some C compilers
> might not distinguish two variables with the first 8 letters identical?

Some 'tiny C' compilers may have that problem. tiny C refers to C subsets
on integer 16 bits or less, usually running on severely limited hardware
(like CP/M or embedded).

Peter
____________________________________________

2004\10\19@112452 by Wouter van Ooijen

face picon face
> BTW: what's the whole issue of the following styles (one vs
> the other)?

I agree with you, my reason is that I want to see as much lines as
possible on my screen without scrolling. This roughly determines how
long I can (or want) to make a function. I even tend to put the closing
} on the same line as the last statement.

The often heared reason for the first style is that the braces are in
the same column, so they are easier to check. Judging from my students
this might be correct, but maybe only for freshman programmers.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\19@115451 by Peter Johansson

flavicon
face
No Religion writes:

> I'm *much* in favour of the latter.. why are there some people who
> prefer the former? :D (IIRC even K&R).

Careful there, you are coming close to starting a religious war.  ;-)

> Any valid argument? ;)

Many people prefer the former because it introduces more whitespace,
and whitespace often makes code more readable.

Way back when I started programming I had my own very strict coding
standards and I found it somewhat difficult to adapt to other styles.
In the many years since, I've worked with so many different styles and
standards that I really don't have a preference any more.

The one key, however, is that I use Emacs which has an infinitely
configurable indentation engine.  I set it for whatever standard I
happen to be working with and then I can simply forget about the
details of indentation.

Another thing about indentation engines is that they are a great way
of catching programming bugs.  I can't count the number of times I've
discovered latent logic errors in other people's code because the
presented indentation did not actually match the code logic.

-p.

____________________________________________

2004\10\19@135901 by Eric Bohlman

picon face
Ake Hedman wrote:
> This is a mystery for me to. What is the benefit of a caps sensitive
> languages and and/or OS?  I have never (and thats for +20 years) found a
> reason for this. And yes I am a Unix/Linux  user since a long time back
> and like that environment. But caps sensitivity in a HMI interface is
> (still) very non user friendly to me.

"Future proofing" is one.  As the world moves from US-ASCII only to
Unicode, case-insensitivity becomes much more problematic.  For one
thing, case-folding becomes *much* more complex to implement; it
requires large tables rather than a few simple bit manipulations.  For
another thing, the rules of case equivalence (and let's not even get
into sensitivity to accents) aren't uniform between human languages.

That's why, for example, XML is inherently case-insensitive (and
therefore why in XHTML, all element and attribute names have to be
lower-case).

All that said, it is extraordinarily *bad* design to exploit
case-sensitivity in displays of nerdismo such as defining distinct
commands or identifiers that differ only in case.  This is an example of
the more general principle that distinct identifiers should be
"psychologically distant" from each other.  The section on
"psychological set" in Gerald Weinberg's classic _The Psychology of
Computer Programming_ should be mandatory reading for any serious
programmer (for those who have read Douglas Adams, psychological set is
the phenomenon that makes the SEP field work).  Weinberg points out that
any programmer who tries to be clever by naming an identifier "ST0P"
(yep, that's a zero) is going to eventually do a face-plant, and
describes a case where an important piece of software had hidden bugs
for years due to confusion between two variables named "SYSTSTS" and
"SYSSTSTS".  (There's also an admonition in there that the names of
symbolic constants need to reflect the *purpose* of the constant rather
than its *value*; Weinberg gives an example of a symbolic constant named
 "FIVE" whose value, due to changes since initial design, was actually 4.)
____________________________________________

2004\10\19@150825 by Wouter van Ooijen

face picon face
> All that said, it is extraordinarily *bad* design to exploit
> case-sensitivity in displays of nerdismo such as defining distinct
> commands or identifiers that differ only in case.

If I ever find the time for a Jal-version-2 I'll make it
case-insensitive but case-enforcing: the use of an identifier must match
the definition exactly (including case), and defining another identifier
that differs only in case is not allowed.

> (There's also an admonition in there that the names of
> symbolic constants need to reflect the *purpose* of the
> constant rather than its *value*;

That's my argument againts
- that weird notation where the type of a variable reflects its
structure
- USING ALL UPPERCASE FOR C DEFINES

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\19@162333 by Ake Hedman

flavicon
face
Eric Bohlman wrote:

> Ake Hedman wrote:
>
>> This is a mystery for me to. What is the benefit of a caps sensitive
>> languages and and/or OS?  I have never (and thats for +20 years)
>> found a reason for this. And yes I am a Unix/Linux  user since a long
>> time back and like that environment. But caps sensitivity in a HMI
>> interface is (still) very non user friendly to me.
>
>
> "Future proofing" is one.  As the world moves from US-ASCII only to
> Unicode, case-insensitivity becomes much more problematic.  For one
> thing, case-folding becomes *much* more complex to implement; it
> requires large tables rather than a few simple bit manipulations.  For
> another thing, the rules of case equivalence (and let's not even get
> into sensitivity to accents) aren't uniform between human languages.
>
Yes, Unicode  makes a lot of things harder and for an OS it must be used. Not as sure for a C/C++ and other program languages though. To restrict variable names etc to be US-ASCII does not feel like big deal to me even if I come from another languages zone. But any deterministic translation would work well also I think.
If the reason to go for case sensitive is due to technical limitations  and not an HMI  design issue it is easier to accept just as you had to accept 8.3 filenames.

{Quote hidden}

This sounds like a must have book. Will buy it have never heard of it before. Thanks for the tip!


Regards
/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\19@190033 by James Newtons Massmind

face picon face
The only correct formatting... <GRIN>

Well, the formatting that makes sense to me...

...is:

if (bla) {
       do_this();
       }
else {
       do_that();
       }

Because until AFTER the compiler has seen the "}" it is still in the
condition. It also makes it so much cleaner to find the point where the
conditional ends.

Also, I activly avoid

if (bla) do_this(); else do_that();

because it confuses me when I'm reading though the code. The conditionaly
executed code should be indented.

---
James.



> {Original Message removed}

2004\10\19@193218 by Russell McMahon

face
flavicon
face
> This 6-8 character thing may be a legacy style from a very old compiler.
> It certainly harks back to the days of 8.3 filenames and other such
> limitations.   Now I wonder if it is really true, that some C compilers
> might not distinguish two variables with the first 8 letters identical?


I have had assemblers with limited name length discrimination, and a PCB
package that has about 5 or 6 digit resolution on component names and NO
warnings when this causes problems !!!


       RM

____________________________________________

2004\10\19@224000 by Eric Bohlman

picon face
Ake Hedman wrote:
> Yes, Unicode  makes a lot of things harder and for an OS it must be
> used. Not as sure for a C/C++ and other program languages though. To
> restrict variable names etc to be US-ASCII does not feel like big deal
> to me even if I come from another languages zone. But any deterministic
> translation would work well also I think.

The key there is *feel* like a big deal to *you*.  Consider a programmer
 in a society that uses a non-Western language.  Yes, he has to accept
that the (relatively few) language keywords are going to be written in a
foreign language using a foreign writing system, but why should he have
to do that with his variable and function names?  After all, choosing
good names is a big part of making code readable and maintainable, and
having to translate as you read and write code really detracts from
that.  A likely result is going to be a bias toward using arbitrary names.

[_The Psychology of Computer Programming_ by Gerald Weinberg]

> This sounds like a must have book. Will buy it have never heard of it
> before. Thanks for the tip!

It was written 34 years ago and a new edition was recently released.
Some of it seems a little "dated"; it was written before the advent of
personal computers and a lot of the examples deal with things like
arguments over whether timesharing systems were more productive than
batch systems, but the basic principles are still valid.  One of
Weinberg's major contentions is that programming on non-trivial projects
has to be considered a *social* activity; that's likely to ruffle some
feathers, but I think he supports it well.

Some highlights:

A consideration of all the factors that determine whether or not a
program is a "good" program.

The hilarious description of the progress-reporting system where
progress reports for a given month had to be entered during the
preceding month.

The observation that "debugging" actually consists of at least three
distinct activities which use different cognitive abilities and
personality traits.

All the stuff on psychological set.

The classic observation that "an 'art colony' is a place where everyone
knows how to look like an artist but few, if any, know how to paint like
one." (it appeared in the context of a discussion of programming
practices (and programming management practices) that encourage
improvement versus practices that merely encourage wannabeism).

The observation that "if builders built buildings the way programmers
write programs, the first woodpecker to come along would have destroyed
civilization."

Emphasis on the distinction between how easy a tool is to *learn* and
how easy it is to *use*.

Lots of illustrations of the psychological phenomena that make extremely
smart people behave in extremely dumb ways, such as the team that nearly
signed off on the completion of a project that was running six weeks
behind, the team that decided that a certain piece of bad output was the
result of simultaneous hardware glitches affecting two completely
independent systems, several cases of managers rewarding programmers for
making mountains out of molehills, the programmer who had to patiently
explain to group of other programmers that the fact this his solution to
a problem produced correct results whereas theirs didn't was more
important than the fact that their solution ran faster than his, and
many more.
____________________________________________

2004\10\20@010640 by William Chops Westfield

face picon face
On Oct 19, 2004, at 1:54 AM, No Religion wrote:

> BTW: what's the whole issue of the following styles (one vs the other)?
>
> if (blabla)
> {
>    do_this();
> }
>
In the days before good editors and glass screens (and C *does* go
back that far), this version would make it easier to add code at the
very beginning and end of the block...  (I can't think of any other
good reason for it, but Wouter's "line up the braces" might have
something to do with it...)

BillW

____________________________________________

2004\10\20@024548 by No Religion

flavicon
face
At 11.19 2004.10.19 +0200, you wrote:
>Lawrence Lile wrote:
>
>>
>>
>>
>>>>www.piclist.com/techref/language/ccpp/10CStyle.htm
>>>>    
>>>Nicely worded, but IMHO otherwise just a list of crap.
>>>  
>>
>>Originally I made this up when I was trying to learn C.  Having been spoilt by non-caps sensitive languages like AUTOLISP, CCS C, TestPoint, and various versions of Basic and Visual Basic, as well as non-caps sensitive environments like DOS, I could not understand why anyone would want to design a caps sensitive language.  Still can't understand this (analogy: Would you design a modern car with motorized seats, automatic electric windows, electronic ignition, automatic moisture-sensing windshield wipers, and a hand cranked starter?)  However it helped me learn the stuff and have fun doing it.  
>>
>This is a mystery for me to. What is the benefit of a caps sensitive languages and and/or OS?

I like it in a programming language.. it shows (as errors) when you type a variable bad.

In Basic I used to call the same variable in many different ways (letter cases speaking), which meant higher mess than my clean, all around the same, C variables.


>I have never (and thats for +20 years) found a reason for this. And yes I am a Unix/Linux  user since a long time back and like that environment. But caps sensitivity in a HMI interface is (still) very non user friendly to me.

Agreed.

I like it in programming languages, but certainly not in filenames.


{Quote hidden}

>____________________________________________

2004\10\20@033038 by Jan-Erik Soderholm

face picon face
> > I have never (and thats for +20 years) found a reason for
> > this. And yes I am a Unix/Linux  user since a long time back
> > and like that environment. But caps sensitivity in a HMI
> > interface is (still) very non user friendly to me.

Don't mix up the technical environment (prog languages, OS)
and the HMI (The Human-Machine Interface of the application).

They are two different things.

It's no problem to use a case-insensitive language (which
I prefer b.t.w) to write an application with a case sensitive HMI...

Regards,
Jan-Erik.
____________________________________________

2004\10\20@040120 by Wouter van Ooijen

face picon face
> > if (blabla)
> > {
> >    do_this();
> > }
> >
> In the days before good editors and glass screens (and C *does* go
> back that far), this version would make it easier to add code at the
> very beginning and end of the block...  (I can't think of any other
> good reason for it, but Wouter's "line up the braces" might have
> something to do with it...)

But that would be equally easy for

if (blabla){
  do_this();
}

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@040122 by Wouter van Ooijen

face picon face
> [_The Psychology of Computer Programming_ by Gerald Weinberg]
>
> > This sounds like a must have book.

It is, highly recommended. And also get "peopleware", I forgot the
author's name.

> The observation that "if builders built buildings the way programmers
> write programs, the first woodpecker to come along would have
> destroyed civilization."

That is of course a cleverly worded but totally wrong comparison.
Builders should be compared to chip factories (or maybe FLASH PIC
programmers), programmers should be compared architects and civil
engineers, and only to the ones that build new types of buildings, in a
new environment, that is not understood, and will change totally the day
the building is finished.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@040123 by Wouter van Ooijen

face picon face
> Well, the formatting that makes sense to me...

That's the point: what makes sense to one needs not make sense to
another.

>  if (bla) {
>        do_this();
>        }
>  else {
>        do_that();
>        }

I consider this a wase of precious lines (vertical space on my screen,
or paper length when printed).

> Also, I activly avoid
>  if (bla) do_this(); else do_that();

I do object to that, but for a different reason: I want to {} to be
there, so I would write

  if( bla ){ do_this(); } else { do_that(); }

(note that I changed the whitespace to what *I* find easy to read :)
Now I don't object to the one-liner, provided that (weak and subjective
definition) it reads like a
single operation.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@043643 by Ake Hedman

flavicon
face
Eric Bohlman wrote:

> Ake Hedman wrote:
>
>> Yes, Unicode  makes a lot of things harder and for an OS it must be
>> used. Not as sure for a C/C++ and other program languages though. To
>> restrict variable names etc to be US-ASCII does not feel like big
>> deal to me even if I come from another languages zone. But any
>> deterministic translation would work well also I think.
>
>
> The key there is *feel* like a big deal to *you*.  Consider a
> programmer  in a society that uses a non-Western language.  Yes, he
> has to accept that the (relatively few) language keywords are going to
> be written in a foreign language using a foreign writing system, but
> why should he have to do that with his variable and function names?  
> After all, choosing good names is a big part of making code readable
> and maintainable, and having to translate as you read and write code
> really detracts from that.  A likely result is going to be a bias
> toward using arbitrary names.

Its impossible for a human to be other then subjective how hard we try to be otherwise :-)

But, yes, you are probably right and I certainly agree on the importance of good variable names. But during the years my experience have learned* * that using our national characters often put me into trouble. This is equally true for filenames as well as for variables. And if using variable names in US-ASCII helps to lower problems and keep productivity up it must be fine. My point is that this is probably not  such a big deal. Maybe some Asian programmer disagree but I have contact with a few and all of them write there code in English. And I think that if I where about to check code from a fellow programmer here in Sweden and he/she uses national characters in varaible names I would know that this person probably got very little programming experience or possibly been coding in a very closed environment.

{Quote hidden}

I wounder why I haven't heard about this book before. Sounds like a real must have. Can't wait until I get my hands on a copy.....

Regards
/Ake


--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\20@044518 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

>>>I have never (and thats for +20 years) found a reason for
>>>this. And yes I am a Unix/Linux  user since a long time back
>>>and like that environment. But caps sensitivity in a HMI
>>>interface is (still) very non user friendly to me.
>>>      
>>>
>
>Don't mix up the technical environment (prog languages, OS)
>and the HMI (The Human-Machine Interface of the application).
>
>They are two different things.
>
>It's no problem to use a case-insensitive language (which
>I prefer b.t.w) to write an application with a case sensitive HMI...
>
>Regards,
>Jan-Erik.
>  
>
But you must agree that for a human

"RunThisCommand"

and

"RUNTHISCOMMAND"

and

"runthiscommand"

should be interpreted to be the same by an HMI. And also it would be very bad coding style to have two variables

int btest;

and

bool bTest;


By definition your programming code is a HMI also. Its no difference if you use a text interface (keyboard, screen), graphical environment, text file input, direct neuron input.  But of course that depends how abstract you like to look at the problem.



/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\20@050503 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> Maybe some Asian programmer disagree but I
> have contact with a few and all of them write there
> code in English...

Or rather in FORTRAN, C, COBOL, BASIC or whatever.

Now, *comments* are a different story. Do you realy expect
a French programmer to write English comments ?? :-) :-)

(I've nothing aginst France, far from it! I think their standpoint
can be quite refreshing sometimes when I've got to much
of Anglo-American "culture" ... :-) )

Best Regards,
Jan-Erik.
PS. I wounder if the O.P. has found any work yet ?
____________________________________________

2004\10\20@051814 by Jan-Erik Soderholm

face picon face
Ake Hedman wrote :

> But you must agree that for a human
>
> "RunThisCommand"
> and
> "RUNTHISCOMMAND"
> and
> "runthiscommand"
>
> should be interpreted to be the same by an HMI.

It depends. If that is entered in an address field on an
order form, I'd expect the application to save it as-is
(That is, keeping upper/lower case as-entered).


> And also it would be
> very bad coding style to have two variables
>
> int btest;
> and
> bool bTest;

Of course, that's why I prefer *programming languages*
to be case-insensitive.

> By definition your programming code is a HMI also.

But not what most put into that TLW (Three Letter Word).
The common definition seems to be the interface between the
end-user and the "machine". And, in this regard, the programmer
is not an end-user.

Jan-Erik.
____________________________________________

2004\10\20@053125 by Ake Hedman

flavicon
face
Jan-Erik Soderholm wrote:

{Quote hidden}

>____________________________________________

2004\10\20@060213 by Wouter van Ooijen

face picon face
> Now, *comments* are a different story. Do you realy expect
> a French programmer to write English comments ?? :-) :-)

If they worked for me, of course! I have been in some international
projects, the mandatory language was always English (in meetings, in
reports, in code, in emails, ...). French find this somewhat difficult,
but they did not seem to regard it as unreasonable. Apart from the UK
and US, the Dutch and Scandinavians seemed to be most at ease speaking
English.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@063020 by Ake Hedman

flavicon
face
Wouter van Ooijen wrote:

>>Now, *comments* are a different story. Do you realy expect
>>a French programmer to write English comments ?? :-) :-)
>>    
>>
>
>If they worked for me, of course! I have been in some international
>projects, the mandatory language was always English (in meetings, in
>reports, in code, in emails, ...). French find this somewhat difficult,
>but they did not seem to regard it as unreasonable. Apart from the UK
>and US, the Dutch and Scandinavians seemed to be most at ease speaking
>English.
>
>Wouter van Ooijen
>
>  
>
Most code I have seen in open source projects which use non English comments/variable names has been from Germany.  I think I have the same experience from closed projects but then again you see a lot more national oriented code in closed projects. Something that costs money and efforts when they hire a guy like me that don't understand what is written.  It may be a bit unfair to point out Germany in this way as it is the originating country for a lot of code for the open source community. But in absolute terms this is my experience.

/Ake

--  ---
Ake Hedman (YAP - Yet Another Programmer)
eurosource, Brattbergavägen 17, 820 50 LOS, Sweden
Phone: (46) 657 413430 Cellular: (46) 73 84 84 102
Company home: http://www.eurosource.se      Kryddor/Te/Kaffe: http://www.brattberg.com
Personal homepage: http://www.eurosource.se/akhe
Automated home: http://www.vscp.org


___________________________________________

2004\10\20@084129 by Lawrence Lile

flavicon
face
>All that said, it is extraordinarily *bad* design to exploit case-sensitivity in displays of nerdismo such as defining distinct commands or identifiers that differ only in case.  This is an example of the more general principle that distinct identifiers should be "psychologically distant" from each other.

That was one reasons I had to write the Ten Commandments in the first place - unless I wrote up hard and fast rules for capitalization for myself, I was not able to get anywhere when I started using case sensitive compilers.  Although the list was variously described as a load of scatological nonsense <grin>, it really helped me.  sINcE I aM IncaPable of tYpING CApS in AnY ConSIStenT WAY, and OfTEN hIT the CApS LoCK Key by ACCiDent, mUCh of MY code LOOks lIkE THIS, pretty Tough TO ComPilE if CApS SenSITIVITY is ON.



-- Lawrence Lile, P.E.
Who pops the CAPS LOCK key off of his keyboard whenever he gets a new computer.



---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004


____________________________________________

2004\10\20@092335 by Gerhard Fiedler

picon face
>> "Future proofing" is one.  As the world moves from US-ASCII only to
>> Unicode, case-insensitivity becomes much more problematic.  For one
>> thing, case-folding becomes *much* more complex to implement; it
>> requires large tables rather than a few simple bit manipulations.  For
>> another thing, the rules of case equivalence (and let's not even get
>> into sensitivity to accents) aren't uniform between human languages.
>>
> Yes, Unicode  makes a lot of things harder and for an OS it must be
> used. Not as sure for a C/C++ and other program languages though. To
> restrict variable names etc to be US-ASCII does not feel like big deal
> to me even if I come from another languages zone. But any deterministic
> translation would work well also I think.
>
> If the reason to go for case sensitive is due to technical limitations  
> and not an HMI  design issue it is easier to accept just as you had to
> accept 8.3 filenames.

I would go even further: it about time to have RTF type formatting in
program source code, plus a lot of other /presentation/ features. We need
to embrace the consequence of the fact that programs are written to be read
by humans just as they are written to be read by computers. Currently, the
human readable aspect is treated as a side aspect; comments and free
formatting are pretty much the only features in most languages that help
this. There should be no need to have all kinds of extra tools to create
proper documentation, this could (and should) all be part of the language
itself. I don't remember where, but I've seen a site dedicated to promote
that once and it really convinced me.

Gerhard
____________________________________________

2004\10\20@092406 by Wouter van Ooijen

face picon face
> Who pops the CAPS LOCK key off of his keyboard whenever he
> gets a new computer.

What a good idea! I never thought of that - the only key on my keyboard
I never use intentionally (but too often unintentionally).

There must be a tool someweher to do this softwarewise...

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@092533 by Jake Anderson

flavicon
face
i like the visual basic IDE's use of caps in all my declerations for
variables i capatilise them
NumberOfLoops say then when i type the variables i do it all in lower case.
when i go to the next line
the IDE changes the case of what i typed to match the deffinition. which
indicates to me that it was typed correctly and also makes it nice and easy
to read. as opposed to numberofloops which just looks like a blob of text to
me.

<rant>
learning PHP for a project really made me aware of how much the little
things like that matter to me.
things like the ; at the end of a statement case sensitivity, why is $_post
different to $_POST VB seems to manage ok without it, why do these other
languages need so much prodding and poking?
the differences in the languages themselves were no problem at all,
occasionally i'll be wishing one of them did it the way the other does but
nothings perfect, its all the little stuff you need to do in addition to do
things , == vs = etc.
</rant>


> {Original Message removed}

2004\10\20@092911 by Gerhard Fiedler

picon face
> And I think that
> if I where about to check code from a fellow programmer here in Sweden
> and he/she uses national characters in varaible names I would know that
> this person probably got very little programming experience or possibly
> been coding in a very closed environment.

Actually, I tend to consider the "works with ASCII only" environment a
"very closed" environment :)

There is no good reason beyond sloppy coding (and that's not a very good
one) these days for any PC program not to accept Unicode. (Of course, in
the case of compilers there are standards to be followed that govern the
language.) And sloppy coding is something that most people don't cherish in
their tools...

Gerhard
____________________________________________

2004\10\20@093458 by Gerhard Fiedler

picon face
> Another thing about indentation engines is that they are a great way
> of catching programming bugs.  I can't count the number of times I've
> discovered latent logic errors in other people's code because the
> presented indentation did not actually match the code logic.

Yep. I started writing some Python code, and it makes a /lot/ of sense not
to use braces at all, but rather use the indentation to mark blocks of
code. Since we need to use proper indentation anyway, to make code readable
and maintainable, why not make the compiler look at the indentation and
make it an integral element of the language? No brace style wars, you even
get to spare the line with the closing brace if your screen real estate is
important, and indentation reflects /by definition/ the code flow.

A C compiler that did that would be pretty cool. That's easy enough to
integrate with the rest of the language...

Gerhard
____________________________________________

2004\10\20@094335 by Gerhard Fiedler

picon face
> But you must agree that for a human
>
> "RunThisCommand"
>
> and
>
> "RUNTHISCOMMAND"
>
> and
>
> "runthiscommand"
>
> should be interpreted to be the same by an HMI.

But I'd reject any program that came to me (in a non case sensitive
language) that would use these three versions of the same command. So while
there's a point for not being case sensitive, there's a point for enforcing
the same case in a program.

> And also it would be
> very bad coding style to have two variables
>
> int btest;
>
> and
>
> bool bTest;

It definitely would be. But in that sense, I think Wouter's approach (to
enforce same case, but not allow identifiers that only differ in case) is
probably the most useful one.

BTW, nobody forces you to actually /use/ case in a case sensitive language
like C. If you want to keep it all in lower case, you can do that.

Gerhard
____________________________________________

2004\10\20@095533 by Ake Hedman

flavicon
face
Gerhard Fiedler wrote:

{Quote hidden}

>____________________________________________

2004\10\20@100906 by Wouter van Ooijen

face picon face
> I would go even further: it about time to have RTF type formatting in
> program source code, plus a lot of other /presentation/
> features.

Please no, I frequently generate code using another program, please
don't complicate this.

Think inside out: why not have a single source format, from which you
can generate both the code and the documentation? Not my invention,
check 'literate programming'.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\20@101400 by Josh Koffman

face picon face
Yup, there sure is. Check out John Haller's site for some interesting
hacks: http://johnhaller.com/jh/useful_stuff/
While there, check out his page about running Mozilla Firefox from a USB drive:
http://johnhaller.com/jh/mozilla/

Enjoy :)

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Wed, 20 Oct 2004 15:26:02 +0200, Wouter van Ooijen <wouterspamKILLspamvoti.nl> wrote:
> > Who pops the CAPS LOCK key off of his keyboard whenever he
> > gets a new computer.
>
> What a good idea! I never thought of that - the only key on my keyboard
> I never use intentionally (but too often unintentionally).
>
> There must be a tool someweher to do this softwarewise...
____________________________________________

2004\10\20@103543 by Alex Harford

face picon face
On Wed, 20 Oct 2004 15:26:02 +0200, Wouter van Ooijen <.....wouterKILLspamspam.....voti.nl> wrote:
> > Who pops the CAPS LOCK key off of his keyboard whenever he
> > gets a new computer.
>
> What a good idea! I never thought of that - the only key on my keyboard
> I never use intentionally (but too often unintentionally).
>
> There must be a tool someweher to do this softwarewise...

I always liked the old Sun? keyboards, where the CTRL key is where the
CAPS LOCK key is on the PC keyboard.

Much easier on the hands if you use it often.

Alex
____________________________________________

2004\10\20@104545 by Jan-Erik Soderholm

face picon face
Gerhard Fiedler wrote :

> There should be no need to have all kinds of extra
> tools to create proper documentation,...

That isn't anything new, of course.

The DECset development tool set includes the LSE, Language
Sensitive Editor. Not only does LSE know what programming language
you are currently working in (helping with function expansion and
parameter fill-in, and so on), you can also enter stuff in the source
that can be extracted and formatted as online help and printed
documentation. And DECset/LSE is now aprox 15 years old.

And, the best of all, this tool-set runs on the best OS in the
Universe, OpenVMS. :-)

Jan-Erik.
____________________________________________

2004\10\20@111001 by William Chops Westfield

face picon face

On Oct 20, 2004, at 5:23 AM, Gerhard Fiedler wrote:

> it about time to have RTF type formatting in
> program source code, plus a lot of other /presentation/ features. We
> need
> to embrace the consequence of the fact that programs are written to be
> read
> by humans just as they are written to be read by computers.

It's NOT clear to me that RTF actually enhances readability very much.
I'm quite certain that I've been to (and made) vendor presentations
involving colorized, logo-ized, multi-font powerpoint wonder
rear-projected
animated slides that didn't actually convey any more information than
the B&W transparencies on an overhead projector I remember from my
youth.
But I guess it gives powerpoint experts continued employment :-(  Or
sucks up time that could be spent on actual content.

BillW

____________________________________________

2004\10\20@111749 by William Chops Westfield

face picon face
On Oct 20, 2004, at 7:11 AM, Wouter van Ooijen wrote:

> Think inside out: why not have a single source format, from which you
> can generate both the code and the documentation?

Did that once. RUNOFF commands in the comments, pipe through assembler
and
got executable, pipe through runoff and got manual. Didn't work very
well.
Formatting commands made the comments harder to read, intervening code
made
the documentation harder to follow without using runoff, and
documentation
isn't the same as commenting anyway (and this starts to show.)

BillW

____________________________________________

2004\10\20@113042 by Peter Johansson

flavicon
face
Wouter van Ooijen writes:

> > Who pops the CAPS LOCK key off of his keyboard whenever he
> > gets a new computer.
>
> What a good idea! I never thought of that - the only key on my keyboard
> I never use intentionally (but too often unintentionally).
>
> There must be a tool someweher to do this softwarewise...

My first keyboards were the Apple ][ and VT100, so I long believed
that control should be at the left end of the home row.  Life was good
when I migrated to Suns and DECstations.  In 1994, I purchased an SGI
Indigo and the control key was decidedly in the *wrong* place, so I
simply used xmodmap to swap those two keys.  This worked fine for a
while until I was forced to use PCs without a simple remapping
solution.  When I returned home to my SGI, I found I was hitting my
re-defined caps lock way to many times, so I made both the control
*and* caps lock keys behave as control keys.  I still do this to this
day, though my pinky now has a natural tendancy to follow the PC
convention.

-p.
____________________________________________

2004\10\20@114510 by Ake Hedman

flavicon
face
William Chops Westfield wrote:

> On Oct 20, 2004, at 7:11 AM, Wouter van Ooijen wrote:
>
>> Think inside out: why not have a single source format, from which you
>> can generate both the code and the documentation?
>
>
> Did that once. RUNOFF commands in the comments, pipe through assembler
> and
> got executable, pipe through runoff and got manual. Didn't work very
> well.
> Formatting commands made the comments harder to read, intervening code
> made
> the documentation harder to follow without using runoff, and
> documentation
> isn't the same as commenting anyway (and this starts to show.)
>
> BillW
>
> _____________________________________________

2004\10\20@123104 by Lawrence Lile

flavicon
face
> There must be a tool someweher to do this softwarewise...
>

A screwdriver works nicely.  I bend a paper clip and stick it in the hole if I every actually [presses caps lock] NEED [unpresses caps lock]  that stupid key.  Same with the three Windows menu keys right near the spacebar, where my palm hits them all the time.  In the trash they go!

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com
573-443-7100 ext 221

> {Original Message removed}

2004\10\20@135016 by John J. McDonough

flavicon
face
----- Original Message -----
From: "William Chops Westfield" <EraseMEwestfwspam_OUTspamTakeThisOuTmac.com>
Subject: Re: [AD] Looking for work (style guide)


> Did that once. RUNOFF commands in the comments, pipe through assembler

You mean there is somebody else around old enough to remember RUNOFF???

Anyone played with doxygen?  I sort of like it, although I haven't had a lot
of success making it useful for PIC assembler.

--McD


____________________________________________

2004\10\20@143000 by Alex Harford

face picon face
On Wed, 20 Oct 2004 13:50:10 -0400, John J. McDonough
<mcdspamspam_OUTis-sixsigma.com> wrote:
> ----- Original Message -----
> From: "William Chops Westfield" <@spam@westfwKILLspamspammac.com>
> Subject: Re: [AD] Looking for work (style guide)
>
> > Did that once. RUNOFF commands in the comments, pipe through assembler
>
> You mean there is somebody else around old enough to remember RUNOFF???
>
> Anyone played with doxygen?  I sort of like it, although I haven't had a lot
> of success making it useful for PIC assembler.

I really like doxygen for C and C++ stuff.  I haven't done any Java
programming but I hear that the javadoc format is what doxygen was
originally based on.

Alex
____________________________________________

2004\10\21@064611 by Alan B. Pearce

face picon face
>PS. I wounder if the O.P. has found any work yet ?

I have been wondering that too :))

There have been close on 250 "[AD] Looking for work ..." messages since
Dave's original posting. I cannot recall that any of them actually offered
the possibility of any work, just lots of advice on how to apply, in the
early messages. Must be about time this moved to [OT] :))


____________________________________________

2004\10\21@120157 by M. Adam Davis

flavicon
face
I'm not sure what that really adds...

I use a code highlighting editor and it tells me everything I need to
know about my code in a very intuitive fashion.

I'd hate to work on code where another programmer decided to enforce
their highlighting rules on my viewing.  Or perhaps they decided to put
each control block in a smaller typeface than the preceding control
block.  Maybe even use white on white font coloring to hide bits of code
(for whatever reason).

I don't have a problem with, perhaps, using a markup to treat comments,
documentation, etc within the code, but I hope you aren't suggesting
that the code itself should be marked up.  Not only does it seem
unecessary, but it'll also increase file size and complexity of editors
(affecting speed, etc) as well as increase possibility of errors.

-Adam

Gerhard Fiedler wrote:

{Quote hidden}

>_____________________________________________

2004\10\21@120935 by M. Adam Davis

flavicon
face
Wouter van Ooijen wrote:

>I do object to that, but for a different reason: I want to {} to be
>there, so I would write
>
>   if( bla ){ do_this(); } else { do_that(); }
>
>  
>
Could also go

bla ? do_this() : do_that;

at least on compilers that allow such statements as
a + b

Where the result is thrown away.  Also, do_this and do_that need to
return a value.  And, of course, optimizers might reduce that statement
to nothing, since there is no value to change.

;-)

For such a simple statement, I prefer

if( bla )
 do_this();
else
 do_that();

which is fairly clear instantly to any level of programmer, and doesn't take up a ton of space.

But in the end it doesn't matter.  Use a code reformatter to convert another's style into one's own convention.

-Adam



____________________________________________

2004\10\22@031938 by hael Rigby-Jones

picon face


>-----Original Message-----
>From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu]
>On Behalf Of M. Adam Davis
>Sent: 21 October 2004 17:09
>To: Microcontroller discussion list - Public.
>Subject: Re: [AD] Looking for work (style guide)
>
>
>For such a simple statement, I prefer
>
>if( bla )
>  do_this();
>else
>  do_that();
>
>which is fairly clear instantly to any level of programmer,
>and doesn't take up a ton of space.

That is a dangerous construct in C, one which has bitten me in the past.
It's very easy to add another functional call etc. to one side of the
conditional statement, without realising you need to add braces.  At best
you'll get a compiler error, chances are you'll get a function that is
always executed.

Depending on your favoured brace style, it may take up no extra space to add
them (in terms of lines).  Personaly I don't like the style of braces added
to the ends of the lines, and always give each brace it own line.  Sure it
takes up more lines, but unless you are being forced to work on a 14" screen
at 640x480, this should really be a none issue.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
____________________________________________

2004\10\22@042518 by Wouter van Ooijen

face picon face
> and always give each brace it own
> line.  Sure it
> takes up more lines, but unless you are being forced to work
> on a 14" screen
> at 640x480, this should really be a none issue.

Why? In my experience every added line of readable code (not comment or
whitespace) I can see on my screen without scrolling increases the local
complexity I can handle.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\10\22@092843 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Jan-Erik Soderholm" <spamBeGonejan-erik.soderholmspamBeGonespamtelia.com>
Subject: RE: [AD] Looking for work (style guide)


> And, the best of all, this tool-set runs on the best OS in the
> Universe, OpenVMS. :-)

Although I think CMS was a little weak compared to the others, I sure miss
LSE and DTM.  Although, over the years I've gotten pretty comfortable with
emacs.  I really do like not having to change editors with every new
operating system (and those who remember VMS probably have been through
several!), but poking one button to get all the scoop on a particular
function is hard to beat.  And I have yet to get as comfortable with Make as
I was with MMS -- MMS always seemed so much more intuitive.  And could Latex
or groff or any of those hold a candle to VAX Document?

Is there a Linux equivalent of DTM?

--McD


____________________________________________

2004\10\22@100006 by Peter Johansson

flavicon
face
Wouter van Ooijen writes:

> > and always give each brace it own
> > line.  Sure it
> > takes up more lines, but unless you are being forced to work
> > on a 14" screen
> > at 640x480, this should really be a none issue.
>
> Why? In my experience every added line of readable code (not comment or
> whitespace) I can see on my screen without scrolling increases the local
> complexity I can handle.

Personally, I find that additional whitespace makes code more
readable.  There is also certainly an advantage to having an entire
function visible on the screen at once.  I consider this one of those
areas where trade-offs must be made.  As such, I will often break one
function into several simply to increase readability.  While this is
generally not a performance hit on non-embedded machines, it could be
a problem with PICs.

-p.
____________________________________________

2004\10\23@232953 by Gerhard Fiedler

picon face
>> I would go even further: it about time to have RTF type formatting in
>> program source code, plus a lot of other /presentation/
>> features.

> Think inside out: why not have a single source format, from which you
> can generate both the code and the documentation? Not my invention,
> check 'literate programming'.

That's been it, I just couldn't remember the name. Thanks for refreshing my
memory... :)

I think I haven't made myself clear enough. The single source format that
represents both program and documentation was what I was talking about.

Ake:
> I prefer javadoc or doxygen style to keep documentation in code.

I know doxygen and javadoc style formatting, and it works ok. But in the
source -- and in the programmer's editor --, it is not quite what I call
easily readable. Lots of cryptic symbols, and the "real" documentation only
becomes visible after you compile the source to the documentation. I'd like
that to be visible /while/ programming, in the end format. It's not for
nothing that this documentation actually gets encoded into something with
visual formatting (HTML, RTF (yes :), whatever). Why shouldn't we have this
benefit /while programming/?

> But if  someone wants rtf its fine with me. I can't say I understand the
> need.... ;-)

Did anybody actually read that I wrote "RTF /type/ formatting"? :)


Adam:
> I use a code highlighting editor and it tells me everything I need to
> know about my code in a very intuitive fashion.

So do I, and I wouldn't go without. But there's lots of stuff that we put
in comments (see doxygen) that looks awful in the source, even in a syntax
highlighting editor. It can look quite good after it has been compiled --
but that's a bit too late for my taste, and there's no real need to wait
that long. There's also no real need to keep all this generally considered
valuable information as an afterthought and hide it in comments, plus have
associated design documents separated from the code. Look at that literate
programming stuff; this is basically what I was trying to talk about
(didn't remember the name though).

> I'd hate to work on code where another programmer decided to enforce
> their highlighting rules on my viewing.  Or perhaps they decided to put
> each control block in a smaller typeface than the preceding control
> block.  Maybe even use white on white font coloring to hide bits of code
> (for whatever reason).

Actually, that was not what I was thinking of. More in the line of
something like doxygen or javadoc, but instead of being an afterthought,
having to be written and viewed (while programming) in a cryptic and raw
form, why not being able to actually view the documentation as it should
look like while programming?


Bill:
> It's NOT clear to me that RTF actually enhances readability very much.

It's not the RTF in itself that was the center of my point. But if you look
at http://www.literateprogramming.com/math.pdf for example, that looks
pretty much like a RTF /type/ formatted program :) -- and it seems to me
that the integration of documentation with the code, the added /text/
structuring (not to be confused with code structuring) and the formatting
does enhance readability.

I haven't read enough about Knuth's CWEB to know how that works, whether it
would be anything like what I'm envisioning /while programming/. But I'm
pretty sure that programmer support can be enhanced way beyond the point it
is today with most languages.

Gerhard
____________________________________________

2004\10\23@233314 by Gerhard Fiedler

picon face
> Who pops the CAPS LOCK key off of his keyboard whenever he gets a new computer.

Try to switch the Caps Lock key with the Ctrl key (in the keyboard layout,
not the actual physical keys :). Needs a bit getting used to, but the Caps
Lock key is so much more conveniently placed on most keyboards...

Gerhard
____________________________________________

2004\10\23@233542 by Gerhard Fiedler

picon face
>> There should be no need to have all kinds of extra
>> tools to create proper documentation,...
>
> That isn't anything new, of course.

Of course not, that's the worst part. It is still extremely rare, even
though it could be mainstream by now.

Gerhard
____________________________________________

2004\10\25@094007 by Bill & Pookie

picon face
Seen a program that would convert c source text into html.  But my big need
is a simple true type font for programming.  where characters can be seen
and not confused. ([{ 1Il 0O and  .,'

Bill

____________________________________________

2004\10\28@115308 by Gerhard Fiedler

picon face
> But my big need
> is a simple true type font for programming.  where characters can be seen
> and not confused. ([{ 1Il 0O and  .,'

I use (on Windows) Fixedsys. Not a True Type font, but the critical
characters are quite easy to distinguish. Courier New (the standard fixed
size True Type font on Windows) is a pain; I'm not sure the one and the
lower case L are in fact different in that font -- they look at least
pretty much the same.

Gerhard
____________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...