mwc 2.0 ++

[Hamburger]

so we continue to develop in the _shared branch...
anyone willing to do the hard work and synchronize _shared with Alex' non-shared tree?

I did submit a multiline version of the LCDconfiguration menu. Far from perfect, but makes good use of smartphone/tablet screen and allows for better overview.

[pm1]

so we continue to develop in the _shared branch...
anyone willing to do the hard work and synchronize _shared with Alex' non-shared tree?

Maybe not too hard. At the first look there seems to be not much features beside LCD.pde in the shared branch, which didn't found the way into non-shared...

[Hamburger]

a big THANK YOUm Alex for doing the hard work and syncing / merging the two _shared and non-shared branches.

Question: in config.h you explicitly set the

Code: Select all

#define DISPLAY_2LINES

This is not neccessary, because in def.h we have code that uses the activated LCD_* to autodetect and set either DISPLAY_2LINES or DISPLAY_MULTILINE:

Code: Select all

#if !(defined(DISPLAY_2LINES)) && !(defined(DISPLAY_MULTILINE))
  #if (defined(LCD_VT100))
    #define DISPLAY_MULTILINE
  #else
    #define DISPLAY_2LINES
  #endif
#endif

I merely added the two options to config.h only for experienced users to overwrite the default (eg. for testing 2line on fullscreen terminal).
Do you prefer the user to actively set the DISPLAY_2LINES in config.h instead of the automatic scheme in def.h? Then I would remove the autodetection from def.h

Cheers, Hamburger

[Alexinparis]

Hi,

Sorry, I didn't see this lines in def.h.
I thought it wasn't defined.

Do you prefer the user to actively set the DISPLAY_2LINES in config.h instead of the automatic scheme in def.h? Then I would remove the autodetection from def.h

no, I think it's better like you did.

[Alexinparis]

Note: I'm currently working on the future serial protocol.
It will be more secure with a parity checksum, and the data separation will follow mavlink principle.

[Hamburger]

coding style / indentation

seems we should decide on a coding style / indentation rules. Alex is always busy correcting indentation, this should not be neccessary. I would like to stick with something common. Eclipse offers some builtin variants.
K&R looks like this:

Code: Select all

/*
 * A sample source file for the code formatter preview
 */
#include <math.h>

class Point {
public:
   Point(double x, double y) :
         x(x), y(y) {
   }
   double distance(const Point& other) const;

   double x;
   double y;
};

double Point::distance(const Point& other) const {
   double dx = x - other.x;
   double dy = y - other.y;
   return sqrt(dx * dx + dy * dy);
}

Available alternatives are GNU, BSD, Whitesmiths.
What do you think?

[timecop]

I think all the code should be formatted with:
indent -kr -nut -l400
(basically k&R style, 4space indent, no tabs.)
Definitely NO to long lines of stuff like
blah = 10; foo = 20; if (blah) bar();
properly indented code is first step to making it better.
btw, the snippet above is not K&R. opening brace on functions is always on new line, but on same line for conditional/loops.

[kos]

identation.. are you realy re-indenting the code by hand ? .. ctrl a - ctrl i should be enough.

...

proper variable naming and good comments are more important.

[timecop]

If you do not see the value of properly indented code (and can't even spell indent) then you're clearly not qualified to contribute to this discussion.

[ciskje]

If you do not see the value of properly variable naming and good comments then you're clearly not qualified to contribute to this discussion.

[Hamburger]

On formatting:
seems my code snippet got garbled by the [ code ] formatting software.
So here are some snapshots from what Eclipse offers and how that looks like.
BSD

BSD

GNU

GNU

KuR

KuR

whitesmiths

whitesmiths

I'd say no real benefit from GNU, but it uses the most vertical space - bad.
Personal favorite is KuR.

[howardhb]

+1 for KuR!

[Alexinparis]

Hi,

Please don't break the current indent
I tried to correct it in LCD.pde, but I gave up...

I use only Arduino IDE to code, nothing else.
I think It's something like K&R style + 2 space indent and no tab.
If you use a third party IDE like Eclipse, please adapt it to use the same style.

generally speaking:
something after a { should begin 2 spaces after on the next line.
something after a #if should begin 2 spaces after on the next line.

I don't know if keeping # statement at the same indent as the other code (and not at the beginning) is clean or not, but I find it more readable.
here is something which is difficult to read for me:

Code: Select all

    case 0:
#if MAG
       Mag_getADC();
#endif
       break;
    case 1:
#if BARO
       Baro_update();
#if defined(LOG_VALUES)
       if (BaroAlt > BaroAltMax) BaroAltMax = BaroAlt;
#endif
#endif
       break;
    case 2:
#if BARO
       getEstimatedAltitude();
#endif
       break;
    case 3:
#if GPS
       GPS_NewData();
#endif
       break;
    }

here is something more natural for me:

Code: Select all

    switch (taskOrder) {
      case 0:
        #if MAG
          Mag_getADC();
          break;
        #endif
      case 1:
        #if BARO
          Baro_update();     
          break;
        #endif

please try also to gather as possible the place where LOG_VALUES appears.

coding style / indentation

seems we should decide on a coding style / indentation rules. Alex is always busy correcting indentation, this should not be neccessary. I would like to stick with something common. Eclipse offers some builtin variants.
K&R looks like this:

Code: Select all

/*
 * A sample source file for the code formatter preview
 */
#include <math.h>

class Point {
public:
   Point(double x, double y) :
         x(x), y(y) {
   }
   double distance(const Point& other) const;

   double x;
   double y;
};

double Point::distance(const Point& other) const {
   double dx = x - other.x;
   double dy = y - other.y;
   return sqrt(dx * dx + dy * dy);
}

Available alternatives are GNU, BSD, Whitesmiths.
What do you think?

[Hamburger]

K&R, 2 space indent is fine.
Indenting the cpp macros may be different. Eclipse does not do it automatically and autocorrects it always. Not sure if that can be changed easily. Also in the old days cpp did not guarantee to always work on #something directives with leading white space. Not sure if they changed that.

Could we also agree on the following:
- macros are all capital letters with optional underscores
- variables either all lower case, or start with lower letter and use Camel style (cycleTimeMax) or get an all capitals prefix for the realm like GPS_latitude ( I found BaroAlt difficult to identify, rather prefer BAROalt or BARO_alt)
- function names ? it seems to be good practice in MWii to start with (optional the realm in all capital letters followed by) lower letter+Camel for functionality (like LCDconfiguration() or SOMESENSOR_init() ) - so same rules as for variables?

Please do not get me wrong, we do not want the Format Polizei; merely readable code without too much hassle and take the burden from Alex to re-format the code all the time.
Thanks.

[kos]

use Camel style (cycleTimeMax) or get an all capitals prefix for the realm like GPS_latitude ( I found BaroAlt difficult to identify, rather prefer BAROalt or BARO_alt)

everything with underscore or all upercase is const or a define, it is ok to use upper case for acronym or short word [1]


int GPSMaxSpeed = ok
define GPS_ALT_MAX 33000 = ok
int BAROalt = ok

int BARO_alt = bad
void INIT() = bad
int GPSHOME_latitude = bad

1 : http://en.wikipedia.org/wiki/CamelCase# ... _computing

[Hamburger]

while we are at it:

I think it is about time to create a proper Credits.txt file and remove the various names that are sprinkled all over the code sections.
ok?

[Hamburger]

...and more importantly a Maintainers.list

[Hamburger]

Please have a look at _shared.
I created the credits file and reformatted LCD.pde.
Anyone know how to indent cpp in Eclipse?

[Alexinparis]

Hi,
No problem to create a Credits file, but with exhaustive information. (I see some missing info about OpenLRS contribution).
It would be better if a small summary could be added for each contribution.
I know this is some more work for you, but it's your initiative

I'm not in favor of a Maintainers.list

[Hamburger]

Hi,
No problem to create a Credits file, but with exhaustive information. (I see some missing info about OpenLRS contribution).
It would be better if a small summary could be added for each contribution.
I know this is some more work for you, but it's your initiative

ok, will do (with low priority). Just copy more of the CREDITS format over from linux. What is good for them should be good enough for us.

I'm not in favor of a Maintainers.list

ok.

[jevermeister]

Can someone please upload a info.txt with coding rules into svn?

SAo we all know what to do to code correctly

[Alexinparis]

Hi,
Look at the readme file in http://code.google.com/p/multiwii/sourc ... vn%2Ftrunk

note you already violated one rule
"no more tabs"
but your idea to add a buzzer tab is ok.

[Hamburger]

So far, the best I could come up with is

Code: Select all

indent  -kr -l100  -i2 -ppi 2 -nut  -brf

This still manipulates the cpp macros in an unwanted style. (Besides, on macosx 10.5 the included indent is not capable of this options set).

Anyone know how to indent cpp in Eclipse?

again - anyone?

[Tommie]

May I ask why everyone hate tabs?

Tabs have one major advantage over indentation by spaces: You can adjust the visual represenation to your liking without changing the code. Want to see more? Just instruct your editor to show tabs with a width of 2 spaces. You cannot do that with spaces, you are bound to the width present in the source file. That makes tabs IMO superior. They distinguish the represenation of the application logic from its visual representation.

[Hamburger]

Tommie,
Your argument is true. But I do not care about tab vs zpaces. In eclipse refomating is only one keystroke away.
Now with indentation of cpp directives in sync with code indentation is a different matter.

[Alexinparis]

May I ask why everyone hate tabs?

Tabs have one major advantage over indentation by spaces: You can adjust the visual represenation to your liking without changing the code. Want to see more? Just instruct your editor to show tabs with a width of 2 spaces. You cannot do that with spaces, you are bound to the width present in the source file. That makes tabs IMO superior. They distinguish the represenation of the application logic from its visual representation.

The only reason is to be compatible with what Arduino IDE provides