MPLABX auto code formatting

[crashmatt]

Somewhere we had a conversation about code style.  MPLABX has an auto formatting tool that can be set to most styles.

IMHO the default style is horrible.  This is entirely my own opinion and will probably divide the developers much like marmite will.

If you have not tried marmite, it is a taste sensation you will be deeply emotional about, one way or the other.

[Mark Whitehorn]

Regarding the formatting conventions that Robert is currently using in trunk:

Is there any way to set up the MPLABX auto-formatting tool to match?

I've had no success with that and would be disappointed to find it's no longer usable on MP code.

regards,

Mark

[Robert Dickenson]

The choice of formatting I have been using had little to do with any 'standard' style conventions. All I was aiming for was consistency across the codebase, and so to that end I adopted what I could see as being the most common formatting that already existed in MatrixPilot, and applied it uniformly.

When the topic of tab size was briefly discussed here, there was clearly a number of disparate opinions as to what is 'best'. After a few hours of online research on the topic, I opted for what I felt was well argued that tabs be used for indentation, and spaces for alignment. This way we can all choose our own preferred indentation size, be that what some felt should be 2 spaces, all the way up to what the google code viewer uses at 8 spaces. I personally am using 4 character indentation, which seems to be a reasonable compromise between the two common extremes.

I also aimed for consistent use, or rather avoiding over-use, of whitespace, especially with respect to blank lines. Within statements, function prototypes etc, once again I went with what seemed to already be most prevalent in the MP source. I used the same rational when it came to placement of braces. I personally was previously inclined towards braces on the same line as an block opening statement, with a few exceptions (ah there's always exceptions). However once again the existing code was heavily represented by braces on their own line, so that was the consistency I went with.

I'm not sure about MPLAB-X auto-formatting options. I've had a go at configuring it, and do have a setup which seems to be very closely aligned to the convention I have adopted when trying to standardise the layout of our code. The one notable exception being tabs versus spaces - for which for all I can tell, the X IDE seems a little broken. I was never a fan of using tabs in code, and have gone slightly mad in the past converting large projects to be tab free. However after reading some of the online arguments presented by what seem to be highly experienced open source coders, stuck with them for initial indentation.

Bottom line was, while aiming for consistency, I tried to find a compromise which meant changing as little as possible. As I can appreciate from all those it has impacted, and especially from the amount of work it ended up being, that was still quite a lot.

And btw, I prefer vegemite (-;

--
You received this message because you are subscribed to the Google Groups "uavdevboard-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to uavdevboard-d...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mark Whitehorn]

Then let's standardize on the "MPLAB-X auto-formatting options... which seems to be very closely aligned to the convention I have adopted".

You could export your settings from the IDE to a zip file and publish it in SVN. 

regards, 

Mark

--
Mark Whitehorn
kd0...@gmail.com

[Peter Hollands]

Mark,

I think Robert just enclosed the settings zip file in his post.  Did you see that ?

Best wishes, Pete

[Mark Whitehorn]

Pete and Robert,

Many thanks, and sorry, the attachment is visible way down the page, but I missed it.

I'll have to try vegemite one day too :)

73, Mark

[Mark Whitehorn]

Robert,

On importing your editor settings, I noticed that the C, C++ and C header options were still set to expand tabs to spaces. Attached is a version which I believe turns those options off.

73, Mark

--
Mark Whitehorn
kd0...@gmail.com

[Tom Pittenger]

This file should be committed somewhere, perhaps in /tools?

[Jasmine Adamson]

On Tuesday, November 5, 2013 8:30:04 AM UTC-7, Mark Whitehorn wrote:

expand tabs to spaces

OMG that drives me nuts! Since we're all using MPLabX maybe it doesn't matter, but I've seen devs use 2, 4, 5, 6 spaces for each level - I've seen that be inconsistent within a file. Tabs do not have that problem - 1 tab is one indent level, always and forever, regardless of what code editor you are using, all the tabs will look the same. So, I can have my code look how I want it and you can have yours look different if you want - same file.

Why tabs are better...

• They're a character specifically meant for indentation
• They allow developers with different preferences in indentation size to change how it's the code looks without changing the code (separation of data and presentation for the proverbial win!)
• It's impossible to half-indent something with tabs. So when you copy code from some website that used 3 spaces into your 4-space indented file, you don't have to deal with misalignment.

 Over the years I've obviously had this argument a bunch of times, and the only bottom line I've ever reached is "you should do whatever makes it easier for people to open a code file and have it look the way they want" and "don't do anything to prevent that" - spaces enforce the look that someone else wanted, tabs don't.

[crashmatt]

@Jasmine.  I have to agree this could drive us all crazy.

Our core problem is that if you do any large formatting changes then doing code diffs and merges is horrible.  We have a huge bunch of branches and are struggling to get them back into one place.  We are sort of stuck with whatever format was used at the time of original writing.

I would pick written, tested, commented and documented code over pretty code.  My own coding style changes with wind direction which does not help one bit.

Regards Matt

[Jasmine Adamson]

I've been a programmer for 30 years, so yeah I follow all that. I'm spoiled because I work in Visual Studio most of the time. My comments above were completely unnecessary, and the following is just chit chat too.

I've done quite a few big merges using Team Foundation and SourceSafe - the diff tools and SC are mostly the same as anything else. My opinion on big merges is they should be done by one person, and everyone else should be locked out during that time. In the past, when I've done it, I've basically gone through all the branches and auto-formatted the code - to any style as long as all the files were the same. Then the merge is a little easier, but you still need someone who knows the system very well, who can make decisions when there is conflicting code.

I can read code of any style as long as it's not minimized or obfuscated or something like that. In jobs, when this situation arises, I usually defer to the younger developers and let them have things the way they want, because they are much more hampered by style issues than I am.

I generally agree with RobD comments above though... I agree with him on tabs vs. spaces, I personally prefer opening braces on the declaration line and closers on their own line, but I agree with the reasoning given to leave it how it is. I prefer that openers on the declaration line because it allows me to see more code on the screen - same thing for empty lines, they are a nice way to break up pseudo-blocks, but there should never be more than one blank line in a row. Because most of us work with color-coded editors, I prefer no blank lines after comments - prefer the comment to be grouped with the thing it's about. These are just personal preferences, mostly chosen because they allow me work faster, but they don't affect the logic, so they are not that big a deal overall.

[crashmatt]

Jasmine,   Feel free to get emotional about this project.  For most of us it is a hobby and we are here to for the kicks.  I have plenty of my own rants about it so I can't deny someone else having theirs.

The team is a mixed bag ranging from mathematicians and weekend rocket scientists to electronics engineers with delusions of software engineering grandeur. It is good to have another experienced software engineer joining us.

Developments have been wherever we feel like in whatever way we feel. The result is that it does some amazing things very well but it also does some basic things badly or not at all.  For example, the IMU performance (thanks to Bill) is world class but there is no good way to store waypoints yet.

Let us know if you are interested in developing code features in any particular direction.  We will be happy to give you guidance.

Regards Matt

[Jasmine Adamson]

Thanks, Matt. I'm mostly just interested in flying at AVC this year. I haven't even tested my plane yet though, might be able to do that Sunday, we'll see. I'm willing to work on the code, if needed, to meet the goals at AVC - bomb dropping, limbo, and auto-landing. It has been a long time since I did any math intensive programming though. However, I am the author of "Supernova Grafix" which was a 3D engine for Mac, in C, heavy use of matrices and all that. So, I'm hoping I can contribute with that experience. At least I do understand most of the code I've looked at so far, but I have minimal micro-controller experience so I'm still learning a lot. I know Mark W through our RC club, and he's the one who told me about this.