Thanks, sounds good to me.

Vitaliy wrote:
> Jan-Erik is right, whenever you can't figure out what's going on, you should 
> try to isolate the problem to the smallest section of code. Which brings me 
> to the subject of refactoring, and other unsolicited advice. :-)
>
> You have a lot of code written, and it looks interesting, but there is 
> plenty of room for improvement. The code is difficult to follow because:
>
>     - The project consists of a one long file
>     - Functions and variable names are not descriptive enough
>     - Most of the functions are doing too much
>     - Some of the functions do things that are none of their business, like 
> the phonebook() displaying temperature range on the LCD.
>
>
> Here are a few suggestions to consider:
>
> 1. Split the project into several modules. For example, you could have 
> adc.c, lcd.c, phone.c, in addition to main.c.
>
>
> 2. Give your functions and variables more meaningful names. Function names 
> should be verbs, and variable names should be nouns. It's also good practice 
> to prepend global function names with the module name, for example
>
>     Phone_SendSms().
>
> Some people omit the underscore, and write
>
>     AdcGetTemperature()
>
>
> 3. Split your long functions into several smaller functions. My rule of 
> thumb is that if a function is longer than 10 lines, it is a candidate for 
> splitting up.
>
>
> 4. Make sure each function does exactly what its name says it's supposed to 
> do.
>
>
> These practices reinforce each other, and it is therefore best to use them 
> simultaneously. For example, #2 would help you practice #3 and #4. If your 
> function name is GetPhoneNumberValidateItAndSaveItToFlash() you know that it 
> needs to be split into three smaller functions:
>
>     GetPhoneNumber()
>     ValidatePhoneNumber()
>     SavePhoneNumber()
>
> And if you find that inside ValidatePhoneNumber() you have code that 
> requests battery voltage, you know that it needs to be factored out into its 
> own GetBatteryVoltage() function.
>
> Software development is about managing complexity. If you can't manage it, 
> you will drown in it.
>
> Sincerely,
>
> Vitaliy
>  
>
>   
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist