eeprom

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.

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?