Reforming datatype practices

I have always wondered why all examples in the arduino enviroment use int where not needed. Why not use byte?

byte bLedPin = 13;

This uses half the memory and is, in my honest opinion a much better practice especially in a microcontroller enviroment.

[the prefix b might be omitted, ofcource, but it is quite standard to prefix variables so why not encourage it?]

This is more a question than anything else, I just have to know if there is any good arguments for using ints where not needed.

I suspect it's a matter of habit, left over from C programming on systems that aren't memory constrained.

I'll take it a step further - I don't see why these are variables at all. To use your LED example, are you going to change which pin the LED is connected to while the program runs? I think it should be #defined.

-j

Indeed it was a stupid example. But I though about all loops and such.

Also, who not use the keyword unsigned a bit often? It can be helpful that the compiler let you know that it may be a stupid thing to do to try and set a led dim to -2, for instance.

I have always wondered how the #define stuff works, does the number get 'hard coded' into hex in the resulting hex file? [i thought it was just a simple find/replace operation] or how does it work? You see, I though that it would take 2bytes if defined, that arduino defaults to ints but that is wrong? :) if so, that is great.

I vote for 'better' practices concidering datatype and use of unsigned datatypes.

defines are more efficient because the compiler can hard code the values in the hex file. But sometimes a variable is necessary, for example when using an array of pins, and using byte is more efficient than int where a variable is necessary.

I think the arduino team is rightly more concerned about how easy an example is for the user to understand than how efficient the code will be. But the examples do influence user style and I also vote for introducing the use of the right sized data types (and #defines) in example code.

A #define (and all other preprocessor directives, e.g. #include , #ifdef, etc) are handled by the C preprocessor (cpp) and not the compiler. #define is a basic search and replace text operation that takes place before the compiler runs.

-j

A #define (and all other preprocessor directives, e.g. #include , #ifdef, etc) are handled by the C preprocessor (cpp) and not the compiler. #define is a basic search and replace text operation that takes place before the compiler runs.

That is correct but misses the point being made above. The compiler is more likely to optimize values that are #defined than values that are declared as normal variables.

Sorry, I should have quoted for clarification. I wasn't commenting on (or correcting or arguing with) anything you said, mem, I was trying to answer the question "I have always wondered how the #define stuff works".

-j

Now I feel bad for sounding harsh ;)

Jason, thanks for clearing that up :)

no problem, didn't sound harsh to me. tone is difficult to pick up, that's why on the internet we a) don't take it personally, and b) use those smiley things.

on all the points you brought up, we are in violent agreement. :)

-j

I think the arduino team is rightly more concerned about how easy an example is for the user to understand than how efficient the code will be.

Ofcourse, but I would argue that it equally easy to comprehend the byte datatype, as opposed to ints. In microcontroller world you are bound to either come across bytes and bits, or if you are an artist using arduino for leds and such, you already know that you need some mega bytes to store tha program. I do think that it is rather intuitive that the byte is a variable that can hold data.

Two last questions about #define: 1) are the variables then treated as constants by compiler? 2) does not arduino store the defines/constants in a integer datatype? [or does compiler check for how many bytes needed, tried google but no luck]

define is just a macro

#define pin 13
...
digitalWrite(pin,HIGH);

is identical to:

digitalWrite(13,HIGH);

You can put just about anything in a #define, i.e.

#define pinOn digitalWrite(13,HIGH)
...
pinOn;

You can also paramaterize the macro, Don K posted a handy example here for determining the length of an arbitrarily typed array:

#define ITEM_CNT(x)  (sizeof(x)/sizeof(x[0]))

While conserving every last bit and byte is important (when you start running out of bits and bytes), being able to do things generically and reducing maintenance are good things too.

Two last questions about #define: >1) are the variables then treated as constants by compiler?

defines of integral values are not variables, they are treated as constants

> 2) does not arduino store the defines/constants in a integer datatype? [or does compiler check for how many bytes needed, tried google but no luck]

The compiler uses the smallest data type that will hold the constant.

defines are more efficient because the compiler can hard code the values in the hex file.

You can also define a variable with the const attribute to serve the same purpose. The compiler will substitute the value as an optimization instead of allocating space in RAM for it (assuming there are no references taken of it). The added benefit is that the compile can type check uses of the "constant".

static const uint8_t pinLED = 13;

You can also define a variable with the const attribute to serve the same purpose.

Hi don, indeed you can , but

 #define pinLed 13

seems easier for beginners than

static const uint8_t pinLED = 13;

My reason for discussing the #define is the fact that the compiler can help with constants, just as don said. [I forgot to explicitly say this, but I somewhat tapped into it while argumenting for unsigned usage]

I do agree that #define seems easyer for beginners, and because of this a better arduino practice on pin declaration.

Sorry for resurrecting this thread, but I am not ready to lay this behind just yet.

I’ve been around in the Software troubleshooting/syntax&programs sections, and I found that in several cases their problems could’ve been supressed, if not solved, by using different datatype practices.

One topic that is pretty hot on the forum right now is the use of other processors with more ram/eeprom and such. [I do not argue that this is not an interesting topic] Almost all arrays I’ve seen uses ints when they could’ve used byte, this results in twice as much ram being used.
This quickly adds up when using multidimentional arrays, or a predefined sinetable.

I’m pretty sure that the use of ints can be traced to the examples and the returntypes of arduino core functions.

Am I the only one who would like to see the arduino being a bit more economic concerning datatype usage.

I think the community could benefit from some kind of standardisation regarding syntax used in libraries that are released into the public domain of arduino.
This would help users take advantage of usercreated libraries.

An example would be a set of rules of what do comment in sourcecodes, and if/how to prefix variables regarding datatypes or accessability. (int,short,public,private)

Is redefining the arduino datatype practices a lost cause?

I would be more than happy to be a part of such a reform. Either by forming a comitee or by creating a survey.

As a PostScriptum I would like to add that I do understand and I am aware of that the goals of such a project would be to make arduino even more userfriendly. And I would argue that by selecting the right datatype, the compiler becomes much more helpful. You can not set a digital pin to -1 if using byte, but you can try (and fail) if using ints.

I agree this is a good discussion to have – having clear and easy to understand guidelines on: '? comments, and if/how to prefix variables regarding datatypes or accessibility' would be a good thing.

Why not post your proposals and see what feedback you get

p.s. I don't think the compiler provides any more help with negative bytes than it does with negative ints – the compiler will accept a byte value of -1

the compiler will accept a byte value of -1

:o I've always thought that it would result in a compile error. I have no idea why... Hmmm.

Why not post your proposals and see what feedback you get

I will do that! But I figured code format and variable prefixes is a matter of preference, but I'll do my best making a versatile 'protocol'. I am a big fan of prefixes myself. Makes coding much easier when you resume coding on an old project.

I agree, code formatting is very much a matter of style and I don't think you will ever get a consensus on how it should be done. But your proposals should generate some interesting discussion and hopefully influence improvements in the documentation.

My two cents – in the arduino world, simplicity is more important than efficiency. BTW, I deplore prepending variable names with an abbreviation of its type. Names should express the purpose of the variable, not how its implemented.

My two cents [ch8211] in the arduino world, simplicity is more important than efficiency. [/code] Agreed.

But simplicity is relative. And for me, I evaluate simplicity true when code explains itself.

BTW,  I deplore prepending variable names with an abbreviation of its type. Names should express the purpose of the variable, not how its implemented.  [/quote]

I agree with you on this as well, but say I make a library for interfacing with GSM, and I have a variable call telephoneNumber, this could be a variety of things. If no 'rules' are present, it could be a define/const or it could be a string or it could be an int, you see where I'm going? Variable names becomes less descriptive in proportions to the program size. And also there are a numerous things that are not restricted to only one datatype.

I've made a v0.1 and that is made strict and overkill on purpose. Will post soon.

Thank you for feedback!