eeprom

Having comments telling "what" often leads to source code where the instructions does one thing, and the comments says something else.

For me, I prefer to do just that; i.e., include the comments.

My reasoning - If the instructions and the comments do not match, then it is an immediate indication that (at least) one of them must be wrong.

In projects where the development team is 'just me', I need all the help I can get. This helps me to read through the code looking for 'sillies' more effectively.

Having comments telling "what" often leads to source code where the instructions does one thing, and the comments says something else.

For me, I prefer to do just that; i.e., include the comments.

My reasoning - If the instructions and the comments do not match, then it is an immediate indication that (at least) one of them must be wrong.

In projects where the development team is 'just me', I need all the help I can get. This helps me to read through the code looking for 'sillies' more effectively.

When opening a project, you don't have time to compare code to comments to check if they match. And if they do not match - which is correct? A silly bug in the code, or the comment not being updated when the logic was updated?

I would definitely recommend that you concentrate on documenting the "why" and write the code in a way that it is enough to look at the code to see the "what".

When you open an old project and see something like

delay_ms(1000); // delay for 1000ms

you most definitely know what it does (or at least what it is expected to do, unless the delay_ms() function is broken). But the question is: Why do you call it? What happens if the delay is increased or decreased? Is the delay needed to let a voltage stabilize, or to make sure that the other side of a communication channel doesn't get overrun or... How has the delay value been deduced? Verified with oscilloscope and with xx% safety margin added? That is things you want to know, when you are in a rush to modify the code to add the next magic feature some customer has requested.

Per,

I would not argue with your content of the comment - Putting in the 'why' is far more important that repeating the obvious.

But if, for example, there is a line of code:

StartTx();  // Check for completion

I do find that on skimming over the code, I notice such obvious discrepancies.

i recall 'comments' from the assembler days such as
push acc ; save accumulator on stack
which, of course do not even deserve the name 'comment'.
however
push AR3 ; beware, the use of r3 is buried deep, do not remove
might have a purpose

I totally agree with the statement that why is the important thing to comment, However, as far as what there are cases:
// ........
// ........
// ........
// exit false if overlow occur

U1 DoSomeMathFunction(U8 Tom, U16 ***, U8 Harry)

i would hate to go through lots of lines of code to see what the exit flag signified.

Erik

I wanna know the difference between the follwing...

Linear Hall-Effect Sensors

Unipolar Hall-Effect Digital Switches

Omnipolar Hall-Effect Digital Switches

Bipolar Hall-Effect Digital Switches

Hall-Effect Digital Latches

First of all, you wrote a statement - was it inteded to be a question?

The functioning of different sensors isn't directly related to the Keil tools. Don't you think a hardware-orientthe inner workings of electronic components?ed forum might be a better choice when wondering about?

Besides, what does the sensors has to do with the use of EEPROM memories?