Subject:
|
Re: What are all those lego companies?
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Fri, 16 Feb 2001 07:45:32 GMT
|
Original-From:
|
Steve Baker <{sjbaker1@airmail.net}nomorespam{}>
|
Reply-To:
|
sjbaker1@airmail/saynotospam/.net
|
Viewed:
|
676 times
|
| |
|
|
Cyborg wrote:
> Why is this done this way, that you have to type "OnFwd" and (OUT_A)
> only that specific way and not like: "onfwd" or ONFWD"?,
> it would make it so much easier for a beginner and since english is not my
> native language, I already have trouble enough to write regular sentences.
(Your English is *excellent* - no need to apologise)
Well, this is something that programmers have 'grown up with' and are
rarely forced to reflect upon...but since you ask.
For people like me who have been writing C code for nearly 30 years(!), it
has become as natural as English - and it has 'accents' and 'inflections'
just like a spoken language. These serve the same purpose as inflections
and pauses in spoken English - they serve to insert meaning where the raw
written language can be 'enhanced'.
Variables in C (and NQC) are restricted to contain A-Z, a-z, 0-9 and underscore ('_').
When writing programs, it's important to be as clear as possible so that instead
of calling a variable just 'x' or 'a', it's nice if you can call it "the distance
the robot has driven so far" or whatever it actually represents. That makes it
easier to *read* programs - especially if someone else wrote the code.
However, you can't have spaces in variable names...and you can't read:
thedistancetherobothasdrivensofar
...very easily.
Some programmers use the underscore: the_distance_the_robot_has_driven_so_far,
but the 'trendy' style is to capitalise every word instead:
TheDistanceTheRobotHasDrivenSoFar ... which is less typing and still quite easy
to read. (I write about 100,000 lines of code a year - that's several MILLION
keystrokes...every little helps!)
In practice, I'd probably type DistanceTravelled - but you get the idea.
Now, in C (and NQC), there are variables and constants. Constants in old-style
C were set up using the '#define' statement:
eg
#define PI 3.1415926
#define MaxSpeed 123
...but there is a problem - you need to *know* that something is a constant
so you don't try to do things like:
MaxSpeed = 6 ;
You could check that you didn't mess up by looking at the '#define' statement,
but this could be a 1,000,000 line program spread over 1,000 separate files in
a couple of dozen folders...(well, not on an RCX it couldn't!)...
*SO* we have come up with the convention (and it's only a convention) of writing
'#define'd constants in UPPERCASE so that they are *obviously* constants.
If you saw:
MAXSPEED = 6 ;
...and you were an experienced C programmer, you'd immediately and instinctively
flinch...realising that there is something BADLY WRONG here!
Unfortunately, the UsingCapitalsAtTheStartOfWords convention doesn't work for
constants - so you go back to the non-trendy underscore convention.
#define MAX_SPEED 6
There are *LOTS* of these conventions out there - and not all programmers
use the same ones. (Remember I mentioned programmers having an 'accent'.
You can tell some groups of programmers by their accent).
Personally, I have a slightly different 'accent' from the NQC author.
I like to distinguish the names of *classes* and *structures* (which NQC
doesn't have) from *variables* and *functions*. I use a leading uppercase
character for class and structure names - and an initial lowercase letter
for variables and functions. I'm a C++ programmer (a bit more complex than
C) - and in that varient of the language, it's useful to tell the difference.
So, I wouldn't have written 'OnFwd()' - I'd have said 'onFwd()' - or more
likely (since the NQC names are 'special' and can't be redefined) I'd have
called it: nqcOnFwd(). Other people might have written 'on_fwd()', yet
others might have written:
TurnTheMotorOnForwards()
...I *hate* people like that! But it's like talking to someone with a strange
accent in English...you can generally understand what they are saying if you
concentrate - but it's harder than listening to someone who speaks with the
same accent as your own.
There have been (and continue to be) attempts to standardize on just one
'accent' for all programmers - but once you've been 'speaking' the language
for 30 years, it's hard to change your 'accent'.
> Ohhh, by the way, am I in the right NG of Lugnet to ask such basic questions
...probably. I guess this is truly a basic programming question that's nothing
to do with Lego at all...but we are a pretty laid back lot here.
--
Steve Baker HomeEmail: <sjbaker1@airmail.net>
WorkEmail: <sjbaker@link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
http://freeglut.sourceforge.net
|
|
Message has 1 Reply:
 | | Re: What are all those lego companies?
|
| (...) Tick. VG. (...) This is only due to inertia in the programming language world. Given the speed of current hardware, lexical efficiency is no longer as important as it used to be. It is quite possible to design language implementations that (...) (24 years ago, 16-Feb-01, to lugnet.robotics)
|
Message is in Reply To:
| | Re: What are all those lego companies?
|
| "Cyborg" <cyborg@euroseek.com> wrote in message news:G8s9A8.Lpx@lugnet.com... ---snip (...) ----snip First of all, thanks for the great information (especially Steve Baker) You guys really know your stuff. The RIS 1.5 arrived today, so did my Droid (...) (24 years ago, 16-Feb-01, to lugnet.robotics)
|
24 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
