next topic »

[Reply #45 on:]

I usually don't use them in that case, it is visually pleasant for me. I am pretty strict with my code style. If there is a multiline else below I add the braces to make the code look balanced.

Of course what graynomad says is true, C can drive to convoluted stuff like the define thing, but I am 'porting' my C# style when I use arduino IDE and not viceversa.

[Reply #46 on:]

I usually don't use them in that case,

I confess that I don't a lot as well, but I'm trying to raise my game in regards to following some of these rules

In this example I think

Code:

if (cost > 2x)  digitalWrite(ledPin, HIGH);

Is neater, and allows you to see more code at a time on the screen. If you add another line you move them down and put them in {}.

______
Rob

[Reply #47 on:]

  .... and the more I find out,  the less I know .... :-)

but I am enjoying the learning !

[Reply #48 on:]

For those interested
In my experiance the java style is:

Code:

if() {
  code;
  }
else {
  more code
  }

old C school style goes like (or was it pascal?)

Code:

if()
  {
    code;
  }
else
  {
    more code;
  }

the most dangerous bug I ever had with not using {} when having a single line is

Code:

#ifdef DEBUG
#define TraceLocation Serial.print("I'm here");
#endif

if()
  TraceLocation
Will_only_be_executed_in_debug();

A good IDE allows you to tune the formatter to how you like it.
In most of the error examples in the above discussion the formatter will give visual clues that something is wrong.
I use eclipse and  formatter works fine for me. The only annoying thing is that you have to select your formatting settings with each and every workspace.
Best regards
Jantje

[Reply #49 on:]

"Old school" C (aka K&R)

Code:

if (boolean expression) {
  code;
  code;
}
else {
  code;
  code;
  code;
}

I've always used this, and like it visually because the closing braces line up with the opening "if". Saves lines, too.

I also like

Code:

if (bool exp) code;

because it saves lines (you see more on the screen at once... too much white space can be as bad as too little.)

And finally, for similar reasons, I will also use

Code:

if (b exp) code;
else code;

or even sometimes

Code:

if (b exp) code; else code;

Sometimes I'll vary it with

Code:

if (b exp)
  longer-line-of-code;
else code;

if it looks more balanced (and of course, just to annoy people like Jante ;-)

And to generalise, I delight in using

Code:

for (;;) code;

and

Code:

while (bool exp)
  code;

when it suits.

As an odd inconsistency (but also found in K&R) is the use of braces when declaring functions:

Code:

int myFunction(int avar)
{
  /* implementation in here */
}

Although it strikes me as stylistically a bit inconsistent, I've also decided I kind of like bringing the opening brace onto the next line for function declarations, rather than at the end of the line, as in a control block.

In short: Good enough for Dennis, good enough for me. :-)

[Reply #50 on:]

Thanks Pico,  it is all so clear now  :-)

[Reply #51 on:]

if it looks more balanced (and of course, just to annoy people like Jante ;-)

Pico
Not sure what makes you think I would be annoyed by this. When I get code from a third party I dump it into my editor who reformats it for me.
Anyway it makes me happy you want to do something extra just for me 

Best regards
Jantje

[Reply #52 on:]

Not sure what makes you think I would be annoyed by this.

Just teasing, my friend. ;-)

(I have had some Pascalians scandalised by some of my coding habits over the years. You are obviously familiar with Pascal -- I thought perhaps you might be just a little bit miffed at my complete lack of respect for unnecessary braces!)

[Reply #53 on:]

Just teasing, my friend. ;-)

(I have had some Pascalians scandalised by some of my coding habits over the years. You are obviously familiar with Pascal -- I thought perhaps you might be just a little bit miffed at my complete lack of respect for unnecessary braces!)

Yes I have done pascal; fortran; (visual) basic (for application); c ; c++; perl script ; bash ; shell; java; and others.
I have seen to much code (and have become to old) to get hung up on the formatting style. My advice: take the formatting style you like and let the formatter do the translation.
There is 1 exception to this rule though. That is when you start being a team member and having version control. But I won't go into that though.
Nor will I let myself be dragged in a naming convention war (which is way out f topic).

Best regards
Jantje

[Reply #54 on:]

Yes I have done pascal; fortran; (visual) basic (for application); c ; c++; perl script ; bash ; shell; java; and others.
I have seen to much code (and have become to old) to get hung up on the formatting style. My advice: take the formatting style you like and let the formatter do the translation.
There is 1 exception to this rule though. That is when you start being a team member and having version control. But I won't go into that though.
Nor will I let myself be dragged in a naming convention war (which is way out f topic).

Best regards
Jantje

  There are formatters for working with team too, not just minor indentation stuff, like this
http://www.jetbrains.com/resharper/

It is very strict, even with var names and makes your code very nice!

[Reply #55 on:]

I think formatting prefs is getting too in depth for this new IDE. I'm really targeting the new to intermediate developer. If you are a hard core user who wants to fully customize your development experience you should probably switch to a standard IDE like Eclipse.


Attached is the latest screenshot.  You can now open, edit, and save a sketch as well as compile and download it to a Diecimila (it's hard coded to the particular board I happen to have on my desk).  I've put the first code drop into a new repo on git hub here. Note that it's probably still not compilable by anyone but me, but you can poke around if you feel like it.

https://github.com/joshmarinacci/arduinox

In addition to the download feature it now has a standard font bundled in it (Ubuntu Monospace). The sidebar you see on the right is where the help text will go.  This *is* html loaded locally, but it is using Swing's text support which is a small subset of CSS 2. Still, it should be enough for nicely formatted help text.

Again the look and feel can be ignored for now. I want to focus on layout and features first, then worry about having a good color scheme, fonts, icons, etc.

So far the feature list is:

* create/open/save/download a sketch with minimum configuration
* intelligently save prefs for font size, window position, loaded tabs, USB port, etc.
* improve the layout, text editor, and tab system
* improve keybindings and other platform specific UX

What else should we have? 

* I really hate the current way you choose serial ports. Is there any way to know what device is connected to a serial port? Can't we detect if the arduino is an Uno vs Leo vs Decimila instead of having to ask the user?  I also hate having to use the /dev/usb blah blah names. On mac each port is listed twice and the bluetooth devices are listed, which is nonsense.

* Is there a better way to interact with examples?  What about common code snippets for novice users to use?

* code visualization? List the pins you are using?  Show a photo of your arduino board indicating the pins you are using.

Dream big folks!


- Josh

[Reply #56 on:]

Re the help. Can you have a hot key (F2?) to bring up the help for a function? Either based on where the mouse/cursor is or maybe you have to highlight the function.

Word boundaries. Currently the IDE uses inappropriate characters as word boundaries, for example

int in_Byte = Serial1.read();

If I double click on in_Byte because I want to copy it I only get "in" or "Byte", depending on where I click. In a programming language this should be considered a single word.

So either allow the setup of word boundary chars or just exclude some common ones like _.

This also applies to ^arrowing, if I ^ left arrow I want the cursor to skip the entire in_Byte, currently it's 3 key strokes to get over the var name.

______
Rob

[Reply #57 on:]

Re the help. Can you have a hot key (F2?) to bring up the help for a function? Either based on where the mouse/cursor is or maybe you have to highlight the function.

Word boundaries. Currently the IDE uses inappropriate characters as word boundaries, for example

int in_Byte = Serial1.read();

If I double click on in_Byte because I want to copy it I only get "in" or "Byte", depending on where I click. In a programming language this should be considered a single word.

So either allow the setup of word boundary chars or just exclude some common ones like _.

This also applies to ^arrowing, if I ^ left arrow I want the cursor to skip the entire in_Byte, currently it's 3 key strokes to get over the var name.

______
Rob

Current ide select whole var when I double click vars with "aaa_aaa" :O and CTRL+Shift+F opens the reference

[Reply #58 on:]

Current ide select whole var when I double click vars with "aaa_aaa"  :O and CTRL+Shift+F opens the reference

Not for me, but I'm using 1.0.

______
Rob

[Reply #59 on:]

* I really hate the current way you choose serial ports. Is there any way to know what device is connected to a serial port? Can't we detect if the arduino is an Uno vs Leo vs Decimila instead of having to ask the user?  I also hate having to use the /dev/usb blah blah names.

This depends on whether java can access usb and/or registry-related system calls.  You can theoretically get the usb device information associated with a serial port, and figure out whether they are likely to be Arduinos, and if so which type of arduino.  (although, I wouldn't rely on this entirely, since it's common practice to use somewhat random usb/serial converter chips/cables/etc as a cost-saving scheme.)
There's an example (for windows, where things are worse) at https://github.com/WestfW/ArduScan
The double-listing on Mac's is Apple's fault; can you really guarantee that /dev/tty.usbserial-xxx and /dev/cu.usbserial-xxxx are the same piece of hardware?

Could you answer my earlier question about Swing vs local editing styles?  I'm genuinely curious...

You're missing the existing keyword-based highlighting of Arduino Functions (digitalWrite(), etc)), and I disapprove of the reduction of information in the compiler interaction part of the display.  "we" have been trying to get more information there (RAM usage in addition to flash usage, in particular.)

Listing pin usage would be interesting.  Sort of baby-steps to actual simulation at some point...