@JohnInTX

I have spent more than two hours on internet to understand purpose of Tree Diagram in embedded systems design. I am not getting information anywhere like the INPUT, PROCESS, OUTPUT you have mentioned.

It would be great help to me from your side if you can post any sample Tree diagram, Not a difficult that you made for yourself. at least i will get some clue to understand it.

 

Like a few others have said, getting the "design" or logic correct before programming. I've done a few PIC projects for a friend, and his requirements are written out in "english" sentences. My interpretation of what he asked for was literal. When the code didn't work as intended, he would say "that's not what I meant" by his statements. I always asked for a logic flow, including exceptions but never got anything more than plain sentences as to what it should do. Only reason I did the work, is I'm getting used to reading his mind as to what he really wants....

As a general statement, I always found that the biggest mistake I've seen from other programmers is what does the code do when something happens that is not expected (exceptions). Many people do not put in proper trapping of errors and alternate logic to handle it. Way back in the late 70's, when we programmed process control stuff, I was taught to make the code "gorilla proof". That is, assume the operator had the mentality of a gorilla (apologizes to gorillas), and our code had to handle whatever they did, including deliberate banging on the keyboard... Operators back then hated computers because it kept accurate track of how the plant was actually operated.

 

In my opinion, the biggest programming mistake is not considering what happens when a condition is NOT satisfied.

When reading from a data source (or device), you must code for situations such as:

• There is no data available
• After reading data, what do you do when there is more data. No data
• How does your code verify that the data is expected and correct
• When reading data, how do you verify that the input is configured correctly? That you can actually read data?

I’ve seen too much code that ASSUMED that the data can be read and that it’s always correct. It doesn’t verify what data is to be expected, that enough (or too much) data was read. If this isn’t done, parsing the data will result in garbage.

Let’s say you’re expecting a result, identified by a certain token and has a fixed amount of data. Without the verifications I list, your program will execute the wrong code and return garbage.

Data drives code. A program that uses (for example) SELECT cases to call code to process the data will ONLY execute the proper code (please feel free to ask me follow up questions; I’m a little tired and may not have been clear)

 

@JohnInTX
I have spent more than two hours on internet to understand purpose of Tree Diagram in embedded systems design. I am not getting information anywhere like the INPUT, PROCESS, OUTPUT you have mentioned.
It would be great help to me from your side if you can post any sample Tree diagram, Not a difficult that you made for yourself. at least i will get some clue to understand it.

It was just an example. I picked those functions to fit the 3 dots on the second row as an example of what some program might do. Here are some trees used in a top-down design example:
https://cgi.csc.liv.ac.uk/~frans/OldLectures/2CS21_Ada/week6/topDown.html
Don't get hung up on it. It's just another way of organizing and showing what the program does. The linked document shows flow charts and other ways of describing the same thing.

You ask in the title what are common programming mistakes. The original point that I and the others are making is that a common mistake is to try to code the program before you have fully thought out what the program is supposed to do.