Hey guys!

The "Format Code" Function is cool, but the style is not what I like to see. For example I would write the Hello World example as this:

#include "mbed.h"

DigitalOut myled(LED1);

int main()
{
    while(1)
    {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}

It would be great to have a global "Format-File" (or for each project). This could contain some Source Snippets you can format like you want. Here an example

Standard

int var;
int * pointer;
if ( 1 != 2 ) {
    //4 space chars
}
void function ( int a, int b );

I for example would change it to

int var;
int * pointer;
if(1 != 2)
{
    //4 space chars
}
void function(int a, int b);

Me 2

{
    Me 2,
}

What about brace matching ?

I think code folding would be nice too !

Ceri.code

I agree too!

I agree too. I've been programming for 20 years and have always used brace matching. It just looks logical.

Changing the indent is something I do manually in every file at the moment.

I do too. I just don't see the logic in doing it the other way; it makes the code look like Basic or Pascal. Using brace matching is an easy way to catch a lot of bugs.

Sure, I agree.

Code formatting and colorisation options are things that have been asked for multiple times, but they never seem to get an official response.

I just wanted to make a clear statement that what the mbed guys might consider small things, can actually be very annoying and impact the experience quite deeply. Annoying enough for example that I'm willing to manually indent every file.

Something like indent width would be so easy for the mbed people to make customisable, so in terms of a trade-off between annoyance factor vs ease of implementation, it seems strange that they haven't bothered to address feedback in this regard. This makes the cynical part of me think that whoever has the power to affect this wants to deliberately enforce his personal style on everyone else.

People might think I'm coming across as ungrateful for this resource that mbed provides, but the point is, I contribute to this as well, and have released libraries and ported things specifically for mbed. Sure, I needed them myself, but I didn't have to share it. What I'm trying to relate is, I think mbed should listen to feedback because we all contribute to mbed by being part of the community.

Ashley

Hello Ashley, All,

First, I'd like to thank you all for the suggestions and recommendations. Your feedback is valuable for us and for mbed as development ecosystem, and it's great that you take time to express it.

Often there are conflicting suggestions and feedback, especially when they based on subjective preference, rather than practical reasons. The coding style is one of them.

Most of the developers use 4 spaces for indentation, hence it's the default indentation value in majority of editors/IDEs. Some developers prefer 3 spaces indentation, others 2, and some even 8 spaces, and usually there is an option for that in most offline IDEs to control that. The mbed Online IDE aims provide a standard "out-of-the-box" experience for everyone and given its tightly collaborative nature, it has the difficult task to set a standard not just for the individuals, but also for developer groups and literally everyone.

Deviating from this can have undesirable effects, like repository commits that are mix between coding style and functionality changes, caused by different "auto-format" behaviors due to different style settings in the IDE. Imagine a situation where for example Ashley has his mbed IDE set to indent with 3 spaces and he imports a random project that uses 4 spaces. Every code block that he writes will be indented to 3 spaces due to his settings, and that won't match the formatting of the existing source code. Basically he would have two options:

• change his settings to use 4 spaces width and re-indent the code that he added/changed
• re-indent the whole file by using the auto-format function, creating commit/diff havoc

If the code style differences increase over time, this could lead to everyone always clicking the auto-format button as soon as they start working on someone else's code... That will impact mbed as a whole and I won't be surprised if people begin forking code just to have the program/libraries indented to their own style.

The overall goal of mbed was always to improve productivity of embedded software development. One of the many ways we try and do that is to encourage a consistent style across all code, the style which is set by the auto-format code button. This doesn't mean we stop anyone from using their own style, but rather provide an automated functionality for the ones used to the K&R style.

As for not providing an official response, you can find an official response by Simon Ford on the following link: https://mbed.org/forum/bugs-suggestions/topic/2929/

On a side note, the aforementioned colorization options are already in our to-do list, but currently I can't tie a time frame to that.

Cheers,
Mihail

Hi Mihail,

Thanks for the response and for digging out that official response. I stand corrected on that one ;)

I can understand some of the argument you are making regarding these style collisions, but it shouldn't cause major problems if people use it properly.

If somebody re-formats the entire file, then that's their fault, and they would have to deal with the commit consequences of this.

But normally someone is not going to do this.

I can see the problem if Ashley is on 3 spaces, and Mihail is on 4 spaces, and Ashley edit's Mihail's file and adds a function and indents it to 3. But this is then an etiquette problem. Ashley should indent the function in Mihail's file according to Mihail's style conventions.

But if Ashley creates his own file, then he should be able to dictate the sylistic conventions and set the indent to 3.

You could have an option "indent width for new files" and store the value per file. So if Ashley imports Mihail's 4 space file, then Ashley's settings should be set to 4 for that file. Then your collision problem won't occur.

So I understand the arguments, but I don't believe they are beyond a technical solution.

Ashley

I'd just like to add my 2¢, I agree with Mihail, the code formatting should be standard. However, please give us the ability to customise:

1. Font size and typeface

2. Syntax colouring (or at least provide built-in "Solarized Dark" and "Solarized Light" schemes which are wildly popular.)

To fellow mbedders, I also have a tip: until these changes are implemented, you can always clone your repository to your local hard drive via mercurial, and edit the files in your favourite editor (i.e. Vim, right?). Then you "just" have to: commit and push on your machine, then update and compile in online IDE.