automatic formatting/commenting suggestions

[maitchy]

Just a thought - could the editor automatically add end-of-line comments after certain commands, such as:

1. after a goto or gosub label copy a comment from the label in the program, e.g. if I enter:

gosub LcdOut
LcdOut: ' send character in b0 to the LCD

then it might automatrically make the gosub line:
gosub LcdOut ' send character in b0 to the LCD

This is something that an old Data General BASIC did, which was a good aid to readability.

2. indent for/next loops nicely, based on the nesting level

also an idea from DG Business BASIC

3. if peek/poke a constant location is used, add a comment from an external, user-edittable text file that has a comment per location for each picaxe model?

4. optionally add a comment after each IO command that references a pin and say the "leg" number (for the selected picaxe chip) or the standard register pin name (e.g. RA2), or allow the programmer to give the leg number or any of the other common names that identify the pin, e.g. "hpwm D" and have the port name shown as a comment?

Note that I think the documentation can lead people to make errors too easily; this would help avoid some of that. For example, the documentation for pwmout, page 115, says to use pin 2 on a 14M, and says to see the pinout diagram, yet neither the diagram on page 70 of manual 1, nor that on page 20, shows anything called "port 2"... there is input 2, output 2, C2, etc. If programmers could be given the option of specifying the leg (e.g. high leg7) and the compiler does the translation for code generation (e.g. high portc 3 'leg7 on 14M) that could aid clarity. Related to that: I see you can sometimes write: portc pin0 (for inputs)... why can't we write "portc pin0" or "portc 0" or "port c0" or "pin C0" or even "RC0" for any input or output statement? Standardisation on one form would be nice, of course, but it is also important to clearly relate software to hardware naming conventions (of which there are several).

5. perhaps as an option when printing programs, have label cross-reference tables, statistics such as code size per section of code, etc... becoming more important as larger programs become possible with the bigger chips. This (and auto-indentation, etc) could be implemented simply by allowing a post-processing filter to be specified when printing.

Mark

 

[BeanieBots]

I'm not sure how it would ever be able to generate the text that would be meaningful. Only YOU know what the specific line does.

There is of course the symbol directive

Symbol Physical_Leg_21 = 0

High Physical_Leg_21 'set output 0 high on a 28X

Personally, I prefer to use names that relate to what the pin does.
Your symbol defs and the circuit diagram pull it all together.
eg
Symbol Int_Reset = 3
Pulsout Int_Reset,10 ' apply 100uS reset pulse to Integrator on pin 24

 

[hippy]

I'll second BeanieBots suggestion for using SYMBOL. That's the easiest way to make programs portable so it's often only necessary to change symbol definitions to run the same program on different hardware.

Using leg names, even pin numbers, for commands is IMO a bad idea in general. Automatically inserted comments may help, but they would also have to automatically change whenever the command changes or the comment won't be correct any more. Once a program uses named legs or specific port pins it cannot be used on another PICAXE which may have its I/O on different ports or different legs.

Being able to tell code size in routines would be useful, but due to being able to jump into and out of routines could make that hard to implement. Having a list of labels and their address in program space would be useful in that respect. Being able to click on a line or lines and see how much code is used could also help.

A one-click option to make the program properly indented would also be a good idea.