next topic »

[Reply #15 on:]

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.

[Reply #16 on:]

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

[Reply #17 on:]

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.

[Reply #18 on:]

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.  

[Reply #19 on:]

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.
[code]
BTW,  I deplore prepending variable names with an abbreviation of its type. Names should express the purpose of the variable, not how its implemented.  

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!

[Reply #20 on:]

Extract this in arduino install directory
http://home.nith.no/~breale/Arduino/hardware.rar

Under
-hardware
 -libraries
  -DatatypeAndSyntaxReform
   -LED_Reform01.h
   -LED_Reform01.cpp
   -examples
    -Blink.pde //example usage
   -DatatypeAndSyntaxReform_v0.1.zip
    This contains a default .cpp , .h , .pde and some documents that defines some coding rules. Naming variables and code format.

I'd be most gratful for any feedback. And Especially criticism. That is my favourite way of learning. Finding arguments, and learn from others.

[Reply #21 on:]

FWIW I'd be more inclined to read this if it was up on the web somewhere rather than having to download a file. :-)

--Phil.

[Reply #22 on:]

Uh, I always forget...
Here is:

[size=22]Sorry for the long post, there was no way around[/size]

[size=20]Example files:[/size]
Example h that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/LEDClass/LED_Reform01.h

Example cpp that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/LEDClass/LED_Reform01.cpp

Example pde that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/LEDClass/examples/Blink/Blink.pde

[size=20]Reform description:[/size]

http://home.nith.no/~breale/Arduino/Reform_v0.1/

[size=20]Naming of Classes and Functions:[/size]

Classes are prefixed C
Abstract Classes are prefixed AC
Class names start upper case after prefix
Functions start lower case

[size=20]Variable Protocol:[/size]

DATATYPE SELECTION
      Always use the variable type that uses the least amount of RAM but has appropriate min / max values.
      Always use const when suitable

      If the bit-width is crucial use a typedef 'typedef uint8_t my8bit'or a 'struct MyThreeBitDatatype { unsigned char : 3; };'

      
VARIABLE NAMING:

      Private member variables start with underscore
      
      Variable names start with prefixes that indicate datatype [after the member underscore]
          -bool           b       bVariable
          -char           c       cVariable
          -byte           by       byVariable
          -int            i       iVariable
          -unsigned int   ui       uiVariable    
          -long           l       lVariable
          -unsigned long  ul       ulVariable
          -float          f       fVariable
          -double         d       dVariable
          -struct         st      stVariable
          -enum           e      eVariable

      arrays should be prefixed by datatype prefix followed by a
          -short[] saVariables;       //public string array
            
      Object instances should be prefixed o
      Object instance variable names should also describe the originated class
          -Shape _oShape;         //private object of class Shape
            
      Pointers should be prefixed by datatype prefix followed by p
          -int* _ipVariable;             //private int pointer
            

[size=20]Control Structures:[/size]

===============================================

if ( condition )
{
      execute1();
}
else if ( condition )
{
      execute2();
}
else
{
      execute3();
}
===============================================

while ( condition )
{
      execute();
}
===============================================

do
{
      execute();
}
while ( condition );
===============================================

for ( initialization; contition; modify; )
{
      execute();
}
===============================================

This following syntax might seem a bit wierd
But it is to ensure that any variables initiated
in a case block gets destructed before the break.

switch ( expression )
{
      case condition1:
      {
            execute1();
      }
      break;
      
      case condition2:
      {
            execute2();
      }
      break;
      
      case condition3:
      case condition4:
      {
            execute4();
      }
      break;
}

[size=20]Code Protocol:[/size]

//Name according to 'Variable protocol:'
//Always initiate to a default value
//Exception is inside for loops, where variablenames like x,y,z,i,j,k,l is accepted
//Curly brackets always 'triggers' a line feed.
//Paranthesis has whitespace on both insides [i.e ( condition )]
//C++ Keywords see 'Control Structures'

if ( condition )
{
      execute;
}
//Space after keywords

//Functions:
//Name according to 'Naming of classes and functions:'

returntype functionName( parameter:datatype parameter:name )
{
      return returntype;
}
Funcion names does not get followed by a whitespace as keywords do

[size=20]Descriptions and Comments:[/size]
http://home.nith.no/~breale/Arduino/Reform_v0.1/DescriptionsComments.txt


[size=20]Default files with descriptions:[/size]

Default cpp that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/Reform_v0.1/default.cpp

Default h that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/Reform_v0.1/default.h

Default pde that is conform with suggested standard:
http://home.nith.no/~breale/Arduino/Reform_v0.1/default.pde


[size=18]Thougts, questions and disagreements are very welcome![/size]  

[Reply #23 on:]

All the opening squiggly brackets are on the wrong line  ;D

[Reply #24 on:]

Yay! Let the code format wars begin...

I vote for:

Code:

if (condition){
  doStuff(args);
} else {
  doOtherStuff();
}

void doStuff(int args) {
  ...
}

etc.

Andrew

[Reply #25 on:]

All the opening squiggly brackets are on the wrong line

http://en.wikipedia.org/wiki/C%2B#Language_features

The way of the wrong line has become the standard. And are used in all programming books on my shelf.

Code:

if (condition){
  doStuff(args);
} else {
  doOtherStuff();
}

I like to code that way myself, but it's hard when you read others code that is formatted that way.

Let the code format wars begin...

We do not need to make it a war, a debate would be nice. And ofcourse, an arduino standard should not be so strict to disapprove of either using 'correct lines' or 'wrong lines'. But when talking about squiggly brackets, I would like to encourage the use of them after all if and else if. In such a manner that Andrew posted. (and I quoted into a [ qode])

[Reply #26 on:]

But I like high density commands like ?: , excessive scrolling and its effects on productivity has to weigh in somewhere.  

And there is no "standard" on the squiggly.  

Also, I can't hang with  Hungarian notation. or leading underscores, I'm in agreement with with Linus and Bjarne on that one.

We are lucky to get anyone to work on anything around here.  Stringent rules won't help or get followed most likely.  I wouldn't mind some productivity oriented guidelines though, based on what we've learned about such things.

For example, I do like python, it makes you indent correctly, while at the same time it gets rid of most squigglies too.

Also I like the lack of duplication in java (no separate header files and prototypes).  The class definitions say it all.  Arduino already assists in this manner, by adding the appropriate includes and prototypes to the beginning of the scripts.  I really like that.

[Reply #27 on:]

The way of the wrong line has become the standard. And are used in all programming books on my shelf.

The not-so-serious 'way of the wrong line' was to indicate a not so serious statement. But I see now that it was not easy to see.

Also I like the lack of duplication in java (no separate header files and prototypes).  The class definitions say it all.

I disagree. The h / cpp division enables users to write classes but only releasing the .o + h and by doing this, one does not have to write a API, but java solves this by having a javadoc generator.

I like being able to skip the implementation while browsing for functionality. But this was a bit offtopic.

excessive scrolling and its effects on productivity has to weigh in somewhere.

Cryptic code and its effects on productivity (as it takes time decrypting/interpret) has to weigh in somewhere too, not to say that lineshifting the { / } makes code that much easier to read. [I am also found of high density commands.]


[size=16]What if we concentrate on the selection and naming of variables in the beginning?[/size]

And maybe come to some loose agreements on code structure.
I know about two general things I would like to implement into all arduino core libraries and examples. (because these files sets the standard for many people.)

1) The use of { } after all if and if-else
2) The use of scope resolution operators { } after case before break

...an arduino standard should not be so strict that it disapproves of either (... nor...)

[slightly modified]


How do you guys feel about making a standardization committee?
This committee should ofcourse validate and post/log all of their work. It's role should be to take decisions based upon the public and tha arduino team? And ofcourse revwrite examples and code to suit the new standard.

[Reply #28 on:]

Maybe it's just me, but I would prefer to think about what arduino the language *could* be, rather than weigh it down with preconceptions about C.  

So I would approach it as "what are the best features of various languages and IDEs" then trim it down to what is doable and appropriate.  But try and make the computer do all the work in any case (i.e. auto code formatters).

[Reply #29 on:]

Maybe it's just me, but I would prefer to think about what arduino the language *could* be, rather than weigh it down with preconceptions about C.  

An excellent idea! (As long as it does not rule out the use of 'regular' c/++)

Any specific ideas?