I think Jean covered a lot of this, but I'd like to put some of it into my own words too.
EssEss wrote:nothing stands out immediately except for:
# when declaring a pointer make it (type* name) not (type *name)
# Never use int, always char, short or long
I disagree w/#1 because:
vs:
granted, I can't even remember that last time I did that, but I've seen others nailed by it multiple times.
I disagree w/#2 because the standard says that int is described as the most efficient native type for that platform. by restricting that you lose portability by making people aware of their platform.
1) If you are right, which I have no doubt about, then it is an ugly "feature" of the language. A typed variable declaration reads "type OF name" and to take the type and spread it into more than one place is ugly. I still advocate the way I said because I strongly prefer to never use a list of vars in a declaration, that is, I think it should be one statement per line, in this case, one variable declaration per line. Putting different types on one line is just ugly in my eyes.
short counter1;
short coutner2;
is better than
short counter1, counter2;
in my eyes.
2) If you use "int" then the code is actually NOT portable, whereas if you use char, short, long then it IS portable because the same behaviour AND accuracy and overflow etc will be present on both platforms. In the case of this chip alone, without porting it, a compiler flag change could totally break the code if int is used instead of an explicit type.
I think that you're working towards some kind of HAL, and the 5554 guys are actually depending on that. Thats the only reason I'm pushing on portability.
Some kind, maybe, fully portable I don't think is possible at this level. We are basically writing some math, glue code, ext interface and a hardware driver.
After that, the next problem you should run into is 'bounding' issues where your algorithims may inadvertantly depend on the 'width' of that type -- thats where something like units tests can help .. I enjoy
CUnit
That is the thing, it isn't inadvertent, it is totally and necessarily explicit and intentional. You MUST be aware of the width of each variable to properly use it for accuracy and correctness. This absolutely goes for all mathematics, but also goes for things as basic as a loop in which you need to know how big it is going to go to use something large enough, likewise, if it goes smaller, you should scale down to compress the code. This core works nicely with both 8 and 16 bits so this choice is up to the programmer to make every time he declares something.
C is suprisingly portable if architected nicely - I commonly proto things out in msvc before even pushing it into my platforms.
I agree with this approach and am advocating it for the PID stuff, transient stuff and even averaging stuff.
This may give some ideas on how I can help out with the code base ?
In many ways, no doubt :-) Right now, the averging code would be a nice addition. How are you with Git?
I really have no problem with adhereing to the rules at all. I am appreciative that Fred's guidelines and just that - I've had the most success with this style. Peer review usually degenerates into squabbling over style and template modification with something rigid.
There are no hard and fast rules really, other than try to be nice most of the time :-) I'd much prefer the code stayed pretty consistent and that each block was the same throughout, but I won't cry about stuff that works but is different to my ideals. I may at my option "fix" stuff as I go though :-) I'm a bit like that... sorry.
As also stated previously I accept/understand/appreciate that Fred is the final word. I'm not shooting for change - just spurring some conversation, since there is most likely some background I'm missing.
I have to be the final word, by definition, BUT, I don't want it to be by iron fist, I want it to be the best solution, not just something that tickles my fancy. Some background to the (incomplete and draft) code style document :
http://issues.freeems.org/view.php?id=10
There is a broken link at the bottom of the page itself :
http://freeems.sourceforge.net/doxygen/ ... Style.html
Fred.