Rick Altherr a écrit :
> Perhaps I'm jaded from writing code for OS X where function names are
> intended to be descriptive and thus end up long.  Most editors include
> autocompletion which makes the difference minimal in practice.  Even
> when I'm writing code in vi, I prefer the longer type names since it
> make it clear that a) it's a type by having the _t suffix and b)
> that's an unsigned int.  With u32, there are plenty of cases where odd
> naming collisions can occur.  It's also not clear that its an integer,
> but just an unsigned 32-bit something.  To be entirely honest, I
> prefer seeing long, descriptive function prototypes like:
>
I hate the autocompletion in my editor because I think it's crap.
(slickedit) I consider it some kind of trojan which makes stupid
decisions which I most of the time disagree with.

I can understand some logic in having some descriptive value if someone
is too lazy to write comments but it is usually not necessary if
intelligent comments are used.
I find it more usefull to spend some time describing the functions.

Where I work we have coding rules but it doesn't involve descriptive
names so much as identifying what type it is and which module it belongs to.

iApp_iData1
lApp_iData1
llApp_iData1
ucApp_iData1
uiApp_iData1
ulApp_iData1
ullApp_iData1
vApp_iData1

Without telling you specifically the type you can identify easily if
rules are obeyed.

For convenience and clarity I combine the two ideas of having
descriptive names as well as comments. Descriptive names is not so
important for us as which module it is part of.

As to the "unsigned int" type I have a preference with u16 because it is
what ST uses in their libraries and it simplier and quicker to type. I
find no special purpose or improvement to use the long version for that.

With NEC it is U16 so I will need to override that in my system.h for my
project files.


I find the whole discussion silly and the proposed change ridiculous.

Michel

-- 
Tired of Microsoft's rebootive multitasking?
then it's time to upgrade to Linux.
http://home.comcast.net/~mcatudal

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to