Is a short tidy code neccessary ?

Seeing hardware types talking about coding is funny, almost as funny as seeing a programmer with a soldering iron ;D .

Flowcharting only works on small programs, after that you really need to look at something like UML if you want to model your program.

comments can be helpful, but well written code should be self documenting, use meaningful variable and function names, and make good use of indentation and structures like switches.

compact code can be good, but it is possible to make something too compact, for instance:

x=(a==b)?1:2;

is perfectly valid code, but readability wise is absolutely terrible, and will produce exactly the same output as

if (a==b)
{
     x=1;
}
else
{
     x=2;
}

what is easier to read to you?

what is easier to read to you?

It depends. Often the second version, but I’ve encountered situations where the first was a lot easier to understand and easier to read. I usually use the triadic operator when it’s absolutely clear that it’s part of the expression and making an if out of it would rip apart an expression that should stay together. Also, in situations where you have a bunch of that kind of expression, the many if statements can make a total mess out of the code. You just have to use the right tool in the right situation.

Korman

I disagree that flowcharts aren’t useful. Most people on this forum are not professional programmers. We write most programs from ground up, testing one module and then do some more. When you do it that way and your project grows into a much larger one than original program. If you don’t do a model like a flow chart, you’re lost at what you’re doing especially you don’t come back to it every day. At least I’m too old to remember all my details.

If you don’t do a model like a flow chart, you’re lost at what you’re doing

If your code is complex, a state diagram is usually of most use, perhaps a rough block diagram. A flowchart with its very linear structure is a just a bad tool to document. Also, more important than the diagram is a management synopsis of what the program does, what limitations it has and why you wrote it.

Korman

If your code is complex, a state diagram is usually of most use, perhaps a rough block diagram. A flowchart with its very linear structure is a just a bad tool to document. Also, more important than the diagram is a management synopsis of what the program does, what limitations it has and why you wrote it.

Korman

Wait, What? At least I know which end of a hot soldering iron to hold and to not solder with shorts on. :wink:

Lefty

Very good tip that, about the shorts, thanks retrolefty :sunglasses:

Re the flow charts, I reckon the whole idea of Arduino is to get people with little or no knowledge of micros to be able to get into it.

A lot of us probably have had a dabble at basic with flowcharts sometime, and can “see” the flow better.

Experienced guys can probably look at reams of instructions and recognise various routines there, even in the complex programs, but I don’t think that’s what this forum is about.

I guess most of us newbies are still trying different ways and patterns to light an LED, and perhaps simple flowcharts can help there…

In a commercial environment, probably.

In the stimulating Arduino world of hobbyists, experimenters and autodidacts, no!

I preface all my work with the phrase “It may not be the best way to do it, but it’s the way I’ve done it”.

Rgds.