On the cloud the variables are listed in alphabetical order based on their names...
bool _Device_AC_Power;
int _Device_AC_State;
float _Device_Fans_Current;
bool _Device_Fans_Power;
int _Device_Fans_State;
float _Device_Humi_Current;
bool _Device_Humi_Power;
int _Device_Humi_State;
float _Device_Light_Current;
bool _Device_Light_Power;
int _Device_Light_State;
float _Enviroment_Humi_Current;
float _Enviroment_Humi_Target;
float _Enviroment_Humi_Trend;
float _Enviroment_Temp_Current;
float _Enviroment_Temp_Target;
float _Enviroment_Temp_Trend;
...but in the primary ino file these are listed in alphabetical order based on their type, then the names...
/*
The following variables are automatically generated and updated when changes are made to the Thing
float _Device_Fans_Current;
float _Device_Humi_Current;
float _Device_Light_Current;
float _Enviroment_Humi_Current;
float _Enviroment_Humi_Target;
float _Enviroment_Humi_Trend;
float _Enviroment_Temp_Current;
float _Enviroment_Temp_Target;
float _Enviroment_Temp_Trend;
int _Device_AC_State;
int _Device_Fans_State;
int _Device_Humi_State;
int _Device_Light_State;
bool _Device_AC_Power;
bool _Device_Fans_Power;
bool _Device_Humi_Power;
bool _Device_Light_Power;
Variables which are marked as READ/WRITE in the Cloud Thing will also have functions
*/
Is there a standard practice for this as I find it easier to group them by name and ignore the type?
C /C++ lets you group variables in struct { } statements, creating new complex variable types to make such variables. Searxh on C struct and find a tutorial that you can understand. Simple, powerful.
While you're at that, minutes spent learning about arrays will save you hours wearing keyboards out and wasted time.
The order in which the variables are listed in the code is really up to you, unless a variable is making reference to a previously declared variable the compiler will not care, and the order has no relevance to where they are actually stored in the compiled code.
So, you can do whatever is most logical or the easiest (for humans) to read and understand.
I generally group by type, starting with the simplest (byte or int). And if I have "related" or "similar" variables of the same type (say, analog inputs) I'd group those together.
But with the "cloud" example it makes sense to group related variables together.
Unless they're within a struct, there is no guarantee that there will be any relation between the order in the source code and the order in memory - so the order you write them is entirely up to you.
It generally makes more sense to group things that are related together - but the compiler really couldn't care less.
If you create an array it will have a base address that the name of the array is a pointer to. Name + 0 is the address of the first element and the rest are in order address + sizeof( element ) * index is the address of each element. It is how pointers work with arrays, even arrays of function pointers.
char textbuf[ 40 [; // will be 40 chars continuous, order is address order.
It's purely a reference thing; an order that is easy for my wee brain to follow. That list is just an excerpt. The current list is about 100 variables... (I do use arrays to process data but these variables are the ones that talk back to the cloud).
If I reorganise the list, it just gets put back to the by type order whenever there is an update to the sketch.
I understand the compiler doesn't care, its just a little annoying that it doesnt put it in the order ive setup.
That would appear to be the result of something automatically generating the list of variables.
Given the rather fixed format of the variable list, automating the process of resorting the variable list would probably not be difficult, if you have a text editor that allows batch files or the like.
