What are the most common programing mistakes programmers make?[SOLVED]

Thread Starter

Pushkar1

Joined Apr 5, 2021
205
Here are many people who have many years of experience in embedded development. Many are still working and some have retired. You must have seen many people making common mistakes when writing code.

What are the most common programing mistakes programmers make when writing code for communication protocol eg UART, I2C, SPI, CAN, etc.

This a really vague question. it would be very hard to give the correct answer. But if you want to share some experience, please share.
 

BobaMosfet

Joined Jul 1, 2009
1,848
Here are many people who have many years of experience in embedded development. Many are still working and some have retired. You must have seen many people making common mistakes when writing code.

What are the most common programing mistakes programmers make when writing code for communication protocol eg UART, I2C, SPI, CAN, etc.

This a really vague question. it would be very hard to give the correct answer. But if you want to share some experience, please share.
The more experience you have as a developer, the more likely it is to overlook simple things- they are assumed that you did it right. So as a debugging measure, my *FIRST* things are to go back and make no assumptions:

  1. Is my syntax right?
  2. Did I accidentally have a comma somewhere I shouldn't have, or fail to put in a semicolon (for C) where it needed to be?
  3. Is my logic sound? (Check it with a flow-chart)
  4. Will my code actually achieve what I want, or what I _think_ it does? Code does what it's told to do, not what you think it does.
  5. Did I include things in the right order?
  6. Did I override includes with defines in the right order?
  7. Did I prototype my functions/procedures?

The technical side of writing in any language comes down to just one thing- accurately translating logic into algorithm. The 'art' side of programming is understanding your machine, and your language so well that you can look at things with perspectives others don't necessarily see- and do amazing things efficiently, elegantly, simply, while producing robust, fast, accurate results able to withstand the test of time. IMHO
 

BobTPH

Joined Jun 5, 2013
3,648
For embedded programming, I think the most common mistake is incorrect or incomplete understanding of the hardware peripherals.

Bob
 

bug13

Joined Feb 13, 2012
1,979
For me, is using simple variable names
C:
uint16_t reading = 1234;
uint16_t batteryReading_mV = 1234;

uint8_t index = 0;
uint8_t indexOfBattVoltage = 0;
 

JohnInTX

Joined Jun 26, 2012
4,545
i'm not sure, do you mean algorithm, flowchart should be developed before writing code
Yes, exactly. Think of programming as problem solving. You solve the problem first in your mind and on paper then code that solution. Coding just describes that solution to the computer. If you haven’t solved the problem in the design stage it is impossible to express a solution in code. There are many tools such as flowcharts, state diagrams, tree diagrams that can be used to help organize the design process but whatever tool you use, you must have a clear, detailed description of how to approach the solution to the problem before you can code it or test it.
 
Last edited:

Thread Starter

Pushkar1

Joined Apr 5, 2021
205
. There are many tools such as flowcharts, state diagrams, tree diagrams that can be used to help organize the design process but whatever tool you use, you must have a clear, detailed description of how to approach the solution to the problem before you can code it or test it.
I know what is Flowchart, State Diagram, but I have never heard of Tree Diagram which use in Embedded System Design.

Can you please explain how it is used in design
 

JohnInTX

Joined Jun 26, 2012
4,545
1626357532453.png
A tree diagram looks something like this. The node at the top is the main function to perform. In this example, the main function at the top uses 3 supporting functiono to do its job INPUT, PROCESS, OUTPUT for example. Each of those functions in turn call upon supporting functions at a lower level and so on. The tree diagram becomes a visual description of the whole program, its parts and how those parts relate to each other.
 

andrewmm

Joined Feb 25, 2011
1,752
a) not understanding the problem / task, but saying they do
b) not testing the code , compile and run
c) not having code peer reviewed, ( its so simple what can go wrong )
d) Commenting , lack of or stupid comments,
e) and the biggest , syntax , but the IDE should find that for you,
 

Thread Starter

Pushkar1

Joined Apr 5, 2021
205
I agree with you 100% @JohnInTX . we should have design plan before writing code. I see a lot of people they write code directly. But I always try to learn techniques how to design the system. I have found great advice on this forum, especially @MrChips has given me great tips.But there are still many questions that I do not understand, maybe with time I will understand.

A puzzle for me is that I don't understand what tools should be used to design a project. Of course the tool will depend on the project. But I am still not clear which tool should be used for which project.

List of tools
1. Flowchart
2. State diagram
3. Table's
4. Timing Diagram
5. Tree Diagram
6. Graph

Can you give some advice on what tools and when should be used in project planning?

I'm sorry if this question is not suitable for this forum or off topic, please ignore
 
Last edited:

JohnInTX

Joined Jun 26, 2012
4,545
Can you give some advice on what tools and when should be used in project planning?
Each of the tools you listed has things they do well and things that something else would be better. For example, a flow chart is good for describing a procedural process i.e. starts at one point and proceeds through various steps to the end. But a flow chart is not as good as a state diagram to describe a state machine if that is what you are using. A tree diagram gives a nice overview of the whole process but may not have enough detail to fully describe all of the program's actions. I use a mix of all of them depending on the particular situation.

If you take the time to become familiar with each tool and more importantly USE them in your design process you'll discover which works best for a particular situation. In any case it is more important to plan your program, using whatever tool(s) and methods make that job easier and more understandable than to get hung up on which tool should be used when.

Good luck!
 
Top